Turso Alternatives - SQLite, Postgres and Edge Options

Turso alternatives fall into two groups. If you want to stay on SQLite, look at Cloudflare D1, self-hosted SQLite with Litestream-style backups, or PocketBase for a full backend in one file. If you are outgrowing SQLite's model or want relational features like row level security, roles and extensions, move to Postgres: Neon for serverless, StitchDB or Supabase for Postgres with auth, APIs and storage included.

The question got more attention in October 2026, when Turso announced it is joining Supabase. Turso says the platform keeps running and the database stays open source. So there is no emergency. But it's a good moment to check whether a per-tenant SQLite design is still what your app needs.

#What's happening with Turso

On October 2, 2026, Turso published Turso is joining Supabase to give every agent its own database. The key points from the post:

• "Turso keeps running": databases, APIs and workflows continue as before.
• Turso Database remains open source and actively developed.
• Supabase and Turso plan "deeper integration" and describe a path to standard Postgres for users who outgrow SQLite.

The post does not mention pricing changes. Turso's pricing page as of November 2026:

The prices on the page are shown with a discount note, so check the billing period there before you compare.

#Why people look for an alternative

Turso's strengths are real: cheap databases you can create by the thousand, embedded replicas that put reads inside your app process, and SQLite's simplicity. People look elsewhere when:

• They need many writers. SQLite historically allows one writer at a time per database. Turso 0.8 adds concurrent writes (its September 2026 release post covers it), but if you depend on Postgres-style concurrency today, Postgres is proven.
• They need security in the database. SQLite has no roles, grants or row level security. Every request runs with full access, so authorization lives in your API code.
• They want one database for analytics across tenants. A database per tenant makes "count orders across all customers" a fan-out job.
• They need extensions such as pgvector, PostGIS or full-text search with ranking across tables.

#Turso alternatives at a glance

#StitchDB: Postgres with the API already built

StitchDB gives each project a dedicated Postgres database plus Auth, REST and GraphQL APIs generated from your schema, Realtime, Storage and Edge Functions. It's hosted in the EU (Germany and Finland).

What maps to Turso features:

• Edge-style access over HTTP. The serverless driver in stitchdb-js/sql runs SQL over HTTPS and WebSockets from Cloudflare Workers, Vercel Edge and Deno Deploy, where TCP isn't available.
• Offline reads in the app. Offline sync keeps a copy of chosen tables on the device (IndexedDB in the browser, or a store you choose on mobile), with a conflict rule per table. It's the closest thing to Turso's embedded replicas, with your row level security applied to what each user receives.
• Multi-tenancy without a database per tenant. One schema, a tenant_id column and a policy.

A query from a Worker:

import { createSql } from 'stitchdb-js/sql'

export default {
  async fetch(req, env) {
    const sql = createSql(env.STITCHDB_SQL_URL)
    const rows = await sql`select id, title from notes where owner = ${'u_123'} limit 20`
    return Response.json(rows)
  },
}

The serverless SQL key runs as the database owner and bypasses RLS, so keep it on the server. For code on users' devices, use the REST API with the anon key.

Tenant isolation with a policy, using the Organizations helpers:

create table public.notes (
  id uuid primary key default gen_random_uuid(),
  org_id uuid not null,
  title text not null
);
alter table public.notes enable row level security;

create policy "members read their org's notes" on public.notes
  for select to authenticated
  using (auth.is_member(org_id));

Trade-offs: you don't get thousands of separate databases per account; a project is one Postgres database, and Free includes 2 projects while Pro includes 1 (extra projects $9/month each; see pricing). EU-only regions add latency for users on other continents. If your architecture truly needs one physical database per tenant or per agent, Turso or Neon fit better.

#Supabase

With Turso joining Supabase, some Turso users will move there naturally. Supabase is Postgres with Auth, Storage, Realtime and Edge Functions; Free has 500 MB per database and 2 active projects, paused after a week of inactivity; Pro starts at $25/month. Watch for the integration Turso and Supabase promised.

#Neon

If "many cheap databases" is the feature you love, Neon is the Postgres version of it. Free includes 100 projects with 1 GB each and 100 CU-hours per project. Computes scale to zero after 5 minutes and wake in a few hundred milliseconds. Paid plans are usage-based with no monthly minimum.

#Cloudflare D1

Cloudflare's managed SQLite for Workers. If your app already lives on Workers and you like SQLite, D1 keeps everything on one platform. Check Cloudflare's pricing page for current limits.

#PocketBase

An open-source backend in one file, built on SQLite, with auth, file storage, realtime subscriptions and an admin dashboard. It runs on one server you manage. PocketBase's own docs say it is still under active development, with no full backward compatibility guarantee before v1.0. Great for small apps and internal tools; see Supabase vs PocketBase.

#Plain SQLite on your server

Often overlooked: SQLite on a single VPS with a streaming backup tool is fast and nearly free. You lose managed backups, branching and remote access, and you own failover.

#Moving from Turso to Postgres

1. Dump the database with the Turso CLI (turso db shell <db> .dump > dump.sql) or the SQLite .dump command on a local replica.
2. Translate types. INTEGER PRIMARY KEY becomes bigint generated always as identity (or keep explicit ids), TEXT dates become timestamptz, and 0/1 integers used as booleans become boolean.
3. Merge tenants. If you had one database per tenant, add a tenant_id column and load each dump with that value set.
4. Load the data with psql or a tool such as pgloader.
5. Add policies so tenant isolation is enforced in the database, not only in code.

Read SQL vs NoSQL for mobile and web apps if you're also rethinking the data model.

#FAQ

#Is Turso shutting down?

No. As of November 2026, Turso says the platform keeps running after the Supabase deal, and Turso Database stays open source.

#What is the best SQLite alternative to Turso?

Cloudflare D1 for Workers apps, PocketBase for a self-hosted backend in one file, or plain SQLite with backups on your own server.

#Can Postgres do embedded replicas like Turso?

Not inside the database engine, but client-side offline sync gives a similar effect: StitchDB's offline sync keeps chosen tables on the device and syncs changes when online.

#Is StitchDB good for one database per tenant?

Not at Turso's scale. StitchDB is designed around one Postgres database per project, with tenants separated by row level security.

Want Postgres with auth and APIs already wired up? Start free on StitchDB.