Cloudflare D1 Pricing Official 2026 | DevToolReviews

The Serverless Database Landscape in 2026

The serverless database market has solidified around three distinct approaches. Cloudflare D1 brings SQLite to the edge with global read replication. Neon delivers serverless Postgres with game-changing branching workflows. Supabase wraps Postgres in a complete backend platform with authentication, real-time subscriptions, storage, and Edge Functions.

Each takes a fundamentally different approach to solving the problems of running databases in serverless environments. We tested all three across the dimensions that matter for production applications: pricing, performance, feature set, developer experience, and ecosystem fit.

At a Glance

Feature	Cloudflare D1	Neon	Supabase
Database Engine	SQLite (via Durable Objects)	PostgreSQL 16+	PostgreSQL 15+
Hosting Model	Edge (global)	Regional (multi-region)	Regional
Read Replication	Global (automatic)	Yes (Scale plan+)	Yes (Enterprise)
Write Location	Primary region	Primary region	Primary region
Pricing Model	Storage + reads + writes	Compute + storage + branching	Compute + storage + add-ons
Free Tier	5 GB, 5M reads/day	0.5 GB, shared compute	500 MB, 50K users
Branching	No	Yes (core feature)	No (Enterprise branching)
Auth Built-in	No (Workers auth)	No	Yes (GoTrue)
Real-time	No	Via extensions	Yes (Realtime)
Full-Text Search	FTS5 (SQLite)	PostgreSQL FTS	PostgreSQL FTS + pgvector
Vector Support	No	pgvector	pgvector
Edge Functions	Workers (native)	External	Edge Functions (Deno)
Max Storage (free)	5 GB	0.5 GB	500 MB
Max Storage (paid)	100 GB	500 GB (Enterprise unbounded)	16 TB (Enterprise)

Pricing Comparison

Pricing models are fundamentally different across the three platforms. We've normalized them to make direct comparison possible.

Cloudflare D1 Pricing

Resource	Free Tier	Workers Paid ($5/mo)
Storage	5 GB	$0.78/GB-month ($0.75 + base)
Read quotas	5M rows read/day	1B rows read/month
Write quotas	100K rows written/day	10M rows written/month
Additional reads	N/A	$0.999 per 1M rows
Additional writes	N/A	$8.00 per 1M rows

Neon Pricing

Plan	Price	Compute	Storage	Branching
Free	$0	Shared (0.25 vCPU)	0.5 GB	Basic branching
Launch	$19/month	1 vCPU, 10 hrs/day	3 GB	Branching included
Scale	$49/month	2 vCPU, compute hours	10 GB	Branching + read replicas
Business	$149/month	4 vCPU, compute hours	50 GB	Advanced branching
Enterprise	Custom	Custom	Up to 500 GB	Full

Supabase Pricing

Plan	Price	Database	Bandwidth	API Requests	Features
Free	$0	500 MB	2 GB	50K users	Auth, Realtime, Storage (1 GB)
Pro	$25/month	8 GB	50 GB	100K users	Auth, Realtime, Storage (100 GB), Edge Functions
Team	$75/month	16 GB	200 GB	Unlimited users	SSO, SOC2, advanced audit logs
Enterprise	Custom	Up to 16 TB	Custom	Custom	Dedicated infra, SLA

Cost Scenarios: Which Saves You the Most?

Scenario	Cloudflare D1	Neon	Supabase
Small side project (1 GB, 10K users)	$0-5	$0-19	$0
Production app (8 GB, 100K users)	$11-15	$49	$25
High-traffic app (50 GB, 1M users)	$44-50	$149	$75-150
Enterprise (500 GB, 10M users)	$395+	Custom	Custom

Cloudflare D1 is cheapest for simple workloads at scale due to its SQLite efficiency and edge distribution. Supabase offers exceptional value for its bundled features — the $25 Pro plan includes auth, real-time, storage, and Edge Functions that would cost significantly more as separate services. Neon is most expensive but offers features (branching, compute scaling) that the others don't match.

