News for hackers. Stuff that matters.
Re:D1: Our SQL database by greg-m on Wednesday May 11, 2022 @10:59AM (#31340942)
Just clarifying - D1 without read replicas is strongly consistent. If you add read replicas, those can have replication lag and will not be strongly consistent.

Disclaimer: I work at Cloudflare :)

Re:D1: Our SQL database by infogulch on Wednesday May 11, 2022 @11:13AM (#31341151)
Thanks for the clarification, that is what I would expect.

Does SQLite support some kind of monotonic transaction id that can be used as a cache coherency key? Say a client writes a new record to the database which returns `{"result": "ok", "transaction_id": 123}`, then to ensure that subsequent read requests are coherent they provide a header that checks that the read replica has transaction_id >= 123 and either waits for replication before serving or fails the request. (Perhaps a good use for the embedded worker?)

Re:D1: Our SQL database by discodave on Wednesday May 11, 2022 @04:41PM (#31345480)
Since it's a relational DB, and supports transactions, you can have a journal table right?

I know of a very important system at AWS that did this with MySQL :D

Re:D1: Our SQL database by infogulch on Thursday May 12, 2022 @10:28AM (#31354737)
Yes you could do it manually, but it would be nice if the solution didn't require carefully managing update queries so the journal addition isn't missed and increasing write amplification to manually update a journal table when that information probably already exists somewhere in the WAL implementation.
Re:D1: Our SQL database by vlovich123 on Wednesday May 11, 2022 @11:41AM (#31341585)
Yup sorry about that. I missed the entire "read replica" bit when reading that blog post.