How Cloudflare D1 Scales to Millions of Databases

Growth driven by AI-assisted development

Cloudflare's D1, a managed serverless database built on SQLite, has passed 5.5 million databases, with 15x growth in live non-deleted databases over the past year and 65x over two years as of October 8, 2026. Daily active databases grew 18x in the same period. The company attributes the shift to AI-assisted development and vibe coding platforms, which push applications toward many small databases, one per user, app, preview environment, or tenant. OpenAI's ChatGPT Sites is among the platforms building on D1. Jon Abrams of ChatGPT Sites said D1 gives users "a simple, scalable way to add features like custom metrics, leaderboards, and comments" to their dashboards, games, and tools.

Architecture: Durable Objects, Workers KV, and Hyperdrive

Each D1 database is backed by a single SQLite Durable Object, making it possible to create millions of them. API requests arrive through the D1 Edge API Worker, while the Eyeball Worker proxies all traffic to the underlying Durable Objects, handling observability, automatic retries, and error handling. Workers KV serves as the edge caching layer for read-heavy routing metadata, and Hyperdrive provides connection pooling, caching, and optimized routing for the central Postgres cluster in Cloudflare's core data centers. The team separates operations into a data plane for queries, a control plane for API operations, and a background asynchronous plane for analytics and billing.

Fast creation and self-correcting heartbeats

Database creation checks account limits, generates a unique database UUID and Durable Object ID, initializes the Durable Object, persists metadata to Postgres, and writes the ID mapping to Workers KV. The Postgres write acts as a creation checkpoint, and the final KV update happens in a waitUntil() call that is allowed to fail. Every 30 seconds, with per-database jitter, each Durable Object heartbeats the control plane to learn its active or deleted state. This lets orphaned Durable Objects mark themselves deleted and ensures Workers KV eventually reflects reality, with the Durable Object acting as the serialization point for KV writes.

Keeping queries off the central database

Query requests over HTTP skip Postgres entirely. The Edge API Worker loads the database mapping from Workers KV, falling back to Hyperdrive and Postgres replicas only on rare cache misses, then forwards the query through the Eyeball Worker to the Durable Object. Worker bindings carry encoded authorization, so requests from user Workers skip the mapping lookup altogether. Storage usage updates flow through a Kafka-like queue to batch writes to Postgres, and incremental view maintenance precomputes per-account totals in an account_database_stats table so enforcement lookups stay constant time even for accounts with millions of databases.

Sources: Cloudflare