Zero-latency SQLite storage in every Durable Object

> ..each DO constantly streams a sequence of WAL entries to object storage - batched every 16MB or every ten seconds.

Which also means it may take 10 seconds before you can (reliably) read the write globally.

I keep failing to see how this can replace regionally placed database clusters which can serve a continent in milliseconds.

Edit: I know it uses streams, but those are only to 5 followers and CF have hundreds of datacenters. There is no physical way to guarantee reads in seconds unless all instances of the SQLite are always connected and even then, packet latency will cause issues.

The writes are streamed in near real time to five followers, acknowledging it near instantly. The cloudflare blog article mention this more in depth. So writes remain fast, while still having durability.

Those WAL entries streamed to object storage I think are just for backups.

Each DO is globally unique (there's one DO with a given id running anywhere) and runs sqlite on its own local storage in that datacenter.

AFAIK the writes and reads are done only from the same process, so the long term storage will apply only if the current process is hibernated. When you write something and then read it, it's immediate, because the writes and reads are also updating the current process's state in memory.

For another process (e.g. another DO or another worker) to access the data, they need to go through the DO which "contains" the data, so they'd be making a RPC or a HTTP request to the DO, and they'd get the latest information.

+ the hibernation happens after x seconds of inactivity, so it feels like the only time a data write to be unavailable as expected would be when the DO or worker crashes right after a write.

You're right that reads and writes are immediate in the same client connection, this is how it works with CF KV as well - but not across the entire network.

On KV they expect up to 30 second latency before a write can be written everywhere, I expect similar here.

Cloudflare ensures all operations on a DO happen on _the_ single instance of that DO, worldwide.

There’s no such thing as the read after wrote problem because only one host will ever do reads and writes (until that host dies).

Indeed. The entire purpose of DO’s is essentially to provide the consistency guarantees that KV cannot.

As others have noted, you misunderstand how Durable Objects work. All traffic addressed to the same object is routed to a single machine where that object lives. That machine always has a consistent view of its SQLite database. You can have billions of objects, but each has its own separate database. There's no way to read from a database directly from a different machine than the one the DO is running on.