● Beta — KubeEra is in active development. Profiles are live; AI-perception measurement is rolling out.
KubeEra
L

libSQL

Wasm
Open source · MIT

libSQL is an open-source fork of SQLite maintained by Turso.

updated 2026-07-01

What it is

libSQL is an open-source fork of SQLite maintained by Turso. It extends SQLite with features the upstream project has historically resisted or moved slowly on: native replication (embedded replicas that sync from a remote primary), a server mode with HTTP/WebSocket protocols for network access, and support for user-defined functions written in Wasm — which is why it's tagged under the Wasm category here rather than as a straight embedded-database entry. Core engine is still C, same as SQLite, so it inherits SQLite's file format and most of its SQL semantics. Think "SQLite plus the networking and extensibility layer SQLite never shipped."

Who builds it and why

Primarily built and driven by Turso (the commercial entity behind it), which sells a managed edge-database service on top of libSQL. The open-source project is the foundation for that product — classic open-core play. 156 contributors on GitHub is a healthy number for a systems-level C project, suggesting real outside contribution beyond just Turso employees, though the core architecture decisions almost certainly still run through Turso's team. CNCF maturity: not publicly available — this is not a CNCF project, it sits outside that governance model entirely.

Production readiness signal

16,923 GitHub stars and a commit as recent as 2026-07-01 indicate active, ongoing development — this isn't an abandoned fork. Latest release tag (libsql-server-v0.24.32) shows a sub-1.0 versioning scheme, which matters: treat this as still stabilizing, not a "done" database engine. MIT license is about as permissive as it gets, no copyleft concerns. Founding date: not publicly available, so you can't easily judge project age/maturity curve from that angle — go by commit history and release cadence instead. If you're evaluating this for production, pull the actual changelog between recent 0.24.x releases and check for breaking schema/protocol changes before you commit to a version.

Who should use this

  • Teams building edge or embedded applications who want SQLite's simplicity but need replication to a central primary without hand-rolling it.
  • Developers who want to extend query logic with Wasm functions instead of compiling custom SQLite extensions in C.
  • Projects already using Turso's managed service that want to self-host the same engine, or evaluate migration paths in either direction.
  • Anyone prototyping multi-tenant SQLite-per-tenant architectures where embedded replicas reduce latency.

Who should NOT use this

  • Teams that need a battle-tested, decades-proven engine for core transactional workloads — plain upstream SQLite has more scrutiny, more books written about its edge cases, and no version-0.x uncertainty.
  • High-write-concurrency, multi-writer workloads. This is still fundamentally SQLite's architecture; if you need real concurrent writers at scale, look at Postgres or a distributed SQL engine, not a SQLite fork.
  • Organizations that need vendor-neutral governance guarantees (e.g., CNCF-graduated projects) for procurement or compliance reasons — libSQL is single-vendor-driven, full stop.
  • Anyone who needs long-term API/protocol stability today. Sub-1.0 releases mean things can and do shift between minor versions.
  • Shops with zero appetite for C-level memory-safety review — if that's a hard requirement, look at Rust-based alternatives.

Alternatives

  • SQLite (upstream) — the original, more conservative, and still the safer default for pure embedded use cases without replication needs.
  • rqlite — a distributed SQLite built on Raft consensus, better fit if you need real distributed consistency guarantees rather than primary/replica sync.
  • Litestream — pairs with vanilla SQLite for continuous backup/replication to object storage, a lighter-weight alternative if you don't need libSQL's server mode or Wasm extensibility.

Pricing

The engine itself is fully open source under MIT — no cost, no feature gating in the codebase. Turso (the company) monetizes via a managed hosting service built on top of it; self-hosting libSQL directly costs nothing beyond your own infrastructure and ops time.

Frequently asked

What is libSQL?+
libSQL is an open-source fork of SQLite maintained by Turso.
Who builds libSQL?+
Primarily built and driven by Turso (the commercial entity behind it), which sells a managed edge-database service on top of libSQL. The open-source project is the foundation for that product — classic open-core play.
Is libSQL production ready?+
16,923 GitHub stars and a commit as recent as 2026-07-01 indicate active, ongoing development — this isn't an abandoned fork. Latest release tag (libsql-server-v0.24.32) shows a sub-1.0 versioning scheme, which matters: treat this as still stabilizing, not a "done" database engine.
Who should use libSQL?+
Teams building edge or embedded applications who want SQLite's simplicity but need replication to a central primary without hand-rolling it. Developers who want to extend query logic with Wasm functions instead of compiling custom SQLite extensions in C.
Who should not use libSQL?+
Teams that need a battle-tested, decades-proven engine for core transactional workloads — plain upstream SQLite has more scrutiny, more books written about its edge cases, and no version-0.x uncertainty. High-write-concurrency, multi-writer workloads.
What are the alternatives to libSQL?+
SQLite (upstream) — the original, more conservative, and still the safer default for pure embedded use cases without replication needs. rqlite — a distributed SQLite built on Raft consensus, better fit if you need real distributed consistency guarantees rather than primary/replica sync.
How much does libSQL cost?+
The engine itself is fully open source under MIT — no cost, no feature gating in the codebase. Turso (the company) monetizes via a managed hosting service built on top of it; self-hosting libSQL directly costs nothing beyond your own infrastructure and ops time.