The Quiet Rise of Edge Databases

An edge database keeps data physically close to the people using it, the way a CDN keeps images and scripts close to them. Edge computing solved the “run code near users” problem years ago — serverless platforms now execute functions in hundreds of cities. But most of those functions still call a database sitting in a single region, and a round trip from Sydney to Virginia erases everything the edge won. The data layer had to follow the compute, and it has.

Why the database became the bottleneck

Move a function from a Virginia data center to one near the user and you cut the network hop from a couple hundred milliseconds to a few. But if that function still queries a Virginia database, every query pays the long round trip anyway. You moved the code, not the wait.

Chained queries make it brutal. A typical request isn’t one query — it’s several that depend on each other: load the session, then the user, then the user’s documents, then the permissions on those documents. Four dependent queries at 100 ms of cross-continent latency each is 400 ms of pure waiting, and they can’t be parallelized because each needs the previous result. The same four queries against a copy of the data in the same metro, at 2 ms each, cost 8 ms. That gap — two orders of magnitude on the hot path — is the entire reason edge databases exist.

Pattern 1: replicate reads, forward writes

The most conservative pattern keeps one primary region that accepts all writes and maintains read-only replicas in many regions. An edge function reads from the nearest replica, which is fast, and forwards any write to the primary, paying the long round trip only when data actually changes.

This matches how most applications behave — the overwhelming majority of queries are reads — and it keeps a familiar engine underneath. It’s ordinary PostgreSQL- or MySQL-style replication stretched across the planet, so schemas, transactions at the primary, and existing tooling all keep working.

Pattern 2: the database ships with the function

The second pattern embeds the database in the same place the code runs — usually SQLite or a derivative, because SQLite is a compact, serverless library rather than a database server. Each location works against a nearby copy, reads are local by construction, and changes sync in the background.

This is the model associated with Cloudflare D1 and with Turso and its libSQL lineage. It shares DNA with local-first software, which pushes the same idea to its logical end: the authoritative copy lives on the user’s own device, and the network exists for sync rather than for every read.

Pattern 3: keep each user’s data in one nearby place

The third pattern doesn’t copy data everywhere — it partitions it. Each user’s (or region’s, or document’s) data lives in exactly one location, chosen to be near whoever uses it. A request from Berlin touching a European user’s data stays in Europe end to end.

Cloudflare’s Durable Objects are the clearest expression of this: each object is a small unit of state with a single authoritative home, and requests route to it. Consistency gets easy because there’s only one copy — no replicas, no lag. The trade is that a user far from their data’s home pays the distance, and cross-partition queries become application work. Partitioning also happens to line up neatly with data-residency rules that require certain data to stay in certain jurisdictions.

The consistency trade-offs, in plain English

Physics doesn’t negotiate. Information can’t cross the planet instantly, so any system with copies in multiple places has to decide what happens in the gap.

• Replication lag. A replica always runs slightly behind the primary — typically a fraction of a second, occasionally more. Anything read from a replica may be stale by that much.
• Read-your-own-writes. The classic sharp edge: a user saves a change, which goes to the distant primary, and the next page load reads a nearby replica that hasn’t caught up — so the change appears to vanish. Systems mitigate this by routing a user’s reads to the primary briefly after they write, or by pinning a session to one copy.
• Stale reads vs. lost writes. Most applications tolerate reads that are a second stale; a comment appearing a moment late is a shrug. Almost none tolerate lost writes. That asymmetry is why the dominant designs relax freshness on reads but still funnel writes through something that durably acknowledges them.

Whether the store is relational or a key-value system — the SQL vs. NoSQL split — matters less here than where the copies live and which one accepts writes.

Do you actually need this?

Edge data pays off when three things line up: the workload is read-heavy, the audience is globally distributed, and the product is latency-sensitive. Content platforms, catalogs, configuration and feature flags, personalization, and session checks on every request all qualify.

It’s the wrong default when writes dominate (the primary round trip is the workload), when every operation needs strong consistency (inventory counts, account balances), or when your users are mostly in one geography anyway. A single-region database next to your application servers is simpler to operate, easier to reason about, and for most products entirely fine. Distribution is a tool, not a virtue.

The landscape, by category

The well-known names cluster by pattern rather than competing head-on:

• Managed relational with read scaling — Neon (Postgres) and PlanetScale (MySQL lineage) represent the serverless-database tier: a conventional SQL engine, operated for you, built to be reached from functions anywhere.
• Edge-native SQLite — Cloudflare D1 and Turso (built on libSQL) put an embedded database next to edge functions.
• Partitioned state — Cloudflare Durable Objects give each unit of data a single consistent home near its users.
• Globally replicated NoSQL — DynamoDB global tables are the long-running heavyweight, maintaining the same tables across regions.

If you want to feel the difference firsthand, deploying a small Hono API on Cloudflare Workers with an edge database behind it is a one-afternoon experiment.

The takeaway

Edge compute moved the code close to users; edge databases move the data, because a fast function in front of a distant database is still slow. Three patterns dominate — replicate reads and forward writes to a primary, embed SQLite alongside the function, or partition data so each user’s copy lives near them. All of them trade a little read freshness for a lot of latency while refusing to lose writes, and that trade suits read-heavy, global, latency-sensitive products far better than write-heavy or strongly consistent ones. Read locally, write to a primary, choose consistency per workload — that’s the pattern quietly becoming the default.