Performance & Latency

Metric	Cloudflare D1	Neon	Supabase
Read latency (hot cache)	~1-5ms (edge read)	~3-10ms	~3-10ms
Read latency (cold)	~10-50ms	~50-500ms (cold start)	~50-500ms (cold start)
Write latency	~50-150ms (primary region)	~5-20ms	~5-20ms
Global reads	Excellent (330+ edge nodes)	Good (multi-region on Scale+)	Good (multi-region on scale)
Concurrent connections	High (Workers-based)	Moderate (pooled)	High (PgBouncer)
Cold start (function)	~0-1ms	~50-200ms	~10-50ms (Edge Functions)

D1's edge architecture gives it the best global read performance. Reads are served from the nearest of 330+ Cloudflare data centers. However, all writes go to the primary region, which adds latency for geographically distributed applications.

Neon and Supabase both use Postgres, so raw query performance is similar. The main latency factors are cold starts (dormant compute resumes on the first query) and network distance. Neon's Scale plan offers multi-region replicas, while Supabase's Enterprise plan provides read replicas.

Feature Deep Dive

Cloudflare D1: SQLite at the Edge

D1 is built on SQLite, the most widely deployed database engine in the world. Running on Cloudflare's global network via Durable Objects, it offers a surprisingly capable serverless database with a clean mental model.

Strengths

• Global reads — Read queries are served from the nearest edge location to the user. For globally distributed applications with read-heavy workloads, this is transformative.
• No cold starts — D1 runs on Cloudflare Workers, which have near-zero cold start times. The first query after idle is fast.
• Simple pricing — Storage + reads + writes is straightforward. No connection pooling complexity, no compute scaling decisions.
• Worker-native — Tight integration with Cloudflare Workers. You can query D1 from a Worker with a native binding and zero network overhead.
• Automatic scaling — D1 handles connection scaling through Workers. No connection pool configuration needed.

Limitations

• SQLite constraints — No stored procedures, no user-defined functions, no triggers in the traditional Postgres sense. Limited concurrent write throughput.
• No branching — D1 databases cannot be branched for development workflows. You manage schema changes manually.
• No real-time — No built-in real-time subscriptions or change data capture.
• Max 100 GB — Hard storage limit. Not suitable for applications that will need to store hundreds of gigabytes.
• No vector support — While SQLite has FTS5 for full-text search, there's no pgvector equivalent for vector similarity search.
• Write bottleneck — All writes go to the primary region. If your users are far from that region, write latency is higher.

Best For

• Read-heavy edge applications
• Simple relational data (user profiles, settings, content metadata)
• Applications already on Cloudflare Workers or Pages
• Projects where 100GB storage is sufficient
• Teams that want simplicity over feature depth

Neon: Serverless Postgres with Branching

Neon decouples compute from storage in Postgres, enabling a serverless model that includes instant branching, autoscaling, and pay-per-use compute. It's the most faithful Postgres implementation of the three.

Strengths

• True Postgres — Full PostgreSQL 16+ compatibility. All extensions, all features, all tools. If you know Postgres, you know Neon.
• Database branching — Neon's signature feature. Create a branch in seconds with copy-on-write storage. Branches share data with the parent until modified, making them storage-efficient. Perfect for PR preview environments.
• Autoscaling compute — Compute resources scale automatically based on load. Idle databases scale to zero (no compute cost).
• Ephemeral branches — Create throwaway databases for testing migrations, running CI pipelines, or sandboxing experiments.
• Postgres ecosystem — Works with everything Postgres: Prisma, Drizzle, psql, pgAdmin, pgvector (vector similarity), PostGIS (geospatial), and hundreds of extensions.

Limitations

