Cloudflare D1: Serverless SQLite in Production (2026)

Updated July 2026: Verified against Cloudflare's current docs and release notes — corrected read-replication status (still public beta, not GA), added direct answers on D1's SQLite version, realtime, and Postgres support, a "what changed in 2025–2026" timeline, and updated competitor status (Turso's SQLite rewrite, PlanetScale on Postgres 18).

SQLite Is Eating the Cloud

The most deployed database engine in the world is not Postgres or MySQL — it is SQLite. It runs in every smartphone, every browser, and most operating systems. And now it is running in the cloud.

Cloudflare D1, built on SQLite, reached general availability in April 2024 and has since added global read replication, a Sessions API for consistency guarantees, up to 60 percent faster Worker API latency, and a storage backend that is 6 to 20x faster than the original alpha. The Cloudflare developer platform serving D1 now has over 4.5 million active developers and generated $2.17 billion in revenue in fiscal year 2025.

D1 is not trying to be Postgres. It is designed for a fundamentally different pattern: many small databases rather than one large one. With 50,000 databases per account and 10 GB per database, D1 targets per-user, per-tenant, and per-entity data isolation at global scale.

Cloudflare D1 in 2026: Quick Answers

The questions people actually ask about D1, answered directly and verified against Cloudflare's current documentation.

Is Cloudflare D1 production-ready? Yes. D1 reached general availability in April 2024 and is a supported production database. The one caveat: global read replication, D1's headline scaling feature, is still in public beta as of mid-2026 — see below.

What SQLite version does D1 run? Cloudflare describes D1 as "real SQLite" but does not publish a pinned version number — there is no version field in the docs or the dashboard. The last community-observed version sat in the 3.41.x range in 2024, but that is unverified for 2026 and should not be relied on. If your application must target a specific, guaranteed SQLite version, D1 is not the place to pin it.

Does D1 support realtime or live queries? No. D1 has no native change-subscription, live-query, or realtime feature comparable to Supabase Realtime. On Cloudflare, realtime is a job for Durable Objects: each Durable Object is a single-threaded actor with its own embedded SQLite and a WebSocket Hibernation API, which is the native pattern for live connections and change fan-out. Reach for Durable Objects, not D1, when you need push.

Does D1 support Postgres? No. D1 is SQLite only — no Postgres, and no Postgres wire protocol. If you need Postgres on Cloudflare, use Hyperdrive to connect Workers to an existing external Postgres (Amazon RDS, Cloud SQL, Neon, or self-hosted), or use a Postgres platform such as Neon or Supabase directly. D1 and Postgres solve genuinely different problems — pick D1 for SQLite-shaped, edge-first, per-tenant data, not as a Postgres replacement.

Is global read replication generally available? Not yet. It entered public beta in April 2025 and remains beta as of mid-2026, with no GA announced. It costs nothing extra, requires the Sessions API (available through Worker bindings only, not the REST API), and routes reads to the nearest replica while all writes go to the single primary.

What are D1's current limits? 10 GB per database (a hard cap — the architecture pushes you toward many small databases, not one large one), 50,000 databases per account, and 1 TB total storage on Workers Paid. Up to 1,000 queries per Worker invocation, 2 MB max row/value size, and single-primary, single-threaded writes. (If you see a "2 GB max database" figure in 2026 coverage, it is recycled from a 2023 announcement — the current cap is 10 GB.)

How much does D1 cost? The Free plan includes 5 million rows read per day, 100,000 rows written per day, and 5 GB of storage. Workers Paid (a 5-dollar per month Workers subscription) includes 25 billion rows read and 50 million rows written per month, then bills 0.001 dollars per million rows read and 1 dollar per million rows written, with 5 GB of storage included and 0.75 dollars per GB beyond it. There are no egress charges on any plan.

D1 Architecture and Capabilities

How It Works

D1 is a serverless SQLite database accessed through Workers bindings. Each database has a single primary instance in one region where all writes occur. Without read replication, both reads and writes route to this primary. With read replication enabled, reads route to the nearest replica while writes always travel back to the primary.

The database runs on Cloudflare's Durable Objects infrastructure, which provides the durability and consistency guarantees. Configuration is straightforward — add a D1 binding in wrangler.toml and query using the Workers API.

Limits and Pricing

D1's pricing is row-based with no egress charges:

Key architectural constraints:

• 10 GB per database — hard cap, cannot be increased. This is by design: D1 encourages horizontal scaling across many databases rather than vertical growth
• Single-threaded writes — each database processes queries sequentially. At 1ms per query, throughput is roughly 1,000 queries per second. At 100ms per query, throughput drops to roughly 10 per second
• Single primary region — all writes route to one location. Location hints let you choose the region at creation time
• Row-based billing — a 1 KB row costs the same as a 100 KB row

Performance

D1's performance has improved dramatically since GA:

Worker API latency (January 2025): Up to 60 percent end-to-end latency reduction by removing redundant network round trips.

REST API latency (May 2025): 50 to 500ms faster depending on request and database location, with the biggest improvements for databases outside the US.

New storage backend: 6 to 20x faster than the original alpha backend. Large batch operations (10,000 rows at roughly 200 bytes each) see 10 to 11x improvement with more consistent latency.

Global Read Replication

The most significant D1 feature since GA launched in April 2025 as a public beta during Developer Week: global read replication.

How It Works

When enabled, Cloudflare automatically creates read replicas across all supported D1 regions. Replicas activate and deactivate based on query traffic — if no queries come from a region, that replica goes dormant. Read queries route to the nearest active replica. Write queries always route to the primary.

The replication is asynchronous and incurs no additional cost. For read-heavy workloads, this can cut cross-continent p95 latency from roughly 150ms down to single-digit milliseconds.

The Consistency Problem

Asynchronous replication introduces a trade-off: you might write data and then immediately read from a replica that has not received the update yet. This is the classic read-after-write consistency problem.

Sessions API: The Solution

D1's Sessions API provides sequential consistency guarantees using a bookmark mechanism. Each query within a session carries a Lamport timestamp (a monotonically increasing commit token). Whatever replica handles your read request will wait until it has received all writes up to that bookmark before serving the response.

Options include:

• Default: reads may hit any replica, eventual consistency
• first-primary: the first query in a session routes to the primary (for the most up-to-date data), then subsequent queries use replicas
• Bookmark passing: pass a bookmark from one session to another to guarantee the new session starts at least as up-to-date as the previous one

This gives developers explicit control over the consistency-latency trade-off rather than forcing one model for all queries.

Time Travel and Recovery

D1 includes Time Travel — always-on point-in-time recovery at no additional cost. The system retains the Write-Ahead Log (WAL) stream, allowing restoration to any minute within the last 30 days on Workers Paid (7 days on Free).

No additional storage charges. No configuration needed. Time Travel is enabled by default on every D1 database.

The Full Cloudflare Data Stack

D1 is one piece of a comprehensive data platform that Cloudflare has built around Workers.

R2 Object Storage

Zero-egress object storage at $0.015 per GB per month. The Infrequent Access tier drops to $0.01 per GB per month with a $0.01 per GB retrieval fee and 30-day minimum storage duration. Free tier includes 10 GB per month.

The zero-egress model is R2's primary differentiator against S3 — for read-heavy workloads serving large files, the cost savings can be dramatic.

Workers KV

Global, eventually consistent key-value store with sub-millisecond reads at the edge. Free tier includes 100,000 reads per day and 1 GB storage. Maximum value size is 25 MB. Best for configuration data, feature flags, and cached content that tolerates eventual consistency.

Queues

Managed message queue now available on the Workers Free plan as of February 2026. Pricing at $0.40 per million operations with no egress charges. Free plan includes 10,000 operations per day with 24-hour retention; paid plan extends to 14-day retention.

Hyperdrive

Connection pooling accelerator for external Postgres and MySQL databases. Hyperdrive maintains connection pools optimally placed to minimize latency between Workers and your existing database infrastructure. Available on both Free and Paid plans — useful for teams that want to use Workers but are not ready to migrate their primary database to D1.

Vectorize

Globally distributed vector database for AI embeddings. Supports semantic search, classification, and RAG workflows. Combined with Workers AI for model inference and D1 for structured data, Vectorize completes the AI application stack on Cloudflare.

Durable Objects with SQLite

Durable Objects gained SQLite-backed storage (GA April 2025), supporting up to 10 GB per Durable Object with a full SQL query interface, point-in-time recovery, and the existing KV and alarm APIs. Cloudflare recommends all new Durable Object namespaces use the SQLite backend. Storage billing began January 2026.

Competition: The Serverless Database Landscape

D1 operates in an increasingly competitive market where every major player has differentiated positioning.

Neon: Serverless Postgres (Acquired for $1B)

Databricks acquired Neon for approximately $1 billion in May 2025. Over 80 percent of databases provisioned on Neon were created by AI agents, not humans — a striking indicator of how agentic workloads are driving database demand.

Neon's strengths — instant provisioning, scale-to-zero, database branching, Postgres compatibility — position it differently from D1. Neon is for teams that need full Postgres. D1 is for teams that want SQLite simplicity at the edge.

Turso: SQLite Goes Distributed

Turso takes a different approach to SQLite distribution. Embedded replicas live in your application process, native vector search supports AI and RAG workflows, and concurrent writes address SQLite's traditional single-writer limitation. Historically Turso was built on libSQL, an open-source SQLite fork in Rust — but in early 2025 the company announced it is going all-in on "Turso Database," a ground-up Rust rewrite of SQLite from scratch (with MVCC, async I/O, and concurrent writes) rather than a fork. libSQL remains production-ready and Turso Cloud runs on it today, with a migration to the new engine underway. It is the clearest sign of how much appetite there is to push SQLite past its single-writer past.

Turso competes directly with D1 in the "SQLite in the cloud" segment but with a different architecture — embedded replicas that sync into your process versus Cloudflare's edge-network replicas behind the Sessions API.

Supabase: The Postgres Platform

Supabase raised $100 million at a $5 billion valuation in October 2025, just four months after a $200 million Series D at $2 billion. With over 4 million developers, 3.5 million databases managed, and $70 million ARR growing at 250 percent year-over-year, Supabase has become the dominant open-source Postgres-as-a-service platform.

Supabase announced Multigres — Vitess-style horizontal sharding for Postgres — addressing the scaling limitations that have historically pushed teams toward NoSQL or distributed SQL databases.

PlanetScale: MySQL Adds Postgres

PlanetScale, originally MySQL-only (built on Vitess), took PlanetScale for Postgres to general availability in September 2025 (after a July 2025 private preview), now running Postgres 18 on local NVMe drives, with plans starting at 50 dollars per month. This is a significant pivot that puts PlanetScale in direct competition with Neon and Supabase rather than competing primarily on MySQL horizontal scaling.

The SQLite-in-the-Cloud Movement

D1 is part of a broader trend: SQLite is moving from embedded-only to a first-class cloud database engine.

Why SQLite in the cloud makes sense: SQLite is the most battle-tested database engine in existence. It has zero configuration, ACID compliance, and performance that scales linearly with hardware. The limitation has always been that it runs on a single machine. The cloud SQLite movement solves distribution while keeping SQLite's simplicity.

Turso/libSQL adds replication, server mode, and WebAssembly support to SQLite. The libSQL fork is a complete rewrite in Rust.

Fly.io LiteFS distributed SQLite across nodes in a cluster, though LiteFS Cloud (the managed backup service) was sunset in October 2024. The open-source project remains but without official support. Litestream is the recommended alternative for SQLite backups to S3-compatible storage.

ElectricSQL provides a bidirectional sync layer between Postgres and local SQLite using CRDTs for conflict resolution. The team includes two inventors of CRDTs and is working on v2.0 with "Durable Streams" for separating transport from sync protocols.

cr-sqlite adds CRDT support directly to SQLite as a runtime-loadable extension, enabling multi-master replication where all peers eventually converge.

The common theme: take SQLite's simplicity, add distribution, and let the edge handle reads while a primary handles writes. D1 is Cloudflare's implementation of this pattern, tightly integrated with their global network.

When to Choose D1

D1 is the right choice when:

• You are already building on Cloudflare Workers
• Your data model fits SQLite (relational but not requiring advanced Postgres features like stored procedures, JSONB, or extensions)
• You benefit from per-tenant data isolation (multi-tenant SaaS, per-user databases)
• Your read-to-write ratio is high (read replication shines here)
• You want zero egress charges and predictable row-based pricing
• Total data per database stays under 10 GB

D1 is not the right choice when:

• You need Postgres compatibility (use Neon or Supabase, or Hyperdrive to reach an external Postgres from Workers)
• You need realtime subscriptions or live queries (use Durable Objects with WebSockets, or a platform with built-in realtime like Supabase)
• You need high write throughput to a single database (D1 is single-threaded)
• Your database will exceed 10 GB (D1's hard cap)
• You need advanced SQL features (stored procedures, materialized views, custom extensions)
• You are building outside the Cloudflare ecosystem (use Turso for standalone SQLite distribution)

Cloudflare D1 represents a bet that many workloads do not need a full Postgres database — they need something simpler, faster, and cheaper at the edge. With SQLite as the engine, global read replication for latency, the Sessions API for consistency, and the full Cloudflare data stack (R2, KV, Queues, Hyperdrive, Vectorize) surrounding it, D1 has become a credible production database for edge-first applications. The 10 GB per-database cap and single-threaded write model are real constraints, but for the per-tenant, read-heavy workloads D1 targets, those constraints are features — they enforce the horizontal scaling pattern that makes the architecture work.