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, 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. 
import { createClient } from "@libsql/client";

const db = createClient({
  url: "file:encrypted.db",
  encryptionKey: process.env.ENCRYPTION_KEY,
});
The encryption key used should be generated and managed by you.

​
Extensions

If you’re looking to enable vector extensions, you should instead consider using the native libSQL vector datatype.
A full list of supported extensions can be found here.