September 26th, 2024

Zero-latency SQLite storage in every Durable Object

Cloudflare's Durable Objects now feature zero-latency SQLite storage, enabling synchronous SQL queries, enhancing performance, supporting scalability, allowing fast writes with data durability, and offering point-in-time recovery within 30 days.

Read original articleLink Icon
Zero-latency SQLite storage in every Durable Object

Cloudflare has introduced zero-latency SQLite storage within its Durable Objects (DO) framework, enhancing cloud computing by allowing application code to run directly where data is stored. This architecture eliminates traditional network latency by embedding SQLite as a local library, enabling synchronous SQL queries that return results almost instantaneously. Previously, DOs only supported key/value storage, but now they offer a full SQL interface, leveraging SQLite's speed and reliability. Durable Objects are small, stateful servers that can be accessed globally, allowing for real-time collaboration and efficient state management. They are designed to scale out rather than up, meaning multiple DOs can handle different logical units of state to manage high traffic. The introduction of "Output Gates" allows for fast writes without blocking the application, ensuring that responses are only sent after confirming data durability. Additionally, SQLite-backed DOs support point-in-time recovery, allowing users to revert to previous states within 30 days. This innovation simplifies database interactions, making it easier for developers to manage data without needing extensive SQL knowledge.

- Cloudflare's Durable Objects now support zero-latency SQLite storage.

- Synchronous SQL queries in DOs enhance performance and reduce complexity.

- Durable Objects are designed for scalability, handling high traffic efficiently.

- "Output Gates" enable fast writes while ensuring data durability.

- Point-in-time recovery is available for SQLite-backed Durable Objects.

Link Icon 4 comments
By @garethalpha - 3 months
They don't mention how the Output Gates interact with things other than the HTTP response. So it seems entirely possible that you could write some data, notify some other system with a POST message, and then try to respond OK to your caller... only to lose the write. Caller doesn't get his OK, but the other system DOES receive a POSTed message. Could be a different channel, e.g. websocket. Could be a write to D1, or KV. Many ways this leads to inconsistent state.
By @imtringued - 3 months
The part where they query individual rows through SQL queries isn't "cringe" because it is inefficient. It is "cringe", because you have degraded SQLite to nothing but an overly verbose key value store.

Shared SQL databases tend to have very poor performance when you join across shards. In this case the downside of distributed joins is avoided by having very many small purpose built databases.

By @SPascareli13 - 3 months
This looks absolutely amazing and absurd at the same time.

All IO is synchronous? Writes don't actually write when they say they do? Running 201 queries is as "fine" as running a single one with join?

It seems as they got every bad ideia in the book and somehow made it into something that works (that is, if it actually does).

By @apitman - 3 months
Honestly really impressive. SQLite is eating the world.