Database guides

Turso Cloud

Updated 2026-08-11 · 2 min read

The remote half of libSQL — SQLite reached over the Hrana v2 HTTP protocol. Local libSQL files have their own entry.

Turso Cloud runs libSQL — a fork of SQLite — as a hosted service, reached over HTTP rather than a database wire protocol. AddisDB has a driver for it that speaks Hrana v2, libSQL’s HTTP protocol. The same driver connects to a self-hosted libsql-server.

This is deliberately a separate entry from Turso / libSQL (local file). A local libSQL file is SQLite on disk and is opened directly; a Turso Cloud database is an HTTP endpoint with a token. Different connection shapes, so different picker entries.

Who it is for

Turso suits applications that want SQLite’s model — one file, no server to tune — with replication and remote access added. Edge deployments and per-tenant databases are the common patterns, since creating a database is cheap enough to do per customer.

Set up the database

  1. In the Turso dashboard or CLI, note the database URL. It looks like libsql://my-db-org.turso.io.
  2. Create an auth token: turso db tokens create my-db.
  3. For a self-hosted libsql-server, the URL is your own host and the token is whatever you configured — a local server usually needs none.
turso db show my-db --url
turso db tokens create my-db

Connect from AddisDB

  1. New Connection → Turso Cloud.
  2. Paste the database URL into the connection string field.
  3. Paste the auth token into the password field. Leave it blank for a local libsql-server with no auth.
  4. Test, then Save.

What AddisDB gives you

Queries, the schema tree, exports and saved queries. Introspection reads sqlite_master and PRAGMA table_info, so the tree matches exactly what you would see opening the same database as a local file — including primary keys, NOT NULL and column defaults.

Mock data works through the shared in-database ledger, so generated rows can be removed again as a batch.

One detail worth knowing: libSQL sends integers as strings on the wire, because JSON numbers are floating point and would round a 64-bit id. AddisDB decodes them as exact integers, so a large primary key round-trips unchanged rather than losing its last digits.