Edge Databases Compared in 2026: Turso vs Cloudflare D1 vs Neon

Three databases. Three takes on "data close to your users". All three matured significantly in 2025. In 2026 the question isn't which one is technically best, it's which one matches your application's shape.

What "edge" means here#

"Edge database" is a category with three distinct meanings, and the vendors overlap them in confusing ways:

1. Globally-replicated reads. A primary that accepts writes; read replicas in every region. Latency on reads is local; latency on writes is to the primary.
2. Local-first with eventual sync. The database lives in the same process as your application; writes happen locally and sync to a central source asynchronously.
3. Per-tenant locality. Each customer's database is placed close to that customer. Different customers live in different regions.

Each of our three picks emphasises a different one of these.

Neon#

Take: globally-replicated reads + branching. It's still Postgres; the "edge" story is that read replicas in multiple regions cut read latency for users far from your primary.

What Neon nails:

• Branching. The killer feature. Every PR can get its own database fork; preview environments use the same data as production without affecting it.
• Autoscaling compute. Compute pauses when idle. Hobby projects effectively cost zero when nobody's using them.
• Serverless driver. HTTP-based Postgres client that skips connection pooling entirely for one-off queries. The right primitive for Vercel-style serverless.
• It's real Postgres. Extensions, tooling, ecosystem all work.

What to know:

• Write latency from far regions still goes to the primary. "Globally-replicated" doesn't mean "global writes".
• Cold-start on a paused branch is faster than it used to be but not zero (~300ms-1s).

Pick if: you want Postgres, you want branching, you have world-spanning users.

Turso#

Take: per-tenant locality + embedded replicas. Each user (or each tenant) gets their own SQLite database. The application can hold an embedded replica that's synced from the primary; reads are local, writes go remote.

What Turso nails:

• Database-per-user economics. Tens of thousands of databases per account on the free tier. For consumer apps with isolated user data, the model is genuinely unique.
• Embedded replicas. Your app holds a local copy of the database, synced from the primary. Reads are microseconds. Writes round-trip.
• SQLite's small surface. Easy to operate, easy for agents to understand.
• Branching. Per-database; preview environments can fork.

What to know:

• One writer per database. Concurrent writes serialise. Hot rooms in a chat app, fast-moving order tables, etc. aren't a great fit unless you can shard.
• No row-level security as a Postgres-style primitive. Tenant isolation comes from the database-per-tenant model.
• Smaller ecosystem than Postgres. The fundamentals are there; the niche tooling is thinner.

Pick if: you have a per-user data model (notes app, personal CRM, single-player creative tools).

Cloudflare D1#

Take: SQLite living in Cloudflare's edge network, bound directly into Workers. Your database is a binding, not a connection string.

What D1 nails:

• Latency floor at the edge. Single-digit ms from any region when paired with Workers.
• Workers-native bindings. No connection pool, no IAM dance, no driver setup. The binding is in your code.
• Generous free tier. Pricing scales smoothly.
• Schema migrations via wrangler are functional.

What to know:

• D1 is tied to Cloudflare. If your compute is on Vercel or AWS, the cross-cloud round-trip cost cancels the edge benefit.
• Write throughput per database is capped. D1 is read-optimised.
• The ecosystem of libraries, ORMs, type-gen is improving but not at libSQL or Postgres parity.

Pick if: you're all-in on the Cloudflare stack.

Head to head#

The trade-offs side by side:

• Real Postgres: Neon. The other two are SQLite.
• RLS-style authorization: Neon. The other two rely on the database-per-tenant pattern or application-level checks.
• Per-user databases at scale: Turso.
• Lowest edge latency: D1 (when you're on Workers).
• Branching for preview environments: Neon and Turso both. D1 is catching up.
• Free tier generosity: all three. They've all converged on "free for hobby projects, pay when you have users".
• Vector search: Neon (pgvector). Turso has sqlite-vec; D1 doesn't natively.
• Ecosystem maturity: Neon > Turso > D1, in that order, by some distance.

The real question#

For most projects, the actual decision isn't edge vs not-edge. It's "do I have global users whose latency I care about?"

If yes, edge databases earn their keep. Pick the one that matches your stack and your tenancy model.

If no, most B2B SaaS, internal tools, regional consumer apps - a regular Postgres on Supabase or Neon is faster, simpler, and cheaper than any of the three. The edge story is a real win for a real set of workloads, but it's not most workloads. Optimise for what you actually have.