Turso vs Cloudflare D1 vs Neon 2026: Best Serverless Database for Next.js

Network cables in a data center representing serverless database infrastructure

Picking the database is one of the first real decisions you make when you start a new Next.js SaaS, and in 2026 the default has quietly shifted. The old answer was "a managed Postgres box somewhere." The new answer is a serverless database that scales to zero, bills by usage, and lives close to your edge functions. Three names dominate that conversation: Turso, Cloudflare D1, and Neon.

They are not the same kind of tool. Two of them are SQLite. One is full Postgres. One is welded to a specific runtime. This guide breaks down how each one actually works, what it costs, and the clear situations where one beats the other two — so you can choose once and not rip it out six months later.

The 30-second answer

If you remember nothing else: Neon for Postgres power, D1 for Cloudflare-native simplicity, Turso for edge-local reads and per-tenant databases.

How each one actually works

Turso (libSQL)

Turso is built on libSQL, an open-source fork of SQLite that adds the networking and replication SQLite never had. The headline feature is embedded replicas: your application keeps a real SQLite file locally, serves reads from it at memory speed, and syncs writes to a cloud primary that propagates back. Reads never cross the network. For read-heavy apps that is a dramatic latency win.

The second thing Turso does well is databases as a cheap primitive. Creating a database is close to free, so the database-per-tenant pattern — one isolated SQLite database for every customer — becomes practical instead of exotic. That is a genuinely different architecture than a single shared Postgres instance with a tenant_id column on every table.

Cloudflare D1

D1 is Cloudflare's SQLite database, and its defining trait is where it lives: inside the Cloudflare Workers runtime, backed by Durable Objects and Cloudflare's storage layer. You bind a D1 database to a Worker and query it with no connection string, no pooling, and no cold-start dance. Billing is based on rows read and rows written, and crucially there are no data egress or bandwidth charges for data read from D1.

In 2026 D1 also ships global read replication — read-only copies in multiple regions, with no extra per-replica fee (you still pay for the rows your queries touch). The trade-off is that D1 is only interesting if you are already committed to Cloudflare. It is not a general-purpose database you reach over the internet from anywhere.

Neon

Neon is serverless PostgreSQL — the real thing, not a SQLite dialect. It separates storage from compute so your database can scale to zero when idle and autoscale compute up under load. The feature everyone talks about is branching: a copy-on-write branch of your entire database in seconds, which makes per-pull-request preview databases and safe migration testing trivial.

Because it is Postgres, you get the whole ecosystem: extensions like pgvector for embeddings, mature SQL, and compatibility with every Postgres tool and ORM. After Neon's 2025 acquisition by Databricks, compute and storage prices dropped noticeably, which only strengthened the "just use Postgres" argument.

Side-by-side comparison

Pricing figures move; always confirm the current numbers on each vendor's pricing page before you commit. The shape of the models rarely changes, though: D1 and Turso bill by rows and storage, Neon bills by compute time and storage.

Latency: the real differentiator

For a serverless app, the question is not "how fast is the database" but "how far is the database from the code that queries it." That reframes everything.

A mismatch here is the number-one performance mistake teams make: a globally-deployed edge app talking to a single-region database in another continent. Co-locate, or replicate.

Code: the same query, three ways

All three pair beautifully with Drizzle ORM, which keeps your query code almost identical across engines.

// Turso (libSQL) with Drizzle
import { drizzle } from "drizzle-orm/libsql";
import { createClient } from "@libsql/client";

const client = createClient({
  url: process.env.TURSO_DATABASE_URL!,
  authToken: process.env.TURSO_AUTH_TOKEN!,
});
export const db = drizzle(client);

// Cloudflare D1 with Drizzle (inside a Worker)
import { drizzle } from "drizzle-orm/d1";

export default {
  async fetch(req: Request, env: Env) {
    const db = drizzle(env.DB); // DB is the bound D1 database
    const users = await db.select().from(usersTable);
    return Response.json(users);
  },
};

// Neon serverless Postgres with Drizzle (edge-friendly HTTP driver)
import { drizzle } from "drizzle-orm/neon-http";
import { neon } from "@neondatabase/serverless";

const sql = neon(process.env.DATABASE_URL!);
export const db = drizzle(sql);

The data-access layer looks nearly the same. What differs is the SQL dialect (SQLite vs Postgres), the driver, and where you run it. That is exactly why committing to an ORM like Drizzle early keeps your options open. If you are weighing ORMs, see our deep dive on Prisma vs Drizzle vs Kysely and the Drizzle vs Prisma for Next.js comparison.

Global network of connected points representing edge database replication

When to choose each one

Choose Neon if…

Neon is the lowest-risk pick for a serious SaaS. See how it stacks up against other Postgres hosts in Neon vs Supabase vs PlanetScale.

Choose Cloudflare D1 if…

If you are choosing your compute layer too, read Cloudflare Workers vs AWS Lambda vs Vercel Functions.

Choose Turso if…

The honest trade-offs

No tool is free of sharp edges.

Bottom line

There is no single winner, because these three target different shapes of problem:

Decide based on where your code runs and whether you need Postgres features, and the choice usually makes itself.

---

Building a Next.js SaaS and want a head start on the data layer? Browse production-ready starters on CodeCudos — including Drizzle ORM templates and starters and Stripe subscription SaaS boilerplates that wire the database, auth, and billing together so you can ship in a weekend.