libSQL vs Turso

Short version: they are not two competing databases, so the comparison people search for is really three things. libSQL is the open source fork of SQLite (MIT licensed), including the sqld server you can run yourself. Turso is the company that created libSQL and operates Turso Cloud, the managed platform. And since 2025 Turso Database is also the name of a separate, from-scratch Rust rewrite of SQLite, formerly called Limbo, which Turso now describes as its intended direction. You can run libSQL without Turso the company. You cannot get Turso Cloud's platform features without Turso.

I run Layerbase, which hosts libSQL, so I have a stake in the hosting half of this. The naming and status section below is quoted from Turso's own repos and docs, and stands whether or not you ever use us.

Contents

• The three things people mean
• Turso Database: the Rust rewrite
• What libSQL gives you anywhere
• What only Turso Cloud gives you
• Turso pricing as of September 2026
• Which one you actually need
• Where Layerbase sits in this
• FAQ

The three things people mean

The confusion is mostly Turso's doing, and they would probably agree. The company named its new engine after itself, so "Turso" now means the company, the hosting product, and a database, depending on the sentence. Meanwhile libSQL was the thing that carried the Turso name for three years.

The practical version: if someone says "we use Turso," they almost certainly mean Turso Cloud, and the engine under it has historically been libSQL. If someone says "we use libSQL," they might mean Turso Cloud, a self-hosted sqld, a different host, or the embedded library linked into their app.

Turso Database: the Rust rewrite

This is the part that changed, and it is why the search query exists at all.

The libSQL repository now opens by pointing new users elsewhere: "If you're starting a new project, you probably want to look into Turso. libSQL is actively maintained, but new features are being developed in Turso." The docs put it the same way. The libSQL docs page says "If you're starting a new project, we recommend Turso Database," while keeping libSQL as the recommendation "For mission-critical workloads that need a battle-tested foundation today."

Turso Database is not a fork. The turso repository describes it as "a SQLite-compatible database rewritten from scratch in Rust" and says plainly that it "is not a fork of SQLite." Its README also says the rewrite "replaces libSQL as our intended direction."

Status, as of September 2026:

• Licence: MIT, same as libSQL.
• Version: the newest tag on the repo is v0.8.0-pre.11, published 2026-09-11. The README states "we have not yet reached 1.0," that "the project is under active development," and that "some features are explicitly marked experimental." It also says "Turso powers production applications today at multiple organizations."
• Compatibility target: the repo tracks SQLite 3.50.4.

Contrast that with libSQL's own cadence. The libSQL repository still takes commits (it was still taking pushes in September 2026), but the newest tagged libsql-server release is libsql-server-v0.24.32 from February 2025. That is the clearest single signal in this whole comparison: libSQL is maintained, it is not abandoned, and it is also not where the new work goes.

I want to be careful about what that does and does not mean. "Maintained but not the focus" is a normal and often fine place for a database you already run in production. It is a bad place to be if your plan depends on a feature that has not shipped yet. Pick libSQL for what it does today, not for a roadmap.

What libSQL gives you anywhere

Everything in this list works on a sqld you start yourself on a VM, on a laptop, or on any host that runs the upstream server. None of it requires Turso Cloud.

• Server mode. sqld speaks HTTP and WebSocket, so multiple processes connect over the network instead of fighting over a file lock. This is the single biggest difference from plain SQLite, and SQLite vs LibSQL goes through it properly.
• The client SDKs. @libsql/client for TypeScript and JavaScript, plus Rust and Go, with Python and C drivers listed as experimental. The client takes a url and an authToken and does not care who operates the server behind them.
• JWT auth. The server validates bearer tokens, which is how every hosted libSQL, ours included, gates access.
• Embedded replicas, as a protocol. The sync machinery is part of libSQL, which is why the local-first story exists at all. In practice the polished version of it is wired to Turso Cloud, which is the honest caveat on this bullet.
• Native vector search. F32_BLOB columns and distance functions in plain SQL, with no sqlite-vec extension to build and ship per platform.
• SQLite's file format and dialect. Your SQL, your migrations, and your .dump files all port. That is what makes moving between libSQL hosts a URL change rather than a rewrite.

