libSQL

libSQL is an open-source, open-contribution fork of SQLite maintained by Turso. SQLite is one of the most widely deployed pieces of software in the world, but it famously does not accept outside contributions. libSQL was created to build on SQLite's exceptional foundation while opening it up to community improvements — and to extend it for modern use cases like remote access, replication, and WASM-based extensibility.

The libsql-server component (also known as sqld) is written in Rust and turns libSQL into a full network-accessible database server similar in spirit to PostgreSQL or MySQL, while retaining full SQLite file format compatibility.

Features

• SQLite compatible — reads and writes standard SQLite .db files; the entire SQLite API is preserved
• Server mode — libsql-server exposes a network endpoint (HTTP + WebSocket) so any client can connect remotely, not just local processes
• Embedded replicas — run a local in-process copy of a remote libSQL database that stays in sync automatically; local reads are instant, writes are forwarded to the primary
• WebAssembly UDFs — define custom SQL functions in any language that compiles to WASM, not just C
• ALTER TABLE extensions — supports modifying column types and constraints, a long-standing SQLite limitation
• Randomised ROWID — avoid ROWID enumeration attacks in multi-tenant scenarios
• Virtual WAL interface — pluggable write-ahead log for custom replication backends
• Multi-language drivers — official drivers for Rust, TypeScript/JavaScript, Python, and Go

Installation

libsql-server (sqld)

The server binary is built from the Rust workspace:

cargo install libsql-server

Or use the Docker image (works on all Linux distributions, including Debian and Fedora):

docker pull ghcr.io/tursodatabase/libsql-server:latest

docker run -p 8080:8080 \
  ghcr.io/tursodatabase/libsql-server:latest

libsql shell

# Build from source
git clone https://github.com/tursodatabase/libsql
cd libsql
cargo xtask build

Running the server

# Start a local server (in-memory, for development)
sqld --db-path :memory:

# Start a persistent server
sqld --db-path /data/mydb.db

# Start with HTTP basic auth
sqld --db-path /data/mydb.db \
  --http-listen-addr 0.0.0.0:8080 \
  --auth-jwt-key-file /etc/sqld/jwt.key

The server exposes an HTTP API compatible with the Hrana protocol, and also accepts standard SQLite-over-HTTP clients.

Using the shell

# Open an interactive SQL shell on a local file
libsql /path/to/database.db

# Connect to a remote sqld server
libsql --url http://localhost:8080

Embedded replicas in Rust

The embedded replica feature is one of libSQL's most compelling capabilities — your app holds a local copy of the database for fast reads, while writes are transparently forwarded to a remote primary:

use libsql::{Builder, Database};

#[tokio::main]
async fn main() -> anyhow::Result<()> {
    // Open an embedded replica — local reads, remote writes
    let db = Builder::new_remote_replica(
        "/tmp/local-replica.db",
        "https://your-db.turso.io".to_string(),
        "your-auth-token".to_string(),
    )
    .build()
    .await?;

    // Sync the local replica with the remote primary
    db.sync().await?;

    let conn = db.connect()?;

    // This read hits the local replica — microsecond latency
    let mut rows = conn
        .query("SELECT * FROM users WHERE active = ?1", [1])
        .await?;

    while let Some(row) = rows.next().await? {
        println!("{:?}", row.get::<String>(0)?);
    }

    Ok(())
}

WebAssembly UDFs

libSQL can load custom SQL functions compiled to WebAssembly, enabling user-defined functions in any language that targets WASM:

-- Load a WASM module as a UDF
SELECT load_extension('/path/to/my_function.wasm');

-- Use the function in queries
SELECT my_custom_function(column_name) FROM my_table;

Why fork SQLite?

SQLite is public domain and extremely well-engineered, but it is effectively controlled by a single author who does not accept external contributions. libSQL exists to:

1. Open the contribution model — accept community improvements that would otherwise never make it into SQLite
2. Add server capabilities — make SQLite-compatible databases accessible over a network without giving up the simplicity of the file format
3. Enable embedded replication — bring edge-native databases to applications that need both local speed and remote durability
4. Extend the extension model — WASM UDFs make the extension ecosystem far more accessible than the existing C-based loadable extension model

For the vast majority of workloads, libSQL is a transparent drop-in replacement for SQLite. The file format remains compatible, and the API is identical.