Cloud Parts

Cloudflare D1

Cloudflare’s serverless SQL database that speaks SQLite, runs each database inside a Durable Object, and bills by rows read and written rather than by the hour.

What it is
Relational databases
Type
Commercial product
Made by
Cloudflare, Inc.
License
Proprietary
Facts checked
12 October 2026
Website

What it is

Each D1 database is a SQLite database backed by a single Durable Object, so it lives in one location and runs one query at a time. Throughput is set by query time: at 1 ms per query a database can do about 1,000 queries a second, at 100 ms only 10. Writes are confirmed only once they are durably stored in several locations. A database can hold up to 10 GB on the Workers Paid plan (500 MB on Free), and that cap cannot be raised, so D1 is meant to scale out: one database per user, tenant or entity, with up to 50,000 databases per account by default. Workers query it through a binding, and there is also an HTTP API.

Two features come from the storage layer underneath. Time Travel keeps the database’s change log, so you can restore it to any minute in the last 30 days (7 on Free) without ever taking a backup. Read replication adds read-only copies in six regions (ENAM, WNAM, WEUR, EEUR, APAC and OC); to use them you open a session with withSession(), and each query carries a bookmark so a session never reads older data than it has already seen, even if it hits a different replica. Writes still go to the primary. Pricing is per row: the paid plan includes 25 billion rows read and 50 million rows written a month, then $0.001 per million rows read, $1.00 per million rows written and $0.75 per GB-month stored beyond 5 GB, with no charge for replicas, idle time or egress.

Why teams pick it

  • Scale to zero and per-row billing: thousands of small databases cost nothing while idle
  • SQLite’s SQL dialect, JSON functions and tooling, with migrations and imports through Wrangler
  • Point-in-time restore to any minute in the last 30 days, always on and free
  • Read replicas in six regions at no extra cost, with sequential consistency inside a session

Watch out for

  • A hard 10 GB ceiling per database, so larger data has to be sharded across databases
  • Single-threaded: one database serves one query at a time and returns “overloaded” errors once its queue fills
  • Writes always go to the primary’s location, and reads only use replicas if your code uses the Sessions API
  • SQLite limits apply: 100 columns per table, 2 MB rows, 100 bound parameters per query and 30 seconds per query

Alternatives

What all relational databases have in common →
Alibaba Cloud PolarDBCommercialAlibaba Cloud’s cloud-native relational databases: MySQL- and PostgreSQL-compatible clusters whose compute nodes share one copy of the data on distributed storage, plus PolarDB-X, a distributed MySQL-compatible edition.CedarDBCommercialA PostgreSQL-compatible database rebuilt from scratch at TU Munich, running transactions and analytics on one copy of the data on a single server.CloudNativePGOpen sourceA Kubernetes operator that runs highly available PostgreSQL with no Patroni and no StatefulSets: the Kubernetes API itself holds the cluster’s state.CockroachDBCommercialA distributed SQL database that speaks the PostgreSQL wire protocol, replicates every slice of data with Raft and keeps transactions serializable across nodes and regions.MySQLOpen sourceThe long-standing open-source SQL database behind much of the web, built on the InnoDB engine.NeonCommercialServerless Postgres that keeps data in a shared storage layer, so compute can scale to zero and a branch of the database is a pointer, not a copy.PatroniOpen sourceA Python agent beside each Postgres server that elects one primary through etcd, Consul, ZooKeeper or Kubernetes, and fails over when it dies.Percona OperatorsOpen sourceFour free Kubernetes operators from Percona that run its builds of MySQL, PostgreSQL and MongoDB, each using the engine’s own replication and backup tools.PGO (Crunchy Postgres for Kubernetes)Open sourceCrunchy Data’s Postgres operator: Patroni in every pod for failover, pgBackRest for backups, and a declarative `PostgresCluster` resource on top.PlanetScaleCommercialManaged MySQL on Vitess and managed Postgres, with schema changes shipped through branches and deploy requests.PostgreSQLOpen sourceThe open-source relational database that most new projects start on, extensible enough to grow into many niches.ScramDBCommercialA brand-new, closed-source database that speaks the PostgreSQL protocol and promises transactions, analytics and vector search on one copy of the data; first builds shipped in summer 2026.SQLiteOpen sourceA complete SQL database in a library and a single file, with no server to run.TursoOpen sourceA from-scratch Rust rewrite of SQLite with concurrent writes, plus libSQL (an open-contribution SQLite fork) and Turso Cloud, which hosts many small databases on S3.VitessOpen sourceA proxy layer, born at YouTube, that shards MySQL across many servers while the app still sees one database.

How it fits with other technologies

Read from a nearby replica without losing your own writes · ts

// wrangler.jsonc: "d1_databases": [{ "binding": "DB", "database_name": "shop", "database_id": "<ID>" }]
export default {
  async fetch(request, env): Promise<Response> {
    // continue from the client's last bookmark, or start anywhere
    const bookmark = request.headers.get("x-d1-bookmark") ?? "first-unconstrained";
    const session = env.DB.withSession(bookmark);

    const { results, meta } = await session
      .prepare("SELECT id, total FROM orders WHERE customer_id = ? ORDER BY id DESC LIMIT 20")
      .bind(new URL(request.url).searchParams.get("customer"))
      .run();

    const response = Response.json({ results, servedBy: meta.served_by_region });
    response.headers.set("x-d1-bookmark", session.getBookmark() ?? "");
    return response;
  },
} satisfies ExportedHandler<{ DB: D1Database }>;

See it in a real stack

No architecture uses Cloudflare D1 yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2022–2025

By 2022 Workers had KV, Durable Objects and R2 for storage, but developers kept asking for a database they could query with SQL. On 11 May 2022 Cloudflare announced D1, “our first SQL database”, built on SQLite. The announcement pointed out that SQLite called itself “serverless” long before the cloud meaning existed, and that a database designed for clients fit Workers, which also borrowed client technology.

D1 went into open alpha in November 2022. In May 2023 Cloudflare replaced its storage with a new backend, up to 20 times faster on its Northwind demo, and introduced Time Travel, built by keeping SQLite’s write-ahead log. D1 became generally available on 1 April 2024 with 10 GB databases and 50,000 databases per account. The same storage system was later opened up to developers directly as SQLite inside Durable Objects, and Cloudflare says D1 itself runs on it.

Global read replication followed in public beta on 10 April 2025, built around sessions and bookmarks so that replicas could be used without breaking “read your own writes”.

Why it’s built this way

SQLite instead of a client-server database
Cloudflare wanted a familiar SQL dialect, a robust query engine and one of the most battle-tested codebases to build on, and SQLite was already designed to run without a server.
Many small databases instead of one big one
Each database is a single-threaded Durable Object capped at 10 GB, and billing is per row, so Cloudflare steers users toward per-tenant databases that cost nothing when idle.
Bookmarks and sessions for replicas
Requests from one client can land on different replicas, so D1 attaches a bookmark to each query and only serves a session from a copy at least that fresh, giving sequential consistency without pinning clients to a replica.

Timeline

  1. 2022

    D1 announced on 11 May; open alpha in November

  2. 2023

    New storage backend and Time Travel announced in May

  3. 2024

    Generally available on 1 April, with 10 GB databases

  4. 2025

    Global read replication enters public beta on 10 April

Sources6 · facts checked 12 October 2026

Improve this page on GitHub