5 Cloudflare D1 alternatives for edge SQL workloads in 2026

Cloudflare D1 is easy to like. It gives you a serverless SQLite database, a generous free tier, and a query interface that lives one binding away from your Workers code. For a prototype or a read-heavy application, that combination is hard to beat, and it explains why so many teams start there.

It also explains why so many teams eventually search for a way out. D1 has a hard 10 GB cap per database, a single-writer architecture that processes queries one at a time, and an access model tied to the Workers runtime. When your data, your write volume, or your ambitions outgrow those constraints, the question stops being "which database" and becomes "which platform."

That platform question splits along a line most comparisons miss. Edge compute is really two markets wearing the same name. One runs code where web requests arrive, which is what a CDN is built for. The other runs code where calls, messages, and device events arrive, which is what a carrier network is built for. Real-time AI infrastructure, where telephony, inference, and state sit on one network, belongs to the second category, and it changes which database shape makes sense.

This guide compares five serverless SQL alternatives, starting with a per-entity database model that takes a structurally different approach and continuing through the strongest shared-database options. You'll find the per-actor SQL model Telnyx is building into its Edge Compute platform, then Turso, Neon, Supabase, and PlanetScale, along with a comparison table, honest tradeoffs for each option, a practical guide to migrating off D1, and a decision framework for whether you should switch at all.

Why developers look for Cloudflare D1 alternatives

D1 is generally available and widely used in production, so this is not a stability question. Its limitations are well documented, both in Cloudflare's own limits documentation and in production postmortems from teams that pushed it hard. The headline constraints are 10 GB per database, 1 TB of storage per account, single-threaded query processing per database, 100 columns per table, and a 30-second maximum query duration. Four of them come up again and again.

The 10 GB per-database ceiling

Each D1 database maxes out at 10 GB on the Workers Paid plan and 500 MB on the free plan. Accounts can hold up to 50,000 databases and 1 TB of total storage, so Cloudflare's answer to scale is horizontal: split your data into per-tenant or per-user databases.

That works, but it pushes sharding logic into your application. One developer documented manually sharding D1 across 50 databases to reach 500 GB of capacity, complete with hash-based routing baked into his UUIDs. It's a clever workaround, and it's also a lot of infrastructure code to write because the database can't grow past a fixed size.

Single-writer architecture and write throughput

Every D1 database is single-threaded and processes queries sequentially. Cloudflare's docs are direct about the implication: your maximum throughput depends on query duration, so a workload averaging 1 ms per query tops out around 1,000 queries per second, and slower queries reduce that ceiling proportionally.

Global read replication, added in beta via the Sessions API in 2025, helps read-heavy applications, but every write still routes to the single primary. Write-heavy workloads have no replication escape hatch.

Coupling to the Workers runtime

D1 is accessed through Worker bindings rather than a standard connection string. A REST API exists, but it routes through Cloudflare's control plane and carries meaningfully more latency than binding access.

SushiData, a team that ran more than 421 D1 databases in production, documented REST queries bouncing through multiple Cloudflare points of presence before reaching the database, along with the operational complexity of managing per-tenant databases at that scale. If your compute doesn't live on Workers, D1 is a hard sell. Every alternative below removes that constraint: Turso, Neon, Supabase, and PlanetScale all expose standard connection strings or HTTP clients usable from any runtime, and Telnyx Edge Compute runs functions and actors with state on Telnyx's own network.

SQLite feature gaps

D1 is built on SQLite but accessed through Worker bindings or an HTTP API rather than as a local file, which means it inherits SQLite's constraints: no stored procedures, limited ALTER TABLE support, and a smaller type system than PostgreSQL. SQLite is a superb engine within its design envelope, and the SQLite project's own guidance on appropriate uses is refreshingly honest about where that envelope ends. Teams that need Postgres extensions, rich JSON operators, or complex migrations eventually feel the difference.

The upside of that SQLite foundation shows up at migration time, since standard SQLite dumps work and moving to another SQLite-compatible platform requires no query rewrites.

None of this makes D1 a bad product. It makes D1 a product with a specific shape, and the alternatives below each reshape a different part of it.

Top 5 Cloudflare D1 alternatives compared

Here's how the five alternatives stack up at a glance.

Pricing reflects each vendor's published rates as of July 2026 and is worth confirming on their pricing pages before you commit.

1. Telnyx per-actor SQL puts the database inside the actor

Full disclosure first: this is our platform, and it's also the only entry on this list that isn't generally available yet. It leads the list because it takes a structurally different approach. The other four alternatives all improve on D1 within the same basic model, a shared database your code connects to. Telnyx is building something else on its Edge Compute platform: SQL as a property of a compute primitive rather than a service you connect to.