• Cold starts — After a period of inactivity, compute scales to zero. The first query triggers a resume which takes 50-500ms on the free and Launch plans. The Scale plan can be configured for lower latency.
• Higher cost — Neon is the most expensive option, especially at scale. The $49 Scale plan with 10GB costs roughly 2x Supabase's $25 plan with 8GB.
• No integrated features — Neon is database-only. You need separate services for auth, real-time, storage, and serverless functions.
• Limited free tier — 0.5GB storage on the free plan is restrictive. A small production app will outgrow it quickly.

Best For

• Teams that need full Postgres compatibility
• Development workflows with branching and ephemeral databases
• Applications that need pgvector, PostGIS, or other Postgres extensions
• Teams that already use Prisma or Drizzle ORM and want native Postgres support
• Applications with bursty traffic that benefit from autoscaling compute

Supabase: Full-Stack Postgres Platform

Supabase wraps Postgres in a complete backend platform. It's the most feature-rich option — database, auth, real-time subscriptions, storage, Edge Functions, and AI/vector capabilities in one product.

Strengths

• All-in-one platform — Auth (GoTrue, works with OAuth providers), real-time (WebSocket subscriptions on database changes), storage (S3-compatible file storage), Edge Functions (Deno-based). You can build a complete backend without leaving Supabase.
• Row-Level Security (RLS) — Supabase's policy engine lets you define auth rules directly in the database. Combined with the client SDK, RLS queries are filtered server-side so users only see authorized data.
• Real-time at scale — WebSocket-based real-time subscriptions on database INSERT, UPDATE, DELETE, or even arbitrary Postgres changes. Broadcast and presence channels for collaborative features.
• AI/Vector ready — Built-in pgvector support for vector embeddings and semantic search. The Supabase AI SDK provides client-side vector search.
• generous free tier — 500MB database, 50K users, real-time, storage, and Edge Functions all free. One of the most generous free tiers in serverless.
• Dashboard + SQL Editor — A polished web-based SQL editor and database management dashboard.

Limitations

