D1 review

D1 is SQLite hosted on Cloudflare’s edge: a real relational database next to your Workers, with almost no setup and very low pricing. For a prototype or hobby project, it really is that easy.

Production is different. Every database has a single writer and a hard 10 GB size cap, and the cap is optimistic in practice, since error rates climb sharply once a database grows past 8 GB or so. Larger workloads mean manually sharding across databases. At that point you are rebuilding the hard parts of a distributed database on top of a product that does not help you do it. Read replication helps read throughput, but the single writer remains.

Errors are the main reason reliability is a 3. Cloudflare’s own debugging docs catalog the transient failures to expect in normal operation, including “Network connection lost”, “storage caused object to be reset”, and “Cannot resolve D1 DB due to transient issue on remote node”. D1 retries read-only queries up to twice on its own, and the docs put the success rate of those retries anywhere from 5% to 95% depending on the underlying error. Writes get no automatic retries, and there are no interactive transactions, only an atomic batch() API, so multi-step write recovery is code you write yourself. The worst case shows up in community threads regularly: a database stuck returning internal error 7500 on every query for days, with nothing to do but wait on support.

It sits on Durable Objects storage under the hood, which means it inherits that platform’s operational characteristics too. Several of the errors above are a Durable Object resetting underneath your database. Great for demos, proofs of concept, and per-tenant toy data. I would not put a production system of record on it today.