libSQL
libSQL is SQLite for modern applications.
Turso is a distributed database built on libSQL, a fork of SQLite. It’s optimized for low query latency, making it suitable for global applications.
Postgres and MySQL have long vied for SQL dominance, while SQLite remains a favored choice due to its simplicity and reliability, often dubbed the “hello world” of databases.
libSQL is a fork of SQLite that aims to be a modern database, with a focus on low query latency and high availability. It’s designed to be a drop-in replacement for SQLite, and scales globally with Turso over HTTP.
tursodatabase/libsql
Browse the libSQL source code on GitHub, report issues, feature requests and contribute using pull requests.
Discord
Join the community on Discord to talk about the development of libSQL.
Why fork SQLite?
SQLite is open-source, not open-contribution, which makes it difficult to innovate and evolve with it.
Turso is committed to the open-source community, and we welcome contributions to libSQL. We’re also committed to keeping libSQL free and open-source, as well rejoining core SQLite if their policy changes.
Read the libSQL Manifesto for more details.
Turso vs. libSQL
Turso manages the distribution of libSQL instances, and provides a global HTTP API for querying and managing databases. It also provides a CLI, Web UI and HTTP API for managing databases, replicas using groups, and team management.
When you use Turso, you don’t need to worry about managing libSQL instances, or configuring replication. You can focus on building your application, and let Turso handle the rest.
SDKs are fully compatible with libSQL, whether you use self-hosted or Turso-hosted libSQL.
SQLite Compatibility
libSQL will remain SQLite compatible by providing the same API and file format, but with additional features and optimizations.
Encryption at rest
libSQL introduces an essential feature for production environments: encryption at rest. This feature enhances data security by encrypting database files, making them inaccessible without the correct encryption key.
libSQL’s encryption leverages existing, proven encryption solutions, integrating them directly into the fork of SQLite. The encryption is page-based, allowing for efficient data access without decrypting the entire file. Supported encryption standards include SQLCipher (default) and wxSQLite3’s AES 256 Bit, with further options for customization per database.
Extensions
Extensions are experimental. Join us on Discord to add your suggestions and feedback.
If you’re looking to enable vector extensions, you should instead consider using the native libSQL vector datatype.
| Extension | Version | Installed | Description |
|---|---|---|---|
| JSON | Built-in | Default | Work with JSON data in SQLite. |
| FTS5 | Built-in | Default | Full-text search and indexing. |
| R*Tree | Built-in | Default | Indexing and querying spatial data. |
| sqlite-vec | 0.1.0 | Opt-in | The Vector Search successor to sqlite-vss. |
| SQLean Crypto | 0.24.1 | Opt-in | Hashing, message digest, encoding, and decoding. |
| SQLean Fuzzy | 0.24.1 | Opt-in | Fuzzy string matching and phonetics. A fork of Spellfix1 with improvements. |
| SQLean Math | 0.24.1 | Opt-in | Advanced mathematical calculations. |
| SQLean Regexp | 0.24.1 | Opt-in | Regular expressions with SQLite. |
| SQLean Stats | 0.24.1 | Opt-in | Common statistical functions with SQLite. |
| SQLean Text | 0.24.1 | Opt-in | String manipulation (reverse, split) with SQLite. |
| SQLean UUID | 0.24.1 | Opt-in | Limited support for RFC 4122 compliant UUIDs. |
You can enable all extensions when creating a new database using the CLI or API:
If you already have a group created with extensions disabled, you can update all databases in a group to enable extensions:
Was this page helpful?