Edge Databases for Low-Latency Apps: D1, Turso, Neon Serverless

Edge compute solves one half of the latency problem: your code runs close to the user. The other half is data. A Cloudflare Worker that has to round-trip to a primary database in us-east-1 is no faster than a Lambda for a user in Singapore. The "edge database" category emerged to fill that gap — primary or replica data nodes co-located with edge compute regions, accessible with low latency from anywhere.

We've evaluated and shipped with three of them: Cloudflare D1, Turso (libSQL), and Neon Serverless. They solve overlapping problems with different tradeoffs. This is what we learned.

Why this category exists#

Traditional setup: your database lives in one region. Your edge code runs in 200+ POPs. The latency from a far POP to the database is whatever the inter-region link is (often 80–250ms). Your "edge function" is now slower than a Lambda right next to the database.

You want one of:

1. The database to be replicated to the edge (read replicas in many regions, with reads served locally, writes routed back).
2. The database itself to be serverless and globally accessible with low cold-start and good latency from anywhere.
3. Edge-native data primitives (KV stores, durable objects) that aren't quite SQL databases but solve similar problems.

The three products below take different approaches.

Cloudflare D1: SQLite at the edge#

D1 is Cloudflare's serverless SQLite, integrated tightly with Workers. Each D1 database has a single primary region (you pick when you create it) and read replicas in multiple regions. Reads from a region with a replica are fast; writes always route to the primary.

Best for: Cloudflare Workers apps with a strong-bias toward reads. Tightly integrated; no separate service to manage. Limits favor small-to-medium databases (current per-database storage cap is generous but real).

Where it surprises you:

• Writes can be slow from non-primary regions. A user in Sydney with primary in Tokyo writes at ~150ms minimum.
• Schema migrations are real (you're running SQLite; SQLite migrations).
• Storage per database has caps; very large datasets either split or move to a different system.
• Strong consistency is regional (write goes to primary; replicas catch up). Stale reads are possible from replicas immediately after a write.

We use D1 for one Worker-only feature with mostly-read traffic and small dataset. Works well. Wouldn't reach for it for write-heavy or multi-GB workloads.

Turso: libSQL with embedded replicas#

Turso is a libSQL (a SQLite fork) hosted service. It supports the "embedded replica" pattern: your application has a local SQLite file that's continuously synced from the primary. Reads happen against the local file (microseconds); writes go to the primary; the local copy stays consistent via the replication protocol.

Best for: applications that can host a local replica. Edge functions with persistent storage, Node servers, mobile apps. Read latency goes effectively to zero. Writes are still primary-bound.

Where it surprises you:

• The embedded-replica pattern needs persistent local storage. Edge functions that don't have that (e.g. ephemeral) lose the read-locality benefit.
• The libSQL fork adds capabilities to SQLite but means you're not running stock SQLite — driver support varies.
• Multi-region writes have the same latency story as D1: routed to one primary.

Turso shines when you can put the embedded replica inside your app's runtime. For a long-running Node service near users (e.g. on Fly.io), the read story is hard to beat.

Neon Serverless: Postgres, autoscaled#

Neon is serverless Postgres — autoscaled compute, separate from storage, with branching (forks) for development environments. Not a true "edge database" in the multi-region-replica sense, but the serverless compute + cold-start story makes it work well from edge functions when you're OK with the network round-trip to a specific region.

Best for: applications that need real Postgres (joins, transactions, all the SQL features). Edge functions that hit a single region's Neon endpoint. Pattern works well when the bulk of users are in one geographic area; less so for truly global low-latency.

Where it surprises you:

• It's still single-region (with optional read replicas in other regions, recently added). Cross-region latency is real.
• Cold-start latency is very low (we've seen ~50ms from zero) — much better than RDS in this regard.
• Branching is the killer feature for dev — every PR can have its own DB branch. Storage is shared so branches are cheap.
• Connection pooling: Neon has a pooler (pgbouncer-style) endpoint; using it well matters for serverless function patterns that don't reuse connections.

We use Neon for a couple of services where we want real Postgres semantics and the workload is regional. Not for global low-latency.

The other options#

A few we considered but didn't run with:

Cloudflare Durable Objects. A different primitive — strongly-consistent in-memory state with one canonical instance per "object." Good for coordination, counters, chat rooms; not really a database. We use them for some real-time state but not as a general data layer.

FaunaDB / DynamoDB Global Tables. Multi-region replicated databases. Real, mature, but the consistency models (eventual consistency in DynamoDB Global Tables; Calvin in Fauna) take effort to design around. We use DynamoDB Global Tables for one workload that fits its model.

PlanetScale. MySQL-compatible with global read replicas. Strong product; we use Postgres elsewhere so haven't migrated.

Self-hosted multi-region Postgres with Patroni or similar. Real but ops-heavy. For a small team, not worth it vs managed serverless.

How to pick#

Rough decision tree:

• All-in on Cloudflare Workers, small-medium dataset, read-heavy? D1.
• Need read-local with embedded replica, can host persistent storage? Turso.
• Need real Postgres, OK with one region (plus optional read replicas), value dev branching? Neon.
• Need true global writes with strong consistency? None of the above easily. Look at Spanner / Cosmos DB / Aurora Global, or rethink the architecture.

For most teams, the answer is: pick the database that matches your primary compute platform's locality model, with one region for writes and replication for reads. The cases where multi-region writes are actually required are rarer than the marketing suggests.

What we measure#

Per-database, the operational metrics:

• Read latency p50, p95, p99 by region. The "edge" claim is meaningful only if these stay low everywhere users are.
• Write latency from each region. Set expectations accordingly.
• Replication lag between primary and replicas. Stale reads are bounded by this.
• Connection error rate. Serverless databases can have transient connection issues during scale events.

Common mistakes#

Treating an edge database like a globally-strong DB. Writes have a primary region. Designing as if every replica was equally writable will bite you.

Heavy SQL with edge compute. Edge functions have tight CPU/memory budgets. A complex JOIN that takes 200ms of CPU in the function eats your latency budget regardless of how fast the database is.

Ignoring cold-start interaction. Serverless DB + serverless compute = 2 cold starts. Sometimes both fast, sometimes both not. Test from cold.

Replicating the primary database to every region "just in case." Costs money; rarely matches the actual access pattern. Replicate where users are.

What to read next#

• Cloud-native databases: choosing the right database for the workload — the broader DB choice
• Postgres connection pooling — PgBouncer in front of RDS — connection management is harder with serverless databases
• Edge computing with CloudFront and Lambda@Edge — edge compute alternatives
• AWS Lambda — optimization for cost and performance — when Lambda+regional-DB beats edge

Edge databases are a real category now, with credible options. The mistake is treating them as a drop-in replacement for traditional databases; the mental model needs to match the architecture. Once it does, the latency wins for global apps are substantial.