Telnyx Stateful Actors, currently in beta, give every entity in your application its own durable, addressable instance with one serialized owner for its state. The upcoming per-actor SQL capability embeds a SQLite database inside each actor. Every user, call, device, or agent gets its own transactional, queryable database, and because the database lives in the actor's process, there's no network hop between code and data.

You can run SELECT, JOIN, and GROUP BY against an entity's state instead of reducing it to key-value lookups. A standalone serverless SQL offering, a more direct D1 equivalent, is planned to follow.

The honest caveats: per-actor SQL is not yet generally available, and the ecosystem is younger than Cloudflare's. D1 counters with maturity, global read replicas, and 30-day point-in-time recovery. If you need a shared production SQL database today, one of the four options below is the pragmatic pick.

What makes the Telnyx model worth watching is what surrounds it. Actors and functions run at the same points of presence as Telnyx's carrier network, storage, and GPU inference infrastructure. For applications that answer phone calls, run AI agents, or process real-time media, state lives on the same network that handles the traffic.

Choose Telnyx if you're building agents or real-time applications where per-entity isolation matters more than a shared database, and where telephony, inference, and compute belong on one platform.

2. Turso brings libSQL with embedded replicas

Turso is the closest thing to a drop-in D1 replacement. It's built on libSQL, an open-contribution fork of SQLite, and it's designed around what Turso calls the many-database architecture: spinning up thousands of small databases, one per tenant or user, the same pattern Cloudflare recommends for D1 but with tooling built for it.

Turso's standout feature is embedded replicas, which place a copy of the database inside your application process for microsecond-class local reads while syncing writes to the cloud. Its free tier includes 100 databases and 5 GB of storage, and paid plans start at $4.99 per month.

Strengths: portable across any runtime via HTTP and native clients, strong CLI and developer experience, embedded replicas for extremely fast reads, and built-in vector search in libSQL.

Tradeoffs: libSQL is a fork, so there are minor API differences from stock SQLite, and calling Turso from a Worker adds an external network hop that a D1 binding doesn't have. It's also a younger company with a smaller ecosystem than Cloudflare's.

Choose Turso if you like D1's SQLite model and per-tenant database pattern but want it decoupled from the Workers runtime.

3. Neon delivers serverless Postgres with branching

Neon separates storage from compute to deliver PostgreSQL that scales to zero when idle and autoscales under load. Its signature feature is database branching: instant copy-on-write branches of production data for development, testing, and preview environments.

Neon's free plan includes 0.5 GB of storage and 100 compute hours per project, and its paid Launch and Scale plans are usage-based with no minimum monthly fee. After Databricks acquired Neon in May 2025, compute rates dropped 15 to 25 percent and storage fell to $0.35 per GB-month, which made always-on workloads noticeably cheaper than before.

Strengths: full PostgreSQL compatibility including extensions like pgvector and PostGIS, branching workflows no other vendor matches at the same polish, scale-to-zero economics for bursty workloads, and connection pooling included.

Tradeoffs: Neon is regional rather than edge-distributed, cold starts after scale-to-zero add latency to the first query, and an always-on database runs the compute meter continuously, which can exceed flat-rate options for steady-state workloads.

Choose Neon if D1's SQLite feature gaps are your main pain and you want real Postgres with a modern developer workflow.

4. Supabase bundles Postgres with a full backend

Supabase is less a D1 alternative than a backend alternative. It bundles managed PostgreSQL with authentication, object storage, realtime subscriptions, edge functions, and vector search into one open-source-flavored platform.

The free plan includes a 500 MB database across two projects, the Pro plan runs $25 per month with an 8 GB database included plus usage-based overages, and the Team plan jumps to $599 per month for compliance features like SOC 2 reporting and SSO. That gap between Pro and Team is worth noting. Most production apps live happily on Pro, but the next step up is a genuine budget line item.

Strengths: the most complete backend in one product, generous Pro-tier allowances, pgvector for AI workloads, and the option to self-host the open-source stack.

Tradeoffs: regional deployment rather than edge distribution, free-tier projects pause after a week of inactivity, and you're adopting a platform, not just a database, which cuts both ways.

Choose Supabase if you'd rather consolidate database, auth, and storage under one bill than assemble them separately.

5. PlanetScale runs MySQL and Postgres at serious scale

PlanetScale built its reputation on Vitess, the horizontal sharding system created at YouTube, and added managed PostgreSQL to its lineup in 2025. Its schema migration workflow remains the best in the business: branch the database, test changes against real data, and merge with non-blocking DDL and zero downtime.

PlanetScale removed its free tier in April 2024 and hasn't brought it back. Entry pricing now starts at $5 per month for a single-node Postgres instance meant for development, with production high-availability clusters starting around $15 per month for Postgres and $39 per month for Vitess-backed MySQL, plus metered storage.

Strengths: battle-tested horizontal scaling that makes database size effectively unbounded, the strongest schema change workflow available, and high-availability clusters with automatic failover.

