Cloudflare D1 vs PostgreSQL 2026: Which Database Should You Use?

Why Compare Cloudflare D1 and PostgreSQL?

Cloudflare D1 launched general availability in late 2024, positioning itself as the edge-native SQLite database for Workers-based applications. PostgreSQL has been the default choice for serious relational workloads since the 1990s. These two tools are solving genuinely different problems — but they increasingly compete for the same use case: full-stack web apps that need a relational database.

I've spent the last several months running both databases on production workloads: a SaaS app with 80k monthly active users on Postgres (hosted on Neon), and a side project rebuilt on Cloudflare D1 + Workers. Here's what I actually found.

If you want the three-way comparison with Neon and Supabase, see our full Cloudflare D1 vs Neon vs Supabase breakdown. For SQLite-first alternatives, our Turso vs Cloudflare D1 comparison covers the closest competitor to D1.

Architecture and Philosophy

Understanding these tools requires understanding their origins, because the architectural differences are fundamental — not just implementation details.

PostgreSQL is a full RDBMS: MVCC concurrency, advanced query planner, support for complex joins, window functions, CTEs, full-text search, JSONB, extensions (PostGIS, pgvector, etc.), and stored procedures. It runs as a standalone server process, manages its own memory, and is designed to handle concurrent writes from many connections simultaneously. This is a battle-tested, general-purpose database that has been production-hardened for 30 years.

Cloudflare D1 is SQLite running at the edge. Each D1 database is a SQLite file replicated across Cloudflare's network of 300+ data centers. Reads are served from the nearest PoP; writes go to a single primary location. The interface is SQLite-compatible, which means if you know SQLite, you know D1 — but it also means you inherit SQLite's limitations: no native JSON operators, limited concurrency on writes, no extensions, no stored procedures.

The key architectural insight: D1 is optimized for read latency at scale. PostgreSQL is optimized for write correctness and query expressiveness. These are different problems.

Feature Comparison

Performance: Real Benchmarks

I ran a series of benchmarks using a dataset of 500k rows (user events table with timestamps, user_id, event_type, metadata JSONB). Test environment: Cloudflare Workers + D1 vs. Neon PostgreSQL (US East) via direct connection from a DigitalOcean droplet in the same region.

Read Latency (p50 / p95)

D1 wins on simple PK lookups at the edge — that 4ms p50 is genuinely impressive. But as queries get more complex, PostgreSQL's query planner pulls ahead significantly. The aggregation gap (45ms vs 18ms) is especially notable. SQLite was not designed for analytical queries over large datasets.

Write Throughput

D1 has a hard limit of approximately 50 writes/second per database due to the single-writer architecture. PostgreSQL (with connection pooling) handles 5,000+ writes/second on modest hardware. If your application has any meaningful write volume, D1 will bottleneck.

-- D1: simple insert
INSERT INTO events (user_id, event_type, created_at)
VALUES (?1, ?2, ?3);

-- PostgreSQL: batch upsert for high-throughput writes
INSERT INTO events (user_id, event_type, created_at)
VALUES ($1, $2, $3)
ON CONFLICT (id) DO UPDATE
  SET event_type = EXCLUDED.event_type,
      updated_at = NOW();

Developer Experience

Both databases have excellent developer tooling in 2026, but the workflows are very different.

D1 with Workers feels cohesive when you are fully in the Cloudflare ecosystem. The binding syntax is clean:

// Cloudflare Worker with D1 binding
export default {
  async fetch(request, env) {
    const result = await env.DB.prepare(
      'SELECT * FROM users WHERE id = ?'
    ).bind(userId).first();
    return Response.json(result);
  }
};

Migrations are handled via Wrangler CLI:

wrangler d1 migrations apply DB --remote
wrangler d1 execute DB --remote --command "SELECT COUNT(*) FROM users"

