The free tier, checked against Turso's pricing page

Free-tier numbers drift, and this article carried three stale ones until we re-read the source. Pulled directly from turso.tech/pricing on 2026-08-31:

Two corrections worth stating plainly, since older versions of this page (and plenty of other write-ups) have them wrong: the free plan is 5 GB, not 9 GB — 9 GB is the paid Developer tier — and it allows 100 databases, not 500.

Even corrected, it's a generous tier: 100 separate SQLite databases and 500 million row reads a month costs nothing, and the per-database model suits multi-tenant apps where each customer gets their own file.

The number most likely to catch you out is 10 million writes per month. Reads are plentiful; writes are not. An app logging every request into SQLite will hit that ceiling long before it runs out of storage.

Turso turned SQLite from "the database inside your phone" into a globally-replicated database your serverless functions read from in ~5 ms. It's two layers: the open-source engine (libSQL, an Apache-2.0 SQLite fork that adds server mode, replication, native vector indexing, and an HTTP API — plus Limbo, a Rust rewrite with the same on-disk format), and the hosted platform with regional replicas and the free-tier ladder. Both engines are Apache 2.0, so you can self-host at any time.

Turso free Hobby plan at a glance

Limits have moved as the engine matured — the turso.tech pricing page is the source of truth — but the shape is stable: more databases than Postgres free tiers, more reads than write-heavy tiers, and the only major host where embedded replicas are first-class.

Why distributed SQLite is suddenly useful

• Read-heavy apps with cheap geographic distribution. Most traffic is reads (a typical SaaS is ~95% SELECT). Serving reads from a same-region replica drops p95 from ~80 ms to ~5 ms; writes forward to the primary.
• Per-tenant databases. Opening a new SQLite database costs about as much as creating a file, so "one database per customer" becomes feasible — perfect isolation, trivial export-on-cancellation, easier compliance — instead of one shared Postgres with row-level security.
• Embedded replicas. The libSQL client keeps a full local SQLite file synced with the cloud primary. Reads hit the local file at on-disk speed (single-digit microseconds) while writes forward to the cloud — a real read replica living inside your process, ideal for feature flags, config, dashboards, and knowledge bases.

The 60-second walkthrough

# macOS / Linux
curl -sSfL https://get.tur.so/install.sh | bash
# Windows PowerShell:  irm get.tur.so/install.ps1 | iex

turso auth signup                          # GitHub OAuth, Hobby plan by default
turso db create my-app --location lhr      # London primary
turso db replicate my-app fra              # add a Frankfurt read replica

npm install @libsql/client

import { createClient } from "@libsql/client";

const db = createClient({
  url: process.env.TURSO_DB_URL,        // libsql://my-app-yourorg.turso.io
  authToken: process.env.TURSO_AUTH_TOKEN,
});

await db.execute(`CREATE TABLE IF NOT EXISTS notes (
  id INTEGER PRIMARY KEY, body TEXT NOT NULL,
  created_at INTEGER NOT NULL DEFAULT (unixepoch()));`);
await db.execute({ sql: "INSERT INTO notes (body) VALUES (?)", args: ["First note."] });
const result = await db.execute("SELECT * FROM notes ORDER BY id DESC LIMIT 5");

The same backend works from Python, Rust, Go, PHP, or a raw HTTP POST. To switch to an embedded replica, just add a local file and a sync URL — reads then hit local.db directly while writes still commit to the cloud:

const db = createClient({
  url: "file:local.db",
  syncUrl: process.env.TURSO_DB_URL,
  authToken: process.env.TURSO_AUTH_TOKEN,
  syncInterval: 60,    // seconds; or call db.sync() manually
});

Vector search built into the schema

libSQL has a native vector type and nearest-neighbor index, so a RAG stack that normally needs a relational DB plus a separate vector DB (Pinecone, Qdrant, Chroma — see our free vector database guide) collapses into one schema:

CREATE TABLE chunks (
  id INTEGER PRIMARY KEY, doc_id INTEGER NOT NULL, body TEXT NOT NULL,
  embedding F32_BLOB(1024) NOT NULL    -- 1024 = Cohere embed-v3 dim
);
CREATE INDEX chunks_embedding_idx ON chunks (libsql_vector_idx(embedding));

SELECT id, body, vector_distance_cos(embedding, ?) AS d
FROM chunks
WHERE rowid IN vector_top_k('chunks_embedding_idx', ?, 10)
ORDER BY d LIMIT 10;

It uses a DiskANN-style ANN index, so it stays fast into the millions of rows, and the embedding is just a column you can JOIN, filter, and back up like any other. Pair it with Cohere's free embeddings API and the whole retrieval layer is one database with one SDK.

Database branches: Git, for schemas

Fork a database as a copy-on-write branch — the same preview-environment pattern Neon built for Postgres, plus the twist that your local dev database is itself just another branch:

