Turso vs Supabase

Quick verdict

Turso now has several products, and the names matter. Turso Database is an in-process SQL database written in Rust and compatible with SQLite (MIT licence); its README says the Rust rewrite "replaces libSQL as our intended direction". It is pre-1.0 (v0.8.2 was released on 6 October 2026), although the project states it already powers production applications, including Turso Cloud. libSQL is Turso's earlier open source fork of SQLite (MIT); its README says it "is actively maintained, but new features are being developed in Turso". Turso Cloud is the managed platform that hosts both kinds of database, with branching, point-in-time recovery and analytics, and Turso Sync pushes and pulls changes between a local database file and the cloud.

Supabase gives every project a dedicated Postgres instance (Postgres 17 by default) and surrounds it with Auth, Storage, Realtime, Edge Functions, a PostgREST REST API and a GraphQL API. It is Apache-2.0 licensed and can be self-hosted with Docker, without some managed features.

For the engines underneath, see SQLite vs PostgreSQL. For another SQLite-based service, see Cloudflare D1 vs Turso.

Side by side

Key differences

Turso's products in 2026: Turso Database, libSQL and Turso Cloud

Turso began with libSQL, a fork of SQLite with additions such as embedded replicas, a server mode and an ALTER TABLE extension. It then rewrote SQLite in Rust as Turso Database, which adds BEGIN CONCURRENT for concurrent writes under MVCC, change data capture, asynchronous I/O on Linux with io_uring, vector support and experimental Postgres compatibility. Turso Cloud hosts both engines; its docs say "If SQLite's single-writer limitation is what would push you toward a client-server database like Postgres, Turso removes it."

Two changes are worth knowing before you read older tutorials. Turso's Edge Replicas feature (replicas in many locations) is deprecated for new users, and the multi-database schemas feature is marked deprecated. For data close to users, Turso now points to embedded replicas and, for new projects that need sync, to Turso Sync.

Database per user versus one shared database

Turso is built for many databases. The free plan allows 100 databases and paid plans are unlimited, so one database per user, tenant or agent is a practical design: each tenant's data is physically separate and can be deleted, branched or restored on its own. Supabase follows the usual SaaS pattern: one Postgres database holds all tenants, and Row Level Security policies tied to Supabase Auth keep each user's rows private. Creating a Supabase project per tenant is possible but each project adds hourly compute.

In our assessment, Turso's model suits apps where tenants never need to be queried together; Supabase's suits apps that need cross-tenant reporting, joins across all users, or Postgres features such as rich data types and extensions.

Local reads and sync

An embedded replica keeps a local database file in your app and syncs it from a Turso Cloud primary. Turso documents that "reads run locally from the file in microseconds, and writes are sent to the cloud primary", and that the replica that made a write sees it immediately. It needs filesystem access, so it does not fit serverless platforms without one, and the docs warn not to open the local file while it is syncing. With libSQL's TypeScript client (@libsql/client), as shown in Turso's SDK reference:

// TypeScript, @libsql/client: embedded replica of a Turso Cloud database
import { createClient } from "@libsql/client";

const client = createClient({
  url: "file:path/to/db-file.db",
  syncUrl: "libsql://[databaseName]-[organizationSlug].turso.io",
  syncInterval: 60,
  authToken: "...",
});

const result = await client.execute({
  sql: "SELECT * FROM users WHERE id = ?",
  args: [1],
});

Supabase has no local copy of the database: clients query over the network, usually through the auto-generated API, and Realtime pushes changes to subscribed clients.

Backend services and SQL features

Supabase's main advantage is everything around the database: Auth with users stored in Postgres, Storage for files, Realtime (Broadcast, Presence, Postgres Changes), Edge Functions and APIs your frontend can call. With Turso you add these yourself, for example an auth provider, object storage and your own API.

At the SQL level, Turso is SQLite-compatible, so SQLite's dialect, flexible typing and single-file model apply, while Supabase is full PostgreSQL. Turso Cloud also documents SQLite differences: PRAGMA user_version and application_id are read-only, and busy_timeout and journal_mode are not supported because Turso manages concurrency and journaling.

Pricing and licensing

Turso. Listed on the Turso pricing page in October 2026, in USD. Free: 0 USD per month, 100 databases, 5 GB storage, 500 million rows read and 10 million rows written per month, 3 GB of syncs, 1 day of point-in-time history. Developer: 4.99 USD per month (a saving is shown for yearly billing), unlimited databases, 9 GB storage then 0.75 USD per GB, 2.5 billion rows read, 25 million rows written then 1 USD per million, 10 days of history. Scaler: listed at 24.92 USD per month, 24 GB storage, 100 billion rows read, 100 million rows written, 30 days of history. Pro: listed at 416.58 USD per month, 50 GB storage, 90 days of history, priority support. Enterprise: custom. Turso states that all paid plans include branching and point-in-time restore.

Supabase. Listed on the Supabase pricing page in October 2026, in USD. Free: 0 USD, 500 MB database, 50,000 monthly active users, 1 GB file storage, 2 active projects, paused after 1 week of inactivity. Pro: from 25 USD per month including 10 USD of compute credits, 8 GB database, 100,000 MAUs, 100 GB file storage, 250 GB egress. Team: from 599 USD per month. Enterprise: custom. Compute is billed hourly per project.

In short, Turso bills by rows read and written and storage, with many databases included, while Supabase bills a plan plus always-on compute per project, with backend quotas included.

Pricing checked on the vendors' official pages on 7 October 2026. Prices change; confirm before buying.

Where each one leads

Limitations

When to choose each

When neither is right

• You deploy on Cloudflare Workers and want a SQLite database bound to the Worker: see Cloudflare D1 vs Turso.
• You want serverless Postgres with branching but no backend platform: see Turso vs Neon and Supabase vs Neon.
• You want a NoSQL mobile backend with offline sync: see Supabase vs Firebase.
• Your workload is analytics on local files: DuckDB fits better; see DuckDB vs SQLite.

Final recommendation

Frequently asked questions

Sources

• Turso pricing
• Turso docs: Turso Cloud
• Turso docs: Embedded replicas
• Turso docs: TypeScript SDK reference
• Turso docs: Edge Replicas (deprecated)
• Turso docs: Turso Cloud limitations
• Turso Database (GitHub repository, MIT)
• libSQL (GitHub repository, MIT)
• Supabase pricing
• Supabase docs: Compute and disk
• Supabase docs: Self-hosting

Checked October 2026.

How we research comparisons: our editorial method.