Changelog
The new beta version of Durable Objects is available where each Durable Object has a private, embedded SQLite database. When deploying a new Durable Object class, users can opt-in to a SQLite storage backend in order to access new SQL API and point-in-time-recovery API, part of Durable Objects Storage API.
You cannot enable a SQLite storage backend on an existing, deployed Durable Object class. Automatic migration of deployed classes from their key-value storage backend to SQLite storage backend will be available in the future.
During the initial beta, Storage API billing is not enabled for Durable Object classes using SQLite storage backend. SQLite-backed Durable Objects will incur charges for requests and duration. We plan to enable Storage API billing for Durable Objects using SQLite storage backend in the first half of 2025 after advance notice with the following pricing.
Exceptions thrown from Durable Object internal operations and tunneled to the caller may now be populated with a .retryable: true property if the exception was likely due to a transient failure, or populated with an .overloaded: true property if the exception was due to overload.
Durable Objects can reside in Oceania, lowering Durable Objects request latency for eyeball Workers in Oceania locations.
Refer to Durable Objects to provide location hints to objects.
Durable Objects request billing applies a 20:1 ratio for incoming WebSocket messages. For example, 1 million Websocket received messages across connections would be charged as 50,000 Durable Objects requests.
This is a billing-only calculation and does not impact Durable Objects metrics and analytics.