turso db create staging --from-db production
turso db create pr-1234  --from-db production

Reading the free-tier edge

Reads are usually overprovisioned — 500 million/month is ~23/sec sustained; embedded replicas take repeat reads off the meter entirely. Writes are easy to burn — 25 million/month is ~9.6/sec, so append-heavy logs, event sourcing, or save-on-keystroke UIs can blow through it; plan to compact or move to the Scaler plan ($29/mo) before launch. Storage is generous and egress is unmetered inside Turso's network.

Where Turso wins, and where it doesn't

Wins when your workload is read-heavy (microsecond embedded-replica reads at zero cost), you ship to multiple regions (3 free replica regions), your model is per-tenant (100 databases = one isolated DB per customer), you want local dev identical to prod (same engine, no drift), you need a vector index beside relational data, or you value open-source portability.

Loses when you need Postgres-specific features (JSONB+GIN, PostGIS, tsvector FTS, partial unique indexes) — reach for Supabase or Neon; you have a single huge write-heavy table (SQLite serializes writes per database); you run real OLAP (use DuckDB/ClickHouse); or your ORM assumes the Postgres dialect.

Turso vs Supabase vs Neon vs Cloudflare D1

• vs Supabase: Supabase is a batteries-included Postgres platform (auth, storage, edge functions; 500 MB DB free). Turso is a database only, but a lot of it (5 GB across 500 DBs). Pick Supabase for a whole backend; Turso when the database is all you want.
• vs Neon: Neon is serverless Postgres with branching and scale-to-zero (free plan: 100 projects, each 0.5 GB and 100 CU-hours/month) — the closest Postgres analogue. If your team writes Postgres, Neon is lower-friction; if the per-tenant model resonates, Turso is more interesting.
• vs Cloudflare D1: D1 is also managed distributed SQLite (5M reads/day, 100K writes/day free) but lives inside the Workers ecosystem and has no embedded-replica equivalent. If your app is a Worker, D1 wins; if it's a Node/Python/Go process elsewhere, Turso's embedded replica wins on read latency.

The per-tenant SaaS pattern

Turso's standout architecture: give every customer their own database. On signup, create a database from a template schema and store its token; on each request, connect to that tenant's database.

// On signup
const dbName = `tenant-${tenantId}`;
await turso.databases.create({ name: dbName, group: "production", schema: "base-schema" });
const token = await turso.databases.createToken(dbName);
await saveTenantConnection(tenantId, dbName, token);

// On every request
const tenantDb = createClient({ url: tenant.dbUrl, authToken: tenant.token });
await tenantDb.execute("SELECT * FROM contacts");

You get five things free: no cross-tenant query risk, trivial export ("here's your SQLite file"), trivial GDPR delete ("drop the database"), per-tenant backups, and per-tenant schema evolution. Hobby supports 500 such customers. To watch which queries are slow once you have users, the Turso dashboard surfaces per-database metrics; instrument LLM features with a free tracing layer like Langfuse.

FAQ

Do I need a credit card?

No. The Hobby plan is signup-with-GitHub, no payment method, and you can stay on it indefinitely.

Is libSQL the same as SQLite?

libSQL is a fork that stays on-disk-format compatible — a SQLite file opens in libSQL and vice versa (unless you use libSQL-only extensions like the native vector index). It adds server mode, replication, vector indexing, an HTTP API, and WASM UDFs that upstream SQLite declined.

What does "embedded replica" mean in practice?

Your app process keeps a local SQLite file synced with the cloud primary. Reads hit the local file at on-disk speed; writes forward to the cloud and replicate back. The file is durable across restarts, so only the first launch pays the full sync cost.

Can Turso handle vector search at scale?

Yes for typical RAG corpora (tens of thousands to a few million chunks) — libsql_vector_idx is an approximate-nearest-neighbor index, so query time stays sublinear. For hundreds of millions of vectors, a purpose-built vector database is still the right call. Vector storage counts against the 5 GB limit and queries count as normal reads — no separate pricing.

Can I use Turso from serverless (Workers, Vercel, Netlify)?

Yes — the libSQL HTTP client works in any environment that can make HTTPS requests, with a request-scoped connection model that suits serverless far better than databases needing a long-lived socket.

Getting started

Three commands: curl -sSfL https://get.tur.so/install.sh | bash, turso auth signup, turso db create my-app --location lhr. Install @libsql/client (or your language's SDK), pass the URL and token, and write SQL. When you want zero-latency reads, add syncUrl and the same database becomes an embedded replica in your process. The free tier carries you far enough to ship.

Related Reads

• Supabase vs Neon: Free PostgreSQL Database Compared
• Qdrant vs Pinecone vs Chroma: Free Vector DB for RAG
• Cohere Free API: Embedding and Rerank for RAG
• Free Web Hosting for Developers: 7 Platforms Tested
• Render Free Hosting Review: Web Apps, Postgres, Limits