Benchmarks comparing D1, PlanetScale and Neon tend to measure the wrong thing. Latency in microseconds, throughput in queries per second, results of synthetic queries — none of these numbers answer the question that matters: which of these three banks is right for what you're building now, considering where your data will grow, how much you want to pay while you have no traffic, and which SQL dialect your code assumes. There are three different architectures with different trade-offs, not performance variations of the same product.
D1: SQLite on the edge with zero cost to get started
The central argument of D1 is the native integration with Cloudflare Workers. When a Worker accesses a D1 database via binding, there is no TCP handshake, there is no connection string, there is no connection pool to manage. The query goes straight to the D1 binding in the same runtime context, with sub-millisecond latency to establish the call. In a serverless architecture where every millisecond of overhead matters, this integration is real and measurable.
The free tier delivers 5GB of storage, 5 million lines read per day and 100 thousand lines written per day — enough for development, internal tools and prototypes with low real traffic. On the paid plan: $0.001 per million lines read, $1 per million lines written, $0.75/GB-month of storage. Local development via wrangler dev --local creates a real SQLite file on the machine, with behavior parity with the remote database.
The limits that define where D1 is not useful: 2GB per bank, 10 banks in the paid plan, no custom SQLite extensions except sqlite-vec for vector search. A bank that grows beyond 2GB has no expansion path within D1 — you need to split the data or migrate to another bank before reaching the limit. For applications that will predictably surpass this ceiling, D1 is the right bank to start with and the wrong bank to hold for the long term.
PlanetScale: MySQL with horizontal sharding and schema branching
PlanetScale is built on Vitess — the same database infrastructure that scaled YouTube's MySQL to volumes that standard MySQL can't handle. This origin defines what PlanetScale offers: genuine MySQL (most ORMs work without modification), platform-managed horizontal sharding as data grows, and the schema branching workflow that distinguishes PlanetScale from any other database available today.
Schema branching works like version control for schema: you create a schema branch, apply the changes, test, and merge back to the main branch. The migration runs without locking tables — unlike MySQL's standard ALTER TABLE, which locks writes during execution. For teams that struggle with maintenance windows for migrations or that need to safely revert schema changes, this functionality solves a real problem.
Cost is the most important filter: PlanetScale ended the free tier in 2024. The Scaler plan starts at $39/month. For side projects and non-revenue early-stage applications, this floor eliminates PlanetScale as an option. For products with consistent revenue and teams that have MySQL experience, $39/month for what PlanetScale delivers is reasonable. The correct comparison is not with free D1, but with the cost of managing MySQL sharding manually when volume grows.
Neon: Real PostgreSQL with serverless compute
Neon delivers PostgreSQL — not a compatible subset, not SQLite with a MySQL interface, but the actual Postgres runtime. This distinction matters when what you need doesn't exist in any other database serverless: PostGIS for geospatial data, pg_trgm for fuzzy text search, pg_partman for automatic table partitioning, TimescaleDB for time series, complex window functions that SQLite performs with limitations.
Neon's serverless compute model — which scales to zero when there are no queries — puts it in an interesting position for applications with sporadic traffic: you pay for compute only when the database is being actively accessed. The Pro plan costs $19/month with 10GB of storage included. For teams that already have PostgreSQL code and need a serverless database without migrating the SQL dialect, Neon is the most direct path.
The downside compared to D1 in a Cloudflare Workers environment: Neon uses a connection pooler (Neon Proxy) accessed via the standard PostgreSQL connection string. There is no native binding like D1 has. The latency of establishing the connection to the Neon Proxy depends on which Neon region you have configured and where the Worker is running — it can be 10ms or 80ms depending on the topology, compared to sub-millisecond for D1.
The cost of migration between the three
Choosing a database at the beginning of a project has an implicit cost that only appears if the choice is wrong and you need to change. The three banks have asymmetric migration costs.
Moving from D1 to Neon is technically feasible but not trivial: wrangler d1 export generates a SQL dump in the SQLite dialect, which needs to be converted to PostgreSQL before importing. Most queries are supported, but specific SQLite behaviors — such as type affinity, the semantics of AUTOINCREMENT versus SERIAL, the handling of dates — require review on a case-by-case basis. The volume of adjustments depends on how much the code takes advantage of SQLite's peculiarities.
Moving from PlanetScale to any other database means moving from MySQL to SQLite (D1) or PostgreSQL (Neon) — different dialects with enough syntax divergences to require a real portability effort. If the code uses transactions with MySQL-specific syntax, MySQL string functions, or other proprietary features, the migration is more expensive.
The rule that simplifies the decision: if you are on Cloudflare Workers and your data fits in less than 2GB, D1 is the correct default. If you need PostgreSQL from the start — for extensions, for compatibility with existing tools, for queries that SQLite doesn't support well — start with Neon rather than migrating later. PlanetScale comes in when Vitess horizontal scaling is the requirement, not the price of entry. None of the three solve analytical workloads well — for this, the Cloudflare Analytics Engine or a specialized OLAP database is the shortest path.
Also read
- Email Routing vs Improvmx vs Forward Email: honest comparison
- Workers + D1 + KV + R2: composing bindings in the same service
- DNS proxied vs DNS only: what changes and when each mode makes sense
- KV vs R2 vs Cache API: When to use each Cloudflare storage tier
- Cloudflare D1: The SQLite database at the edge — and why 'edge' doesn't mean what it seems
- Cloudflare Load Balancing and Geo Steering: when DNS becomes an intelligent traffic layer