Databases Are Moving to the Edge — Turso, Neon, and Cloudflare D1 Are Rewriting Where Your Data Lives

For most of database history, the question of where your database lives has had a simple answer: in a data center, probably a region or two for redundancy, accessible to your application servers over a fast private network. The database is central. Everything connects to it. Latency between your app and your database is measured in sub-millisecond network hops within the same facility.

The problem with this model is that it doesn't account for where your users are. If your app servers are in us-east-1 and a user in Singapore makes a request, that request travels from Singapore to Virginia and back — roughly 200 milliseconds of round-trip latency before you've even thought about database queries. Modern serverless platforms and edge runtimes have pushed application code closer to users: Cloudflare Workers runs in 300+ locations, Vercel Edge Functions deploy in dozens of regions. But most apps still query a single Postgres or MySQL instance sitting in one region, erasing the latency benefit of edge execution the moment a database call is made.

Edge databases try to solve this by moving the data itself — or at least frequently accessed data — closer to users.

The Main Contenders

Turso is built on libSQL, a fork of SQLite with replication added. The architecture is straightforward: a primary database stores the authoritative copy of your data, and Turso automatically replicates it to edge locations close to your users. Read queries hit the nearest replica; writes go to the primary. Turso has deployed edge replicas in dozens of regions and makes the whole thing look like a standard SQLite connection from the developer's perspective. The price model is aggressive — a generous free tier, then per-database pricing. For applications with many isolated tenants (SaaS products where each customer gets their own database), Turso's model is compelling: you can have thousands of databases for very little money, each co-located near its primary user.

Neon takes a different approach: it's serverless Postgres, with storage and compute separated. Compute scales to zero when not in use (eliminating idle costs) and scales up within seconds when traffic arrives. The storage layer is durable, multi-tenant, and globally replicated at the block level. Read replicas can be deployed in any region. The developer experience is very close to standard Postgres — connection strings, psql, all the usual tooling works — which reduces the migration friction significantly. Neon's branching feature, which creates instant copy-on-write snapshots of your database for development or testing, has been widely praised.

Cloudflare D1 is also SQLite-based and deeply integrated with Cloudflare Workers. The pitch is simple: your Worker script runs at the edge, and D1 is right there with it. For queries that don't require global consistency, D1 eliminates the round trip to a central database entirely. D1 is currently limited in features compared to a full Postgres — no foreign key support out of the box, limited to SQLite's type system — but it's genuinely fast for reads when co-located with the edge Worker handling the request.

PlanetScale deserves a mention for a different reason: it announced in 2024 that it was ending its free tier and refocusing on enterprise customers. Several developers who had built projects on PlanetScale's MySQL-compatible service scrambled to migrate, and many ended up at Neon or Turso. PlanetScale's Vitess-based architecture offered horizontal scaling at a price point that turned out to be unsustainable. The episode was a useful reminder that free-tier database services are not a guaranteed foundation.

The Consistency Problem

Edge databases make a real tradeoff: distributing data for low-latency reads makes strong consistency harder to guarantee. This isn't a new problem — the CAP theorem has been a fixture of distributed systems education for two decades — but it's made concrete in edge database designs in ways worth understanding.

With Turso's edge replicas, a write committed to the primary may take a few hundred milliseconds to propagate to all edge replicas. If a user writes data and immediately reads it back, and the read hits a replica that hasn't received the write yet, they see stale data. For many applications — a blog, a product catalog, a social feed — this is acceptable. For applications where consistency is critical — a financial transaction, an inventory update with hard constraints — it's not.

Neon handles this differently. Its read replicas can be configured to be synchronous (guaranteed consistent) or asynchronous (lower latency, potentially stale). Most applications can use asynchronous replicas for read-heavy paths and route writes and latency-sensitive reads to the primary. The architecture is more flexible than Turso's but requires more explicit thinking about which queries need which consistency level.

Cloudflare D1's consistency model is scoped to a single region: writes to D1 are immediately visible to reads in the same region, but global consistency isn't guaranteed. Cloudflare's Durable Objects provide a different primitive for globally consistent state, but Durable Objects are not a relational database.

The SQLite Convergence

A striking pattern in the edge database landscape is how many of these products converge on SQLite as their underlying storage engine. Turso's libSQL, Cloudflare D1, Bun's built-in database, and several others all use SQLite or a derivative. The reasons are practical: SQLite is extremely fast for single-writer workloads, it's embedded in the application process (no separate server), and it's extraordinarily well-tested. The challenge has always been replication, which standard SQLite doesn't support — libSQL, LiteFS, and similar projects are working to fill that gap.

The emergence of SQLite as a serious production database engine — beyond its traditional role as an embedded local store — is one of the more interesting infrastructure trends of the last few years. It runs on everything from IoT devices to serverless edge functions, and its simplicity is increasingly a feature rather than a limitation.

When to Use It

Edge databases are a good fit for applications where users are globally distributed, read-heavy workloads are the norm, and eventual consistency is acceptable for most queries. SaaS products with per-tenant databases, content platforms with global audiences, and API backends serving mobile apps in many geographies are all reasonable candidates.

They're a worse fit for applications with complex transactions, strict consistency requirements across many users, or heavy analytical workloads. A financial ledger, an e-commerce inventory system under high concurrent writes, or a data warehouse should probably stay on a conventional centralized database — at least until the edge database ecosystem matures further.

The underlying pressure driving this shift isn't going away: users expect fast applications, and fast applications need data close to users. The edge database category is still young, the tooling is less mature than centralized Postgres, and some rough edges remain. But for the right workload, the latency improvement is tangible and real — and that's usually how infrastructure adoption starts.