Cloudflare details how D1 scales to millions of small databases for AI-built apps

Cloudflare reworks D1 for a per-tenant world

Cloudflare has published an engineering deep dive into D1, its managed serverless SQLite database, explaining how the service was re-architected to handle millions of databases created largely by AI-driven development platforms.

According to the Cloudflare blog, conventional database design assumes an application runs on one or two big clusters, usually fronted by a connection pooler. AI-assisted development and so-called vibe coding platforms invert that assumption: they spawn many small databases, one for each user, app, preview environment or tenant. D1's model, where every database is managed by Cloudflare and billed only for what is used, fits that shape, but only if the control plane can keep up.

The growth behind the redesign

Cloudflare reports that D1 has passed 5.5 million databases. As of October 8, 2026, the number of live, non-deleted databases had grown 15x over the previous year and 65x over two years, while the number of databases executing at least one query per day grew 18x year over year.

The company says established platforms are already building on D1 using the same tools available to any Cloudflare customer. It cites ChatGPT Sites, which according to a statement from OpenAI's Jon Abrams included in the post relies on D1 to give users of its dashboards, games and tools features such as custom metrics, leaderboards and comments.

How the control plane is put together

Each D1 database is backed by a single SQLite Durable Object, which is what makes creating millions of them practical, Cloudflare explains. All public API surfaces, including the dashboard, Wrangler and the Cloudflare CLI, pass through Cloudflare's edge gateway into a D1 Edge API Worker.

That worker splits traffic into two kinds. Query endpoints and applications using a D1 Worker binding are routed to a component Cloudflare calls the Eyeball Worker, a proxy that fronts the Durable Objects and centralizes query handling, retries, error handling and observability before forwarding each request to the object backing a given database.

The remaining CRUD endpoints, covering creating, deleting and listing databases plus import, export and time travel, are served through Hyperdrive, Cloudflare's connection-pooling product, against a central Postgres cluster Cloudflare refers to as Core. One Hyperdrive configuration is uncached and targets the primary; the other is cached and targets read replicas. Workers KV, the globally distributed key-value store, sits at the edge as a cache for read-heavy metadata, including the mapping from database ID to Durable Object ID that the query path depends on.

Cloudflare formally divides operations into three planes: a data plane for queries that must stay fast and always run at the edge, a control plane for API and lifecycle operations that may depend on central single-region components, and a background asynchronous plane for analytics and billing work that can be eventually consistent.

Creating a database in seconds

When a database is created, the system checks free-tier and account limits, generates a database UUID and a fresh Durable Object ID, initializes that object, writes a metadata row to Postgres, and records the database-to-object mapping in Workers KV. A sample Wrangler creation shown in the post completes in roughly 1.6 seconds of wall-clock time.

Principles Cloudflare says generalize

The post lists engineering tenets it claims apply to anyone building control or data planes on Cloudflare's Developer Platform. Design every process for failure and idempotency so the system can self-correct and keep making progress. Keep centralized single-region components out of any data-plane hot path. Place critical routing metadata in Workers KV so cache misses rarely need to hit central databases. Use Hyperdrive, with read replicas wherever possible, for access to central Postgres. Periodically precompute aggregations in the database rather than running scans while handling user requests. And lean on queues and eventual consistency between components that do not need strong consistency. Cloudflare adds that it repeatedly load-tested against a target well above expected growth to find and fix bottlenecks.

Why it matters

The post is a concrete signal of how AI-assisted development is reshaping infrastructure assumptions. Instead of sizing one database for an application, platforms increasingly provision a database per tenant or per generated app, and the hard problem shifts to the control plane that tracks them all without taxing every query. For builders on Cloudflare, the piece doubles as a reference architecture for edge-first systems. For the wider industry, it shows that database services will increasingly be judged on cheap, fast provisioning of enormous numbers of small databases, a workload that the classic big-cluster-plus-connection-pooler design was never meant to serve.