Serverless Databases: Neon vs Supabase vs Turso [2026]

Checked against official docs and pricing on May 10, 2026, these three platforms now sit in clearly different lanes. Neon is serverless Postgres built around branching and autoscaling, Supabase is a full backend platform wrapped around Postgres, and Turso is SQLite/libSQL optimized for edge, offline, and many-database architectures. Use this cheat sheet when you need a fast pick, the right CLI command, or a safe migration starting point.

• Neon favors branch-heavy Postgres workflows with pooled connections and autoscaling.
• Supabase adds platform primitives that can replace several extra services in one stack.
• Turso changes the database model entirely: think edge SQLite and replication, not hosted Postgres.
• Free plans, local tooling, and branching semantics differ enough that the wrong pick creates workflow drag fast.

Pick the Right Lane

The biggest mistake is treating these as interchangeable. Two are Postgres products with different opinions about developer workflow, while one is a distributed SQLite/libSQL system that unlocks a different app architecture.

Choose Neon when:

• You want Postgres previews that behave like real database branches.
• You care more about database workflow than bundled backend services.
• You need autoscaling, pooled connections, and fast branch creation in CI or preview deploys.

Choose Supabase when:

• You want one platform for database, auth, file storage, realtime, and edge functions.
• You like a strong local workflow with supabase init and supabase start.
• You want platform features to remove separate vendors early in a product build.

Choose Turso when:

• You want SQLite/libSQL close to users, devices, browsers, or agents.
• You expect many small databases instead of one large shared multi-tenant cluster.
• You need lightweight local development, point-in-time cloning, or replication-oriented edge patterns.

Install, Auth, and Branch

These are the shortest official paths to a useful first session in each toolchain.

Neon

brew install neonctl
neon auth
neon me
neon branches list
neon branches create --name feature/users --parent production
neon branches reset development --parent

Supabase

npx supabase init
npx supabase start
supabase link --project-ref <project-ref>
supabase db pull
supabase db push

Turso

brew install tursodatabase/tap/turso
turso auth login
turso db create my-db
turso db show my-db
turso db shell my-db "SELECT 1"
turso db tokens create my-db --read-only

Commands by Purpose

Use the live filter to narrow the table by vendor, task, or flag.

Grouped snippets

• Local-first work: supabase init, supabase start, turso dev --db-file local.db
• Preview environments: neon branches create, supabase branches create, turso db create --from-db
• Deployment and drift control: supabase db pull, supabase db push, supabase config push
• Access control: turso db tokens create --read-only, pooled or direct Neon connection strings, Supabase project linking and secrets

Configuration and Security

Configuration is where these platforms reveal their real personality. Neon wants you to think in connection strings and branches, Supabase wants project config plus platform secrets, and Turso wants you to choose between local file, local dev server, and remote database URLs.

Neon

• Use pooled connections when your app creates many concurrent connections.
• Use the serverless driver for JS and edge or serverless runtimes.
• Keep branch names environment-specific so connection routing stays obvious.

DATABASE_URL='postgresql://USER:PASSWORD@HOST/DB?sslmode=require'

import { neon } from '@neondatabase/serverless';
const sql = neon(process.env.DATABASE_URL);
const rows = await sql`SELECT * FROM users`;

Supabase

• Treat supabase/config.toml as code and push it deliberately.
• Link local projects before using remote database commands.
• Generate types after schema changes instead of hand-maintaining them.

supabase link --project-ref <project-ref>
supabase db pull
supabase gen types --linked --lang typescript > database.types.ts
supabase config push

Turso

• Decide first whether development should use a local SQLite file, turso dev, or the hosted database.
• Use read-only database tokens for app clients that never write.
• Pick locations intentionally when latency matters more than a single primary region.

turso dev --db-file local.db
turso db locations --show-latencies
turso db tokens create my-db --read-only --expiration 7d

Advanced Usage

• Neon: Branch creation supports --cu as a fixed size like 2 or an autoscaling range like 0.5-3. That is useful when preview databases need burst capacity without a permanently larger footprint.
• Neon: The serverless driver is designed for HTTP or WebSocket access from serverless and edge runtimes, which makes it a cleaner fit than forcing raw TCP everywhere.
• Supabase: Preview branches are separate environments with their own credentials and services. Treat them as app environments, not just schema diffs.
• Supabase: Branch usage is billed as branch usage, and preview branches are not covered by the project spend cap. Cleanup discipline matters.
• Turso: Branching is operationally just database creation from another database or from a point in time. That makes it simple, but it also means your merge workflow usually lives in migrations and application release steps.
• Turso: Row-read and row-write billing means query shape matters. A query can scan more rows than it returns, so indexing and access patterns affect cost directly.

Live Filter and Keyboard Shortcuts

If this page becomes your operational reference, keyboard speed matters more than memorizing every subcommand.

Official docs checked

• Neon pricing and Neon CLI branches
• Neon serverless driver and Neon connection guide
• Supabase pricing and Supabase CLI getting started
• Supabase branching and Supabase CLI reference
• Turso pricing and Turso authentication
• Turso db create, Turso db shell, Turso db tokens create, and Turso local development