Turso GUI: A Native SQL Client for Turso and libSQL

SQLly is a native Turso GUI and libSQL client for macOS, Windows and Linux. You connect with a database URL and an auth token instead of a username and password, and from there it behaves like the SQLite it is: same dialect, same schema browser, same IntelliSense. Turso is the distributed younger sibling of SQLite, and SQLly speaks the whole family, so your edge database and your local dev files live in the same window. Free tier, no account to start.

Why a GUI for Turso at all

The Turso CLI is good. I say that as the person who would like you to open it less often. turso db shell answers one question at a time; it will not show you the shape of a schema, diff a dev database against production, or page through forty tables hunting for the column you swear existed. That gap is what a desktop Turso client fills, and it is why I built the libSQL support.

Connecting to Turso: a URL and a token

There is no username in libSQL land: access is a bearer token, the address is a URL. The generic shape of it:

# from the Turso CLI, two commands get you everything:
turso db show <your-db> --url
#   libsql://<your-db>-<your-org>.turso.io
turso db tokens create <your-db> --read-only --expiration 7d
#   eyJhbGciOi... (a long token; treat it like a password, because it is one)

In SQLly: create a connection, pick libSQL / Turso, and either paste the full URL with ?authToken= or fill in host and token. Three details worth knowing:

• The token goes into your operating system's secure store, never into a file or an exported connection.
• Any *.turso.io host is contacted over HTTPS no matter what scheme you typed, so a token cannot accidentally travel in the clear.
• A read-only token plus SQLly's read-only connection setting is a pleasant belt-and-suspenders for poking at production.

Full walkthrough: Using a GUI with Turso and libSQL: URLs, tokens, transactions.

Local libSQL: sqld in Docker, or a plain file

You do not need Turso at all to use this. The libSQL server runs fine in Docker:

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

Connect to http://127.0.0.1:8080 with a blank token; sqld's default port is filled in for you. Because libSQL is SQLite under the hood, plain .db files open in SQLly's SQLite engine with the same tooling. Local dev database, staging on Turso, production on Turso: three connections, one dialect, one window.

Edge replicas and local SQLite in one app

Turso's pitch is databases close to your users, and embedded replicas take it further: your app keeps a local SQLite file that syncs from the primary, so reads never leave the device. Replicas are an SDK feature, not something a client creates or syncs. What a GUI adds: connect to the remote primary over HTTP, open local SQLite files alongside it, and use Schema Compare to keep the two in step.

What you get on libSQL

• Schema-aware IntelliSense: SQLly runs its SQLite catalog queries against libSQL, so completion and hover cards work as they do for a local file.
• Guardrails: a warning before UPDATE or DELETE without WHERE, read-only connections, and an auto-rollback wrap that shows what a write would do without keeping it.
• Transactions that behave: a multi-statement script runs as one unit, so BEGIN ... COMMIT works as long as you run the block together.
• EXPLAIN QUERY PLAN in a real plan view, Schema History snapshots, Data Compare, a test data generator.
• Honest limits: the server cannot interrupt a running statement, so Cancel abandons the request; a whole result arrives before its first row, so page big reads with LIMIT or keyset paging; and row editing in the grid is not available on libSQL yet.

When the Turso CLI or a smaller tool is enough

Stay with the CLI if your work is migrations, CI scripts and one-off turso db shell checks; it is genuinely the right tool there. Stay with Turso's web shell for a thirty-second look from a machine that is not yours. And if libSQL is the only database you ever touch, the small dedicated tools do one thing and do it fine. SQLly's case is the other situation: Turso sitting next to Postgres, MySQL, DuckDB or plain SQLite files, where one native app beats a shelf of single-engine viewers.

FAQ

Does SQLly work with Turso embedded replicas? No. Embedded replicas are an SDK feature inside your app: a local file that syncs from the remote primary. SQLly connects to the remote over HTTP and does not create or sync one. For inspecting data, the primary is the source of truth anyway.

Is my Turso auth token safe in SQLly? It is stored in your operating system's keychain, not in the connection file, and exported connections carry no token. Turso hosts are always reached over HTTPS, even if you paste a plaintext scheme.

Do transactions work over libSQL? Yes, with one rule: keep BEGIN and COMMIT in the same run. SQLly sends a multi-statement script as a single unit, so a transaction opened and committed in one run behaves, and the first failing statement stops the script with the server's own message.

Is SQLly free for Turso? The free tier covers two saved servers with unlimited databases on each, with a pay reminder about every five hours. Paid licenses are one-time: $100 for all 1.x updates, $200 lifetime. Details on the pricing page.

Try it on your own database

• Open the live preview: the real workbench in WebAssembly on sample data, no install or account. It demos the SQLite and Postgres engines; a libSQL connection needs the desktop app.
• Download SQLly for macOS, Windows or Linux.
• Create a read-only token, paste your libsql:// URL into a new connection, and you should be browsing tables a minute later. The libSQL engine page lists which tools apply.