Tradeoffs: no free tier, no edge distribution, and pricing that rewards disciplined query patterns but punishes unoptimized workloads.

Choose PlanetScale if you're planning for scale that would require sharding anywhere else and you want the platform to own that problem.

Shared databases vs. per-entity databases

There's an irony buried in Cloudflare's own documentation: D1 is described as designed for horizontal scale-out across per-user, per-tenant, or per-entity databases. In other words, even the shared-database vendor recommends the per-entity pattern once you hit real scale. The difference between platforms is who does the work.

On D1, per-entity architecture is a pattern you implement: provisioning databases through the API, maintaining routing tables or hash schemes, and managing thousands of bindings, which is exactly the operational load the SushiData and manual-sharding writeups describe. On Turso, tooling for many databases is first-class, which is a real improvement.

In the actor model, per-entity state is the construction itself. The entity and its database are one addressable unit, created on first use and reached by stable identity.

Where your compute runs shapes the same decision. A CDN-based platform executes code where web requests arrive, which is the right placement for serving websites. A carrier network executes code where calls, messages, and device events arrive, which matters when your application's traffic is a phone call rather than a page load.

The architecture of edge computing is ultimately about placing state and compute next to the events that trigger them, and different platforms sit next to different events. For a deeper look at how inference fits that picture, see how edge inference collapses the latency budget for voice AI by colocating models with the network.

If your application only serves web requests, a database on a CDN is a natural fit. If it touches the real world through calls, agents, or devices, it's worth asking whether your database should live where that traffic lands.

Other options worth knowing

Three more tools come up in D1 migration discussions and deserve a mention. CockroachDB offers distributed SQL with strong global consistency and a Postgres-compatible wire protocol, which is compelling for multi-region applications that can't tolerate data loss, though it's operationally heavier than most D1 refugees need.

Fly.io's LiteFS replicates a SQLite file transparently across regions for teams that want to run their own database, and Litestream streams SQLite's write-ahead log to object storage for backup and point-in-time recovery. Both are tools rather than managed services: excellent if you want control, wrong if you're leaving D1 to reduce operational load.

How to migrate off Cloudflare D1

Because D1 is built on SQLite, migration to any SQLite-compatible target is an export-and-import exercise rather than a rewrite, and even Postgres targets can consume a standard SQL dump with modest schema translation. The process looks the same regardless of destination.

Step 1: Export your data. Wrangler produces a standard SQL file containing schema and data:

npx wrangler d1 export <DATABASE_NAME> --remote --output=./d1_export.sql

For large databases, export table by table with the --table flag to stay under command timeouts.

Step 2: Review the schema. Moving to another SQLite-based platform, schemas and indexes typically transfer unchanged. Moving to Postgres or MySQL, review type affinities, auto-increment behavior, and any SQLite-specific pragmas before importing.

Step 3: Import into the target. Each platform has its own ingestion path: a CLI import command, a dashboard upload, or piping the dump through a standard client. Run it against a staging database first.

Step 4: Update the connection layer. This is where D1's binding model shows its coupling. Replace env.DB.prepare() calls with your new platform's client or a standard connection string. Your SQL itself should need little to no change for SQLite targets.

Step 5: Validate and cut over. Compare row counts and checksums between old and new, run PRAGMA integrity_check on SQLite targets, test read and write paths in staging, and then switch production environment variables. Keep the D1 database around in read-only fashion until you're confident, since exports are cheap and rollbacks are not.

When should you switch from Cloudflare D1?

Stay on D1 if your databases are comfortably under 10 GB, your workload is read-heavy, your compute is all-in on Workers, and the free tier or the $5 per month Workers Paid plan covers your usage. Read replication has made the read-heavy case genuinely stronger, and no alternative matches D1's price at small scale.

Switch if any of the following describes you: a database approaching the 10 GB cap, write throughput bumping against the single-writer ceiling, compute that lives outside Workers, a need for Postgres features that SQLite can't offer, a compliance requirement to control where data physically lives, or a roadmap that adds voice, agents, or real-time features that benefit from state living next to the traffic.

There is no single best alternative, only the one that matches the constraint you hit. Turso is the most direct replacement for SQLite at the edge. Neon and Supabase suit teams that want Postgres, PlanetScale suits MySQL shops operating at scale, and Telnyx per-actor SQL fits agent and real-time workloads that need per-entity state on a carrier network.

Build where your traffic lands

If D1 taught the industry anything, it's that developers want databases that appear instantly, scale per entity, and live next to their compute. The open question is which traffic your compute should live next to. For web pages, a CDN answers it. For calls, messages, agents, and devices, the answer is a carrier network with compute, inference, and state built in.

Telnyx Edge Compute runs serverless functions and Stateful Actors on the same private global network that powers Telnyx voice, messaging, and AI inference, with per-actor SQL on the way. Sign up for free to start building, or explore the Edge Compute documentation to see how the pieces fit together.