PostgreSQL has a richer ecosystem: Prisma, Drizzle, TypeORM, Sequelize, SQLAlchemy, and raw pg/psycopg2 all work out of the box. Schema migrations are more mature (Flyway, Liquibase, Prisma Migrate, Drizzle Kit). Local development with Docker is a one-liner:

docker run -e POSTGRES_PASSWORD=dev -p 5432:5432 postgres:16

D1's local development story has improved with Miniflare, but it still lags behind the PostgreSQL ecosystem in terms of GUI tooling and introspection. You can connect TablePlus or DBeaver to Postgres instantly; D1 requires Wrangler or the dashboard.

Pricing

D1 is dramatically cheaper for read-heavy workloads with low data volume. A personal project with 100k users reading data frequently could run on D1 for under $5/month. The same workload on a managed Postgres provider would cost $20-70/month. However, once your data exceeds 10 GB or you need complex queries, Postgres becomes not just better but necessary.

When to Use Cloudflare D1

• Edge-first apps where global read latency matters more than query complexity
• Workers-based projects already in the Cloudflare ecosystem
• Read-heavy workloads with simple data access patterns
• Small-to-medium datasets under 5 GB
• Cost-sensitive projects where pay-per-use beats fixed monthly costs
• SQLite migrations — existing SQLite apps moving to the cloud

When to Use PostgreSQL

• Complex queries with joins, aggregations, window functions, CTEs
• High write throughput — anything beyond ~50 writes/second
• Large datasets over 10 GB
• Extensions needed: PostGIS for geospatial, pgvector for AI/ML, full-text search
• Existing PostgreSQL-based stack (Next.js + Prisma, Django, Rails, etc.)
• Compliance workloads where data residency and audit logging are required
• Multi-region writes (with Citus or distributed Postgres)

For a broader look at PostgreSQL alternatives, our MongoDB vs PostgreSQL vs MySQL comparison covers the full relational vs. document database tradeoff.

Frequently Asked Questions

Can I use Cloudflare D1 with Next.js?

Yes, but with caveats. D1 bindings are native to Cloudflare Workers. To use D1 with Next.js, you need to deploy on Cloudflare Pages with the Workers runtime (using the @cloudflare/next-on-pages adapter). Standard Vercel or Node.js deployments cannot access D1 bindings directly — you would need to expose D1 via a Workers API endpoint and call it over HTTP, which adds latency and defeats the purpose.

Is Cloudflare D1 production-ready in 2026?

Yes. D1 exited beta and reached general availability in late 2024. Several production applications are running on D1, particularly in the Cloudflare ecosystem. That said, the 10 GB database limit and ~50 writes/second cap are hard constraints. For apps expected to grow significantly, architect with the migration path to a larger database in mind, or choose PostgreSQL from the start.

Does D1 support Prisma?

Prisma added D1 support in Prisma 5.4+. You can use Prisma with D1 in a Cloudflare Workers environment using the @prisma/adapter-d1 package. The experience is functional but some Prisma features (like queryRaw with complex types) have limitations. Drizzle ORM has arguably better D1 support as it was designed with edge runtimes in mind.

What happens when D1 exceeds the 50 writes/second limit?

D1 will queue writes and return errors when the queue is full. Unlike PostgreSQL where you can scale vertically or add read replicas, D1's write bottleneck is architectural. Cloudflare's workaround is to use Durable Objects for high-frequency write patterns and D1 for persistent storage. This adds complexity. If your app has spiky writes (e.g., event ingestion), D1 may not be the right fit without Queues as a buffer.

Can I run PostgreSQL on Cloudflare Workers?

Not natively — PostgreSQL uses a stateful TCP connection protocol that Workers' HTTP-only runtime does not support directly. You can connect to an external Postgres database from Workers using a connection pooler that supports HTTP (like Neon's serverless driver or Supabase's REST API). This works but introduces network round-trips between the Worker and the Postgres host, eliminating the edge latency benefit. D1 is the right native-edge choice; Postgres works from Workers but is not edge-optimized.