---
title: "Turso vs Cloudflare D1 vs Neon: Edge SQL Databases for 2026"
author: "Nate Laquis"
author_role: "Founder & CEO"
date: "2026-05-08"
category: "Technology"
tags:
  - edge database comparison
  - Turso vs Cloudflare D1
  - Neon serverless Postgres
  - SQLite edge replication
  - edge SQL latency
excerpt: "Edge databases promise sub-10ms reads for every user on earth. Turso, Cloudflare D1, and Neon each take a radically different approach to getting there. Here is how they actually compare in production."
reading_time: "13 min read"
canonical_url: "https://kanopylabs.com/blog/turso-vs-cloudflare-d1-vs-neon-edge-databases"
---

# Turso vs Cloudflare D1 vs Neon: Edge SQL Databases for 2026

## The Edge Database Landscape in 2026

The pitch is simple: put a database replica within 50 milliseconds of every user on earth, and your application feels instant. No amount of server-side rendering or CDN caching can substitute for a fast database read when the request actually needs dynamic data. That is why edge databases have gone from niche experiment to mainstream infrastructure in the span of two years.

Three products dominate this space today, and they could not be more different. Turso is built on libSQL, a fork of SQLite, and distributes embedded read replicas globally. Cloudflare D1 runs SQLite inside Cloudflare's Durable Objects layer, tightly coupled to Workers. Neon takes a completely different route: serverless Postgres with a separated compute-storage architecture, global read replicas, and database branching. Each one makes real trade-offs. Choosing the wrong one means either re-architecting later or paying for complexity you did not need.

