Database guides

Turso / libSQL

Updated 2026-08-11 · 2 min read

A local libSQL database file. libSQL forks SQLite and keeps its on-disk format, so AddisDB opens the file directly with its SQLite driver.

libSQL is an open-source fork of SQLite, and Turso is the platform built on it. A libSQL database file uses SQLite’s on-disk format unchanged, so AddisDB opens it directly with its SQLite driver and the full SQLite toolset applies.

Who it is for

Turso suits applications that want SQLite’s simplicity with replication and remote access added — an embedded database that can also sync. The local file is the piece AddisDB works with, which is the right surface for inspecting a replica, a local development database, or a file pulled down from a remote database.

This entry is deliberately the local file only. Turso’s remote endpoint speaks HTTP rather than a database wire protocol, and reaching it needs a driver of its own that AddisDB does not have yet. To inspect a remote Turso database today, dump it to a local file first.

Getting a local file

  1. A local development database created by the libSQL client or the Turso CLI is already a plain file — note its path.
  2. To pull down a remote database, use the Turso CLI: turso db shell mydb .dump > mydb.sql, then load that dump into a local file.
  3. An embedded replica created by a libSQL client library is also an ordinary file at the path you configured.
# Dump a remote Turso database and rebuild it locally
turso db shell mydb .dump > mydb.sql
sqlite3 local.db < mydb.sql

Connect from AddisDB

  1. New Connection → Turso / libSQL.
  2. Choose the database file. There is no host, port or username — it is a file on disk.
  3. Test, then Save.

What AddisDB gives you

The full SQLite toolset: schema tree, in-grid editing, the structured create and alter table builders, mock data, and query plans through EXPLAIN QUERY PLAN, which shows which index each table is reached by.

Test clones work. AddisDB uses VACUUM INTO to write a transaction-consistent copy of the whole file to a throwaway database, so you can try a destructive change against a real copy of your data and drop it afterwards.

The Live Monitor reports table sizes, which is enough to drive size alerts, but a file has no sessions or running queries, so the session view says unsupported rather than inventing one. Database-user management does not apply — a libSQL file has no user system.