- Cloudflare says D1 has passed 5.5 million databases, and it designs the query path to avoid its central Postgres so queries are not routed through it.
- Creation and deletion can fail midway, so each database checks in about every 30 seconds and corrects itself against the central record over time.
- Ask your team which hot-path operations depend on one central store, and what happens when a multi-step operation stops halfway.
Most database stories are about the data. Cloudflare's new account of D1, its managed SQLite-based database, is about the paperwork. Once a platform holds millions of small databases, the hard part is creating, counting, limiting and deleting them without routing every query through a central bottleneck. The lesson for any leader: keep the fast path free of central dependencies, and build the slow path so it corrects itself.
Why the shape of databases is changing
Cloudflare says traditional design assumes one or two large database clusters per application. In its view, AI-assisted development and "vibe coding" platforms push applications toward many small databases instead. Rather than one shared cluster, a platform might give each user, each app, each preview copy or each customer its own database. This is Cloudflare's description of demand, and the company sells the product that fits it.
The numbers below are Cloudflare's own, measured on its platform.
Cloudflare counts a database as active if it ran at least one query that day. It says hundreds of thousands are active at any point.
How queries avoid the bottleneck
Every D1 database lives inside its own Durable Object. That is a Cloudflare building block that runs SQLite and holds its own state. Cloudflare says this one-to-one pairing makes it easy to create millions of databases.
Cloudflare calls avoiding Postgres, and any other central single-region component, the key principle for query endpoints. The request runs at the nearest edge location. There it passes authentication, rate limits and checks of the account's entitlements. It then goes through a proxy Cloudflare calls the Eyeball Worker, straight to the database's Durable Object. Queries from a user's own Worker skip those checks, apart from the Eyeball Worker's own rate limiting. Their D1 binding carries encoded proof that it may reach one specific database.
The source describes this as a design principle. It does not say whether any other code path ever reads from Postgres.
Cloudflare also explains why it uses generated Durable Object IDs rather than names. Names would need a lookup in a central mapping on every query, and it says it would end up with two lookups instead of one.
How creation survives failure
Creating a database touches two systems: the Durable Object and a central Postgres primary that holds one metadata row per database. Cloudflare could not wrap both in one Postgres transaction. It says that would hold connections open while a Durable Object initializes, possibly on the other side of the world.
So the steps run in a deliberate order. The Durable Object is initialized first. Otherwise queries could reach an object that is not ready and be rejected. Then the Postgres write happens. That write is the "creation checkpoint": from that point the database counts as created, even if the reply never reaches the user. If either step fails, the system retries with a new database ID and a new object ID. Reusing the same database ID would let multiple objects believe they own one database.
A last confirmation to the Durable Object is allowed to fail. It only updates a Workers KV cache, a fast but eventually consistent store.
The heartbeat that corrects drift
Every Durable Object checks in with the control plane every 30 seconds, with a small random offset per database. It learns whether it is active or deleted and what its account limits are. These reads can come from caches or a Postgres read replica, because slightly stale data is acceptable.
The check-in lets the system correct itself toward Postgres, the source of truth. It cleans up orphaned objects. It also rewrites any cache entry that failed to update. Each object keeps its own active or deleted state, so it can reject queries even when the cache is stale.
What this shows, and what it does not
This shows a design stance: a failed step is expected, so the system is built to converge rather than to never fail. Think of an airline. Planes fly without calling headquarters for every decision, while a central registry is reconciled continuously. The idea is not new, but D1's sequence of steps is a clear example of it.
Two limits apply. This is Cloudflare describing its own system, and the numbers have not been independently checked. The sections describing these flows also give no failure rates or latency figures.
Questions for your team
If you run or buy a platform with many tenants, put these to your engineers or vendors:
Which operations on the customer-facing path depend on one central database or region? What happens to them if it slows down?
When creating or deleting something spans two systems, what happens if the process stops halfway? Is there a timer that detects and corrects the mismatch?
How stale can cached limits or permissions get before they cause harm? Who has chosen that number?
The takeaway: at scale, speed comes from what you keep off the hot path, and trust comes from how quickly the system notices it has drifted.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Cloudflare.