The practical consequence: application code written against @libsql/client is portable by construction.

import { createClient } from '@libsql/client'

const client = createClient({
  url: process.env.LIBSQL_URL!,
  authToken: process.env.LIBSQL_AUTH_TOKEN,
})

const result = await client.execute({
  sql: 'SELECT id, email FROM users WHERE email = ?',
  args: ['ada@example.com'],
})

Point those two environment variables at Turso Cloud, at a sqld on your own box, or at a managed instance somewhere else. The code above does not change.

What only Turso Cloud gives you

This is the part worth paying for, if you need it. From Turso Cloud's docs, as of September 2026:

• Branching, described as "Create isolated Copy-on-Write branches super fast."
• Point-in-time recovery: "Restore your database to any point in time," with the retention window set by your plan.
• Sync and embedded replicas: "Keep devices in sync with each other on demand with Turso Cloud." Partial sync, conflict resolution, and checkpointing all have their own docs pages. If you are building a local-first or offline-capable app, this is the feature, and nobody else has a comparable turnkey version of it.
• The Platform API, which manages groups and databases programmatically. This is what makes database-per-tenant practical at scale: you create a database per customer from your own control plane instead of by hand.
• Bring-your-own-key encryption, team access controls, and per-database analytics.

One thing to correct, because our older posts leaned on it and so does a lot of writing about Turso: the hosted edge replica model is not the current story. Turso's Data Edge page now carries the notice "This feature is now deprecated for all new users. Existing users can continue to use Edge Replicas on Fly." The direction Turso points at instead is embedded replicas, where the replica lives inside your application process rather than in a Turso region near it. Multi-location groups still exist in the CLI and Platform API, but if you are choosing Turso in 2026 for "a database replica in fifteen regions," check what is actually on offer for a new account before you architect around it.

Turso pricing as of September 2026

All figures as of September 2026, from turso.tech/pricing, on the monthly billing toggle.

The free plan also allows 100 databases; the paid plans list databases as unlimited. Paid plans bill overage per unit above the included amounts (storage per GB, reads per billion rows, writes per million rows).

The number to read carefully is rows read, not requests. A row read is every row a query touches, including rows scanned and then discarded by a WHERE clause. An unindexed lookup that returns one row can bill thousands of reads, and a COUNT(*) over a date range costs whatever it had to walk. That is not a gotcha exactly, it is a metering choice with a real upside (you pay nothing for an idle database), but it means capacity planning on Turso is query-shape planning. Turso alternatives goes into the specific query patterns that surprise people.

Which one you actually need

Pick Turso Cloud when:

• You need embedded replica sync as a product feature, for a local-first, offline-capable, or device-sync application. This is the strongest reason on the list and there is no close substitute.
• You are running database-per-tenant at a scale where you create and destroy databases programmatically. The Platform API plus per-database billing is built for exactly that shape, and the free plan's 100 databases tells you what they optimize for.
• You want point-in-time recovery with a retention window you select, and copy-on-write branching, without operating any of it.
• Your workload is spiky and mostly idle. A metered plan genuinely is cheaper than a flat instance when the database does nothing most of the month.

Pick self-hosted or otherwise-hosted libSQL when:

• Your bill is dominated by reads, not by storage, and you would rather buy a fixed amount of machine than a number of rows.
• You want the database to be yours: a sqld process on a VM you control, backed up the way you back up everything else. It is a single binary, and you take on TLS, tokens, and backups in exchange.
• You need the database reachable from anything, without a platform SDK or control plane in the path.
• You are in development, tests, or CI, where a libSQL that starts in a second and costs nothing beats a cloud account.

