best serverless databases for edge functions

Edge functions promise single-digit-millisecond compute, but a database round-trip can blow that budget. If your function runs in 5 ms but waits 50 ms for a query to a centralized database, the edge advantage vanishes. The fix: serverless databases that replicate or proxy data to the edge, so reads and writes land close to the user.

This guide compares five options — Turso, Cloudflare D1, CockroachDB Serverless, Supabase, and ElectricSQL — by latency model, query language, free tier, and edge-platform fit. Each optimizes for a different constraint: raw read latency, ecosystem lock-in, consistency, full-stack simplicity, or offline-first sync.

> How we pick: We evaluated each database on its replication strategy, query language compatibility, pricing model, and how tightly it integrates with popular edge runtimes. We disclose affiliate relationships where applicable — some links below may earn us a commission at no cost to you.

What matters at the edge

Before the picks, here's the decision framework:

• Latency model. Read replicas near the user (Turso, D1) give the lowest read latency. Distributed SQL (CockroachDB) trades a few milliseconds for global strong consistency. Sync-based approaches (ElectricSQL) push data all the way to the client.
• Query language. SQLite/libSQL (Turso, D1) is lightweight and embeddable. Postgres wire protocol (CockroachDB, Supabase) means you can reuse existing drivers, ORMs, and tooling.
• Pricing model. Usage-based pricing on rows read/written (D1) can be cheaper for read-heavy workloads but unpredictable for writes. Free tiers (Turso, CockroachDB, Supabase) lower the barrier for experimentation.
• Edge-platform lock-in. Cloudflare D1 is native to Workers/Pages — seamless if you're there, irrelevant if you're not. Turso and ElectricSQL are portable across runtimes.

1. Turso — libSQL/SQLite at the edge

Turso is an edge-hosted database based on libSQL, a fork of SQLite, designed for low-latency access at the edge.1 Its standout feature is multi-region read replicas: you can place read-only copies of your database in dozens of locations worldwide, so edge functions anywhere get local reads without a cross-region hop.

Why it's the top pick: If the goal is ultra-low-latency reads from any edge runtime — Vercel, Cloudflare, Deno, Netlify — Turso is the most direct fit. SQLite's small footprint means each replica is cheap to operate, and the libSQL client libraries work across JavaScript, Go, Rust, and Python.

Trade-offs: Writes still go to a primary region, so write-heavy workloads won't see the same latency benefit. The libSQL ecosystem is growing but smaller than the Postgres world.

Best for: Read-heavy apps, content sites, user-preference stores, and any workload where the edge function needs sub-10 ms reads.

2. Cloudflare D1 — serverless SQLite native to Workers

Cloudflare D1 is a serverless SQL database built on SQLite, integrated directly into the Cloudflare Workers and Pages ecosystem.2 It features automatic read replication and Time Travel restores, and uses usage-based pricing on rows read and written.

Why it's here: If you're already on Cloudflare Workers or Pages, D1 is the path of least resistance. No external connection, no extra auth layer — your database binds directly to your function. Time Travel lets you restore to any point in the past, which is a genuinely useful safety net for schema migrations gone wrong.

Trade-offs: D1 is Cloudflare-native. If you later move your compute to Vercel or Deno Deploy, you'd need to migrate your data. The usage-based pricing on rows read/written is transparent but can surprise you on write-heavy or scan-heavy queries.

Best for: Teams already invested in the Cloudflare ecosystem who want a zero-config database alongside their Workers.

3. CockroachDB Serverless — distributed Postgres with global consistency

CockroachDB Serverless is a distributed SQL database that is PostgreSQL-compatible, allowing developers to use standard Postgres drivers for global scale.3 Key features include distributed SQL, high availability, Postgres compatibility, and a free tier.

Why it's here: When your app needs ACID guarantees across regions — think financial transactions, inventory, or any multi-region write workload — read replicas aren't enough. CockroachDB distributes writes across nodes and delivers strong consistency, so every read sees the latest committed write regardless of region.

Trade-offs: Distributed consensus adds latency compared to a local SQLite replica. You won't get single-digit-millisecond reads globally, but you get correctness. The free tier makes it approachable, but costs scale with storage and request units.

Best for: Apps where data correctness across regions matters more than raw read latency — payments, multi-tenant SaaS, collaborative tools.

4. Supabase — edge functions + Postgres, all-in-one

Supabase Edge Functions are TypeScript functions powered by Deno that run globally, designed to integrate deeply with Supabase's database and auth services.4 The platform pairs Deno-based edge compute with a managed Postgres database, plus auth, storage, and real-time subscriptions.

Why it's here: If you want edge functions and a database from one platform, Supabase is the most complete package. Your edge function can query Postgres using the Supabase client, enforce row-level security policies, and subscribe to database changes in real time. For teams that don't want to stitch together a database vendor, an auth provider, and a function runtime separately, this is the simplest path.

Trade-offs: The Postgres database is centralized (not edge-replicated by default), so you don't get the same read-latency profile as Turso or D1. You're also buying into the Supabase platform's opinionated stack.

Best for: Teams who want a full backend — database, auth, edge functions, storage — from a single provider without managing infrastructure.

5. ElectricSQL — durable Postgres-to-edge sync

ElectricSQL is a durable sync layer for Postgres that leverages replication streams to maintain strict schema consistency between cloud and edge.5 It integrates with PGlite (Postgres in the browser/edge via WASM) and supports partial replication, so only the data a client needs is synced.

Why it's here: ElectricSQL solves a different problem than the others: offline-first and local-first edge patterns. Instead of querying a remote database, the edge function or client runs queries against a local PGlite instance, and ElectricSQL syncs changes via durable replication streams. This means reads are instant (they're local) and writes sync when connectivity allows.

Trade-offs: This is a more architectural commitment — you're designing around sync, not just connecting to a database. The ecosystem is newer and less battle-tested than the others on this list.

Best for: Offline-first apps, local-first edge patterns, and use cases where the edge function needs to work without a network connection and reconcile later.

How they compare

Which one should you pick?

• Lowest read latency, any runtime → Turso. Multi-region SQLite replicas are hard to beat for read speed.
• Already on Cloudflare → D1. Zero-config, native binding, Time Travel. Don't overthink it.
• Need ACID across regions → CockroachDB Serverless. Strong consistency is the feature, not the trade-off.
• Want one platform for everything → Supabase. Database, auth, edge functions, storage in one place.
• Offline-first or local-first → ElectricSQL. Sync-based architecture with PGlite at the edge.

Edge functions only deliver on their latency promise when the database is equally close to the user. Each of these picks optimizes for a different constraint — and the right choice depends on which constraint is yours.