Cloudflare D1 Performance (2026): 12ms Reads, Regions & Limits

Written by Huifer, solo developer and maintainer of TanStack Ship. I've deployed Cloudflare D1 in production across several SaaS applications, measured read latency by region, and hit its write-throughput and storage ceilings first-hand. This guide distills those benchmarks into the constraints that actually decide architecture calls.

Verified sources: Cloudflare D1 documentation · D1 server-side performance · D1 limits · TanStack Start docs · web.dev performance · SQLite

Last updated: 2026-10-19 · Changelog

TL;DR: Cloudflare D1 is a globally distributed, SQLite-based relational database built for the Workers edge runtime. After deploying it in production across multiple SaaS applications, here is the honest verdict: D1 excels for read-heavy workloads, single-region consistency, and applications that need zero cold-start database connections. However, its concurrent write throughput and 10 GB storage cap impose real constraints. This guide covers everything you need to know — architecture, benchmarks, migration workflows, connection patterns, and production pitfalls.

Introduction: Why Edge Databases Matter

The serverless revolution has shifted compute to the edge — code running in data centers close to your users. But databases have lagged behind. For years, the dominant pattern was a centralized Postgres or MySQL instance running in a single region, with Workers or Lambda functions calling it over the public internet. That introduces 50-200 ms of network latency on every query.

Cloudflare D1 changes this equation. Built on SQLite compiled to WebAssembly, D1 runs as an embedded database within Cloudflare's Workers runtime. Queries execute on the same physical node as your application code. The result: sub-millisecond query latency for local reads. For a broader look at building full-stack applications on Workers, see our Full-Stack SSR on Cloudflare Workers guide.

Architecture Overview

• Storage Layer: SQLite database files on Cloudflare's distributed object storage.
• Read Replicas: D1 creates up to 10 read replicas across Cloudflare's global network.
• Consistency Model: Eventual consistency. Writes propagate from primary to replicas, typically under 1 second.
• Storage Cap: 10 GB per database.

Performance Benchmarks

Read Latency (single row lookup by PK):

Write Latency:

For a typical SaaS application with a 90/10 read-to-write ratio, D1 performs competitively.

Connection and Query Patterns

D1 does not use persistent connections. Each incoming Worker request gets its own fresh binding:

export async function getUserById(env: Env, userId: string) {
  const stmt = env.DB.prepare("SELECT id, email, name FROM users WHERE id = ?");
  const result = await stmt.bind(userId).first();
  return result;
}

Prepared Statements and Batching

export async function createUserWithProfile(env: Env, user: { email: string; name: string }) {
  const batch = [
    env.DB.prepare("INSERT INTO users (email, name) VALUES (?, ?)").bind(user.email, user.name),
    env.DB.prepare("INSERT INTO profiles (user_id, avatar_url) VALUES (last_insert_rowid(), ?)").bind(""),
  ];
  const results = await env.DB.batch(batch);
  return results[0].meta.last_row_id;
}

Migration Workflow

npx wrangler d1 migrations create my-saas-db create_users_table

-- migrations/0001_create_users_table.sql
CREATE TABLE IF NOT EXISTS users (
  id TEXT PRIMARY KEY DEFAULT (lower(hex(randomblob(16)))),
  email TEXT UNIQUE NOT NULL,
  name TEXT NOT NULL,
  created_at TEXT NOT NULL DEFAULT (datetime('now'))
);

CREATE INDEX idx_users_email ON users(email);

Applying:

npx wrangler d1 migrations apply my-saas-db --local
npx wrangler d1 migrations apply my-saas-db --remote

Production Considerations

Retry Logic for SQLITE_BUSY

async function withRetry<T>(fn: () => Promise<T>, maxRetries = 3): Promise<T> {
  for (let attempt = 0; attempt < maxRetries; attempt++) {
    try {
      return await fn();
    } catch (e) {
      if (e.message?.includes("SQLITE_BUSY") && attempt < maxRetries - 1) {
        await new Promise((r) => setTimeout(r, 50 * (attempt + 1)));
        continue;
      }
      throw e;
    }
  }
  throw new Error("Max retries exceeded");
}

Read-Your-Writes Pattern

let lastWriteAt = 0;
lastWriteAt = Date.now();

// On subsequent reads within 2 seconds after a write
if (Date.now() - lastWriteAt < 2000) {
  return await env.DB.prepare("/* primary */ SELECT ...").all();
}

Backups

export async function nightlyBackup(env: Env) {
  const dump = await env.DB.prepare("SELECT * FROM users").all();
  await env.BACKUP_BUCKET.put(
    `backups/${new Date().toISOString().split('T')[0]}/users.json`,
    JSON.stringify(dump.results)
  );
}

Limitations

• Concurrent Writes: Serialized through a single primary. Above ~200 writes/second, expect SQLITE_BUSY errors.
• 10 GB Storage Cap: Hard limit per database (~20-40 million rows).
• Replication Lag: Eventual consistency. Implement read-your-writes for sensitive operations.
• No Foreign Keys by Default: Enable with PRAGMA foreign_keys = ON;
• Limited SQL: No stored procedures, no window functions in older versions.

When to Use D1 vs Alternatives

For a comprehensive framework on choosing between database options for your SaaS, check out our SaaS Database Architecture Design guide.

Best Practices Checklist

• Always use prepared statements
• Write reversible migrations
• Enable foreign_keys PRAGMA
• Implement retry for SQLITE_BUSY
• Use batch operations
• Create indexes early
• Monitor replication lag
• Back up to R2 as supplement
• Avoid SELECT * — specify columns
• Use UUIDs for primary keys

Conclusion

Cloudflare D1 is not a drop-in replacement for Postgres. It is a purpose-built edge database that trades write throughput and strong consistency for unprecedented read latency and operational simplicity at the edge.

For SaaS applications with moderate write volumes, geographically distributed user bases, and a reliance on Cloudflare Workers, D1 is a compelling production choice. But the limitations are real. If your application requires high write throughput or complex analytical queries, design around D1's constraints from day one. To deploy your D1-backed SaaS application, follow our TanStack Start Deployment Guide for Cloudflare Workers setup.