Pick neither when one process owns the database file. That is plain SQLite, and reaching for a network layer you do not need makes the system worse. SQLite vs LibSQL is the post for that decision.

Where Layerbase sits in this

We host libSQL on Layerbase Cloud at a flat monthly price per instance, with no row-read meter and no request allowance. You pay for the instance to exist. libSQL is on the free tier, so you can put a real one up without a card. On the paid side Solo is $5/mo and Pro is $15/mo, taken from our own pricing page rather than typed from memory.

It is the upstream libSQL server, so your existing @libsql/client code moves by changing two environment variables:

LIBSQL_URL=libsql://your-db.cloud.layerbase.dev
LIBSQL_AUTH_TOKEN=your-token

The connection URL and a JWT auth token come from the dashboard's Quick Connect panel. Adding email and password auth to libSQL with Better Auth is a full worked example on the same setup, and the create flow will scaffold the Better Auth schema for you.

Branching works on our libSQL too: it is one of the 16 engines on Layerbase Cloud that branch, so you can fork a database for a migration test or a preview environment and throw it away. Locally, the Layerbase CLI runs the same libSQL server on your machine, which is the part that makes "develop locally, deploy the same engine" true rather than aspirational.

What we do not have, and you should know before you move:

• No embedded replicas. We run a primary you connect to over the network. If your application depends on a local replica that syncs, Turso Cloud is the right answer and I would rather you stayed there than found out after the migration.
• No multi-region placement. Your instance lives in one region.
• No point-in-time recovery to an arbitrary timestamp. We take backups; Turso restores to a moment.

If you are leaving Turso for the pricing model rather than for a missing feature, migrating from Turso to Layerbase walks the whole path, and layerbase.com/migrate/turso does the copy for you over HTTP. If you got here from the Cloudflare side of the SQLite world instead, Cloudflare D1 alternatives covers that one.

Create a libSQL instance if flat pricing is the thing you came for.

FAQ

Is libSQL the same as Turso?

No. libSQL is an open source fork of SQLite, MIT licensed, that anyone can run. Turso is the company that created it and operates Turso Cloud, the managed platform that hosts it. Since 2025 "Turso Database" is also the name of a separate Rust rewrite of SQLite from the same company, which is why the question keeps coming up.

Can I use libSQL without Turso?

Yes. The sqld server is MIT licensed and runs on any machine, the client SDKs connect to it with a URL and a token, and several hosts run it as a managed service. Nothing in libSQL phones home to Turso.

Is libSQL still maintained?

Yes, and its own repository is direct about the nuance: "libSQL is actively maintained, but new features are being developed in Turso." Commits still land, but the newest tagged libsql-server release is libsql-server-v0.24.32 from February 2025. Treat it as a stable thing to build on, not a fast-moving one.

Is Turso Database ready for production?

Turso says it powers production applications at multiple organizations, and also that it has not reached 1.0 and that some features are explicitly marked experimental. As of September 2026 the newest tag is a v0.8.0-pre prerelease. Its own docs recommend libSQL over it "For mission-critical workloads that need a battle-tested foundation today," which is a reasonable summary of where it stands.

What does Turso Cloud run, libSQL or Turso Database?

Both. Turso's docs describe libSQL as having "powered it for years," with Turso databases "now available on the platform as well." So the platform is the constant and the engine under it is in transition.

Does moving off Turso mean rewriting my application?

Usually not. @libsql/client is the standard client and talks to Turso Cloud, a self-hosted sqld, or a managed libSQL elsewhere with the same calls, so you swap the URL and the auth token. What does not move is anything built on Turso-specific infrastructure, embedded replica sync above all, because no other host offers an equivalent.

Does Turso still do edge replicas?

Not for new users. The Data Edge documentation says the feature "is now deprecated for all new users. Existing users can continue to use Edge Replicas on Fly." The current answer to the same problem is embedded replicas, which put the replica inside your application rather than in a nearby region.