• Vendor lock-in — The tight integration means migrating away from Supabase means replacing multiple services. Self-hosting Supabase is possible (it's open source) but complex.
• No branching — Database branching is enterprise-only and less mature than Neon's implementation. Schema changes require manual management.
• Cold starts — Supabase Edge Functions have cold starts (though faster than Neon's). Postgres compute doesn't scale to zero like Neon's.
• Postgres version lags — Supabase runs PostgreSQL 15, while Neon is on 16+. The difference is minor for most use cases.
• Regional limitation — Multi-region deployment is enterprise-only. For a global application on the Pro plan, all traffic routes to a single region.

Best For

• Full-stack applications that want a single backend platform
• Projects that need auth, database, real-time, and storage integrated
• Applications using Row-Level Security for authorization
• Real-time collaborative features (chat, notifications, live updates)
• AI applications needing pgvector for semantic search
• Startups that want the fastest path from idea to production

Selection Matrix: Which Database for Your Use Case?

Use Case	D1	Neon	Supabase
Simple edge API	Best choice	Works	Overkill
Global read-heavy app	Best choice	Good (multi-region)	Works (single region)
Complex relational data	Limited	Excellent	Excellent
PR preview environments	Not supported	Best choice	Manual setup
Auth + real-time app	Not suitable	Needs external	Best choice
AI/vector search	Not supported	Excellent (pgvector)	Excellent (pgvector + AI SDK)
Geospatial data	Not supported	Excellent (PostGIS)	Excellent (PostGIS)
Budget-conscious startup	Cheapest	Most expensive	Best value
Rate-limited/API-style data	Works well	Good	Best via RLS

Ecosystem Integration

ORM Compatibility

ORM/Tool	D1	Neon	Supabase
Prisma	Via @prisma/adapter-d1 (limited)	Native (full support)	Native (full support)
Drizzle ORM	Via drizzle-orm/sqlite (limited)	Native (full support)	Native (full support)
Kysely	Native (SQLite variant)	Native	Native
Supabase JS SDK	N/A	N/A	Native
psql	No	Yes	Yes
pgAdmin	No	Yes	Yes

Serverless / Edge Runtime Integration

Runtime	D1	Neon	Supabase
Cloudflare Workers	Native (binding)	Via HTTP (driver)	Via HTTP (supabase-js)
Cloudflare Pages Functions	Native (binding)	Via HTTP	Via HTTP
Vercel Edge Functions	Via HTTP	Via serverless driver	Via supabase-js
Node.js	Via HTTP	Via @neondatabase/serverless	Via @supabase/supabase-js

Migration Paths

Each platform offers different migration experiences:

To D1 — Migrating from SQLite is straightforward: D1 uses the same SQLite dialect. From Postgres, you'll need to rewrite queries and adjust to SQLite's limited feature set. D1's wrangler CLI supports import/export of SQL files.

To Neon — As standard Postgres, migrations from any Postgres provider are simple. Use pg_dump/pg_restore or migration tooling like Prisma Migrate. Neon's branching makes it easy to test migrations before applying.

To Supabase — Supabase provides a migration workflow through its CLI. Migrating from other Postgres providers works via pg_dump. Migrating from Firebase or non-Postgres backends requires more work but Supabase provides migration guides and tools.

Frequently Asked Questions

Can I use the same Postgres extensions in Neon and Supabase?

Both support most popular Postgres extensions, but there are differences. Neon supports pgvector, PostGIS, pg_stat_statements, and hundreds more. Supabase similarly supports major extensions but maintains its own curated list. Check the specific extension compatibility for your use case before committing.

Which is best for a real-time chat application?

Supabase is the clear winner for real-time chat. Its built-in Realtime engine provides WebSocket-based subscriptions on database changes, broadcast channels, and presence tracking. Neon and D1 would require a separate WebSocket service or additional infrastructure.

Does D1 support foreign keys?

Yes, D1 supports foreign key constraints. However, they must be explicitly enabled per connection using PRAGMA foreign_keys = ON. D1 does not enforce foreign key constraints by default, which is consistent with SQLite behavior.

How does database branching work in practice?

With Neon, branching uses copy-on-write storage. When you create a branch, it initially shares all pages with the parent database. Only when you modify data on the branch does it create its own copies of the modified pages. This means creating branches is nearly instant and storage grows only with the data you change. In practice, you create a branch per feature or per PR, work on it, and discard it when done.

Can I self-host Supabase?

Yes, Supabase is open source and can be self-hosted using Docker. The self-hosted version includes all features: database, auth, real-time, storage, and Edge Functions. However, self-hosting requires significant operational expertise and infrastructure. The hosted version is the recommended path for most teams.

The Verdict

There is no single best serverless database in 2026 — the right choice depends entirely on your application's requirements:

Cloudflare D1 wins for edge-first applications and simplicity. If you're building on Cloudflare Workers or Pages, D1 provides the lowest-latency reads globally, the simplest pricing model, and zero cold starts. It's perfect for read-heavy edge APIs, caching layers, applications where the simplicity of SQLite is sufficient. For applications that need Postgres features, complex relational data, or storage over 100GB, look elsewhere.

Neon wins for teams that need full Postgres with modern developer workflows. Database branching is transformative for development teams. Combined with full Postgres compatibility, autoscaling compute, and a rich extension ecosystem, Neon is the best choice for teams that want production-grade Postgres without managing infrastructure. The higher cost and lack of bundled services are the tradeoffs.

Supabase wins for full-stack applications that want a complete backend platform. The bundled auth, real-time, storage, and Edge Functions dramatically reduce the number of services you need to manage. For startups and teams building complete applications, Supabase offers the fastest path to production with the best value. The tradeoff is vendor lock-in, regional limitations, and no branching on lower plans.

For additional context, see our full backend platform comparison for more hosting options, or our serverless hosting comparison to understand the frontend infrastructure landscape.