![Modern data center with rows of illuminated server racks powering edge databases](https://images.unsplash.com/photo-1558494949-ef010cbdcc31?w=800&q=80)

This post is an opinionated comparison based on production experience with all three. I will cover architecture, latency, pricing, ORM compatibility, write consistency, and migration paths. If you are building something that needs globally fast reads and you want to understand the real trade-offs instead of the marketing pages, keep reading.

## Turso: libSQL and the Embedded Replica Model

Turso is built on libSQL, a permissively licensed fork of SQLite maintained by the Turso team. The fork adds a few things that stock SQLite cannot do: native replication, a remote access protocol (over HTTP and WebSockets), vector search extensions, and ALTER TABLE improvements. Everything else is SQLite. Your schema, your queries, your migration files, and your local development experience are all just SQLite.

The architecture is straightforward. You create a database that lives on a primary in one region. You then attach read replicas in additional regions. Turso handles WAL (write-ahead log) frame shipping from the primary to replicas automatically. Reads hit the nearest replica. Writes are routed to the primary, applied, and then replicated outward. Replication lag is typically under one second for most workloads.

### Embedded Replicas: The Killer Feature

Turso's most important feature is embedded replicas. Instead of your application making a network call to a remote database, Turso syncs a full libSQL database file to local disk on your application server. Your reads hit local disk. There is no network hop, no connection pool, no cold start penalty. Read latency drops from 5 to 50 milliseconds (typical for a remote database) to under 1 millisecond. For read-heavy workloads, this is transformative.

Embedded replicas work on Vercel Functions, Fly.io, Railway, and any platform that gives you a writable filesystem (or even just memory). The sync runs in a background thread and typically keeps the local copy within a few hundred milliseconds of the primary. You configure sync intervals, and the library handles conflict-free application of remote changes.

### Where Turso Gets Tricky

Writes always go to the primary. If your primary is in us-east-1 and your user is in Tokyo, that write crosses the Pacific. You will see 200 to 300ms write latency. Turso does not (and cannot, given SQLite's single-writer model) offer multi-region writes. For write-heavy applications, this is a hard constraint. For the 90% of web applications that are read-heavy, it rarely matters.

The other caveat: libSQL is a fork, not stock SQLite. If you depend on a SQLite extension that has not been ported to libSQL, you may hit a wall. In practice, the most popular extensions (JSON, FTS5, vector) all work, but it is worth checking your specific dependencies. For a deeper look at SQLite production patterns, see our [SQLite for production guide](/blog/sqlite-for-production-turso-litefs-d1).

## Cloudflare D1: SQLite Woven into Workers

Cloudflare D1 takes a different approach. Instead of distributing a database across a fleet of replicas, D1 runs a single SQLite instance inside a Durable Object (Cloudflare's strongly consistent compute primitive) and layers read replicas on top using the Sessions API. The tight integration with Cloudflare Workers is both the product's greatest strength and its most significant limitation.

When you create a D1 database, Cloudflare pins the primary to a single location (generally wherever the first write originates, though you can influence this). All writes go to that one Durable Object. Read replicas are distributed automatically across Cloudflare's 300-plus PoPs, so a user in Sao Paulo reading data gets it from a local replica rather than crossing the Atlantic.

### The Workers Integration Advantage

If you are already building on Cloudflare Workers, D1 is nearly frictionless. You bind a D1 database to your Worker in wrangler.toml, and you have direct access to a SQLite interface with no connection strings, no drivers, no pooling, and no cold start overhead. The database client is injected into the Worker's execution context by the runtime. Queries execute inside the same infrastructure that runs your application code.

This integration extends to Cloudflare Pages Functions, which means your full-stack Next.js or Remix app deployed to Pages gets D1 access with essentially zero configuration. For small to medium applications, this developer experience is hard to beat.

### Limitations You Will Hit

D1's row size limit is 1 MB. Its database size limit is 10 GB on the paid plan (2 GB on free). You cannot run D1 outside of Cloudflare's ecosystem. There is no TCP connection string, no way to connect from a traditional server, and no compatibility with standard SQLite drivers outside of Workers. If you want to query D1 from a Node.js backend running on Railway or Fly, you need to go through Cloudflare's REST API, which adds latency and complexity.

![Server room with blue lighting and organized rack infrastructure](https://images.unsplash.com/photo-1504868584819-f8e8b4b6d7e3?w=800&q=80)

Write throughput is another constraint. D1 processes writes sequentially on a single Durable Object. Cloudflare quotes 1,000 write operations per second as a practical ceiling. For most web applications that is fine, but if you are building anything with high write volume (analytics ingestion, real-time collaboration, IoT telemetry), D1 will not work.

Pricing is deceptively simple. The free tier includes 5 GB storage, 5 million row reads per day, and 100,000 row writes per day. The paid Workers plan ($5/month baseline) charges $0.001 per 1,000 rows read and $1.00 per million rows written. Storage is $0.75/GB/month. For low-traffic apps, D1 is essentially free. For read-heavy production apps processing millions of requests daily, the per-row-read cost adds up quickly.

## Neon: Serverless Postgres with Global Reach

Neon takes a fundamentally different path. Instead of SQLite at the edge, Neon offers full PostgreSQL (version 17 as of early 2026) with a custom storage layer that separates compute from storage. This separation enables features that neither Turso nor D1 can match: instant database branching, scale-to-zero, autoscaling compute, and point-in-time restore down to the individual transaction.

Where Turso and D1 bet on SQLite's simplicity and small footprint for edge distribution, Neon bets that PostgreSQL's feature richness is worth the heavier runtime. For many teams, that bet pays off. PostgreSQL gives you JSON operators, window functions, CTEs, materialized views, full-text search, PostGIS, pgvector, row-level security, and a twenty-year ecosystem of tooling and community knowledge. None of that exists in SQLite.

### Read Replicas and Edge Caching

Neon added global read replicas in 2025. You can place read replicas in multiple regions, and Neon routes reads to the nearest replica automatically when you use their connection pooler with the read replica endpoint. Typical read latency to a regional replica is 5 to 20ms. That is not as fast as an embedded Turso replica (sub-1ms), but it is fast enough that most users will not perceive the difference.

Neon also supports connection pooling via their built-in PgBouncer layer. This matters for serverless environments where connection limits are a real problem. A Vercel Function connecting to Neon goes through the pooler and avoids the "too many connections" errors that plague serverless Postgres deployments. If you have previously struggled with connection management on Supabase or direct Postgres setups, Neon's pooler handles it transparently.

### Database Branching

Neon's branching feature creates a copy-on-write clone of your entire database (schema and data) in seconds. Each branch gets its own compute endpoint. This is transformative for development workflows. Every pull request gets its own database branch with production-like data. Every migration can be tested against a real dataset before it hits production. Every preview deployment can run against an isolated branch.

For a broader comparison with other Postgres options, check out our [Neon vs PlanetScale vs Supabase breakdown](/blog/neon-vs-planetscale-vs-supabase).

### Where Neon Falls Short at the Edge

Neon is not an embedded database. Every query requires a network round trip. Even with read replicas in your region, you are looking at 5 to 20ms per query, not the sub-millisecond reads you get from Turso's embedded replicas or a local SQLite file. For applications that issue dozens of sequential queries per request (ORMs with N+1 patterns, for example), those milliseconds compound.

Cold starts are the other concern. Neon scales compute to zero after 5 minutes of inactivity by default. The first connection after a cold start takes 500ms to 2 seconds as compute spins up. For production applications with consistent traffic, this rarely matters. For low-traffic internal tools or staging environments, the cold start is noticeable.

## Edge Latency Benchmarks and Real-World Numbers

Marketing pages quote best-case numbers. Here is what I have actually measured across production deployments in 2026, testing from multiple global regions against all three databases.

### Read Latency (P50)

- **Turso embedded replica:** 0.3 to 0.8ms. This is a local disk read. Nothing over a network beats it.

- **Turso remote replica:** 4 to 15ms depending on proximity to the nearest replica region.

- **Cloudflare D1 with read replicas:** 3 to 25ms. Reads from nearby PoPs are fast. Reads that fall through to the primary are slower.

- **Neon read replica:** 5 to 22ms. Consistent and predictable, but always involves a network hop.

### Write Latency (P50)

- **Turso:** 8 to 280ms. Depends entirely on distance between the caller and the primary region. Same-region writes are under 10ms. Cross-continent writes are 200ms or more.

- **Cloudflare D1:** 15 to 200ms. Similar to Turso, with the added wrinkle that you cannot always control where the primary lives.

- **Neon:** 10 to 180ms. Slightly faster than SQLite options for complex writes because Postgres handles concurrent writes more efficiently, but single simple inserts are comparable.

### Cold Start Impact

- **Turso:** No cold start for embedded replicas. Remote connections via HTTP have negligible overhead.

- **Cloudflare D1:** Minimal cold start (under 50ms) because D1 is tightly integrated with Workers, which already have fast cold starts.

- **Neon:** 500ms to 2s cold start when compute has scaled to zero. Configurable, and you can keep compute always-on for $19/month or more.

The takeaway: if raw read speed is your priority and you can live with SQLite's feature set, Turso's embedded replicas are unbeatable. If you need Postgres features and can tolerate 5 to 20ms reads, Neon is excellent. D1 sits in between, fast for reads within Cloudflare's network but locked to the Workers ecosystem.

## Pricing Comparison: Free Tiers and Production Costs

Pricing is where these three products diverge sharply, and where the wrong choice can cost you ten times what you expected.

### Free Tiers

- **Turso:** 1 billion row reads/month, 25 million row writes/month, 9 GB storage, 500 databases, 3 replica locations. This is the most generous free tier in the edge database space by a wide margin.

- **Cloudflare D1:** 5 GB storage, 5 million row reads/day (roughly 150 million/month), 100,000 row writes/day. Generous for small apps, but the daily limits can trip you up if traffic spikes.

- **Neon:** 0.5 GB storage, 10 branches, 1 compute with autoscaling up to 2 CU. Limited storage but unlimited reads and writes within your compute budget. Scale-to-zero keeps costs at $0 when idle.

### Production Costs (Typical SaaS, 100K MAU)

For a SaaS application with 100,000 monthly active users, moderate read volume (500 million row reads/month), low write volume (5 million writes/month), and 5 GB of data:

- **Turso Scaler ($29/month):** Includes 100 billion row reads and 100 million writes. You will not exceed the included limits. Total: $29/month.

- **Cloudflare D1 (Workers Paid, $5/month baseline):** 500 million reads at $0.001/1K = $500/month in row reads alone. Plus $5 for writes. Total: roughly $505/month. This is where D1's per-row pricing gets painful.

- **Neon Launch ($19/month):** 10 GB storage and autoscaling compute. With 100K MAU, compute hours will likely push you to $40 to $80/month total depending on query complexity and concurrency.

The pattern is clear. Turso's flat-rate plans are the most cost-effective for read-heavy production workloads. D1 is cheapest at small scale but expensive at volume. Neon's compute-based pricing is predictable and scales smoothly, but you pay for the Postgres feature set whether you use it or not.

![Developer writing database queries in code editor on monitor](https://images.unsplash.com/photo-1461749280684-dccba630e2f6?w=800&q=80)

### Hidden Costs to Watch

Turso charges for replica regions beyond the included count. Adding ten replica regions on the Scaler plan will cost extra. Cloudflare D1 does not charge separately for replicas, but the per-row-read cost is the hidden tax. Neon charges for compute hours, and if you leave autoscaling uncapped, a traffic spike can run up a bill. Always set a max compute size on Neon.

## ORM Compatibility: Drizzle, Prisma, and the Ecosystem

Your choice of edge database will shape your ORM and migration tooling. Here is the current state of compatibility in 2026.

### Drizzle ORM

Drizzle has first-class support for all three. The `drizzle-orm/libsql` driver works with Turso (both remote and embedded replicas). The `drizzle-orm/d1` driver works with Cloudflare D1 inside Workers. The `drizzle-orm/neon-http` and `drizzle-orm/neon-serverless` drivers work with Neon over HTTP or WebSockets respectively. Drizzle Kit handles migrations for all three backends. If you pick Drizzle, you can switch between Turso, D1, and Neon without rewriting your query layer. This is a real advantage.

### Prisma

Prisma's story is more complicated. Prisma supports Neon natively via its standard PostgreSQL adapter, and Neon works perfectly with Prisma Migrate, Prisma Studio, and all standard Prisma features. Turso support arrived in 2025 via the `@prisma/adapter-libsql` driver adapter, but it uses Prisma's "driver adapters" feature, which means some advanced Prisma features (like interactive transactions) have limitations. D1 support exists via `@prisma/adapter-d1`, but it is the least mature of the three and has known issues with certain migration patterns.

If Prisma is non-negotiable for your team, Neon is the safest choice. Turso works well for most use cases. D1 with Prisma is usable but expect occasional friction.

### Other ORMs and Query Builders

Kysely supports all three through community adapters. TypeORM works with Neon (via its Postgres driver) but has no official SQLite-over-HTTP support for Turso or D1. Knex.js works with Neon and has experimental Turso support. If you are using a less mainstream ORM, check the SQLite-over-HTTP compatibility carefully before committing to Turso or D1.

For teams evaluating the broader serverless function landscape alongside these databases, our [comparison of edge function platforms](/blog/supabase-edge-vs-cloudflare-workers-vs-vercel-functions) covers how these databases integrate with different compute providers.

## Write Consistency, Migrations, and When to Pick Each

Understanding each database's write consistency model is critical before you commit to one for production.

### Write Consistency Models

Turso provides strong consistency on the primary and eventual consistency on replicas. After a write completes on the primary, replicas receive the update within one to two seconds under normal conditions. If your application reads from an embedded replica immediately after a write, it may see stale data. Turso provides a sync() method to force a replica refresh, and you can also read from the primary for critical post-write reads. This pattern (write to primary, read-after-write from primary, subsequent reads from replica) handles most consistency requirements.

Cloudflare D1 offers strong consistency for all writes because they go through a single Durable Object. Read replicas introduce eventual consistency for reads, with the same one-to-two-second lag. D1's Sessions API lets you pin a session to the primary for read-after-write consistency when you need it.

Neon provides strong consistency on the primary compute and near-instant replication to read replicas (typically under 100ms thanks to their storage-level replication). Neon's LSN-based consistency controls let you specify "read after this write" semantics on replicas, which is more sophisticated than what Turso or D1 offer.

### Migrating from Traditional Databases

If you are moving from a traditional PostgreSQL deployment (RDS, Cloud SQL, self-hosted), Neon is the path of least resistance. Your schema, your queries, your extensions, and your tools all carry over. Point your connection string at Neon, adjust your pooling configuration, and you are done. Migration effort: a few hours to a day.

Moving to Turso or D1 from Postgres means rewriting your schema for SQLite. SQLite does not support ENUM types, ALTER COLUMN, or most Postgres-specific features. Your migration tool needs to generate SQLite-compatible DDL. If your schema is simple (which most startup schemas are), this takes a day or two. If you lean on Postgres-specific features, it could take a week or more.

Moving from MySQL is similar. Neon requires translating MySQL idioms to Postgres (different auto-increment syntax, different string functions, different JSON handling). Turso and D1 require translating to SQLite. Neither path is painless, but both are well-documented.

### When to Pick Each Database

**Pick Turso** when you want the absolute fastest reads globally, your workload is read-heavy (90% or more reads), you are comfortable with SQLite's feature set, and you want the flexibility to deploy on any platform. Turso's embedded replicas are genuinely unique in the market, and the pricing is hard to argue with.

**Pick Cloudflare D1** when you are already building on Cloudflare Workers and Pages, your database is under 10 GB, write volume is moderate, and you value the tight integration with Cloudflare's ecosystem over portability. D1 is the lowest-friction option if you are already in the Cloudflare world.

**Pick Neon** when you need PostgreSQL features (joins across large tables, advanced indexing, extensions like pgvector or PostGIS), you want database branching for your development workflow, or you are migrating from an existing Postgres deployment. Neon is also the right choice if your team knows Postgres well and does not want to learn SQLite's quirks.

There is no universally correct answer. The right database depends on your read/write ratio, your team's SQL dialect preference, your deployment platform, and how much you value portability versus integration. If you are unsure which path fits your project, [book a free strategy call](/get-started) and we will help you evaluate the trade-offs for your specific use case.

---

*Originally published on [Kanopy Labs](https://kanopylabs.com/blog/turso-vs-cloudflare-d1-vs-neon-edge-databases)*