SQL Studio: a single-binary database explorer for SQLite, Postgres, MySQL, ClickHouse, DuckDB and more

What sql-studio actually solves, and for whom

Most SQL clients make you choose a platform and a database engine before you choose a tool. sql-studio inverts that. The README describes it as a "Single binary, single command SQL database explorer", and the driver list is the point: SQLite, libSQL, PostgreSQL, MySQL/MariaDB, DuckDB, ClickHouse, Microsoft SQL Server, plus local Parquet and CSV files. Nine targets, one executable, one subcommand each.

The audience is narrow but real. Someone who has a .sqlite3 file on disk and wants to see its tables without opening a full IDE. Someone who has a Parquet export and no DuckDB CLI installed. Someone who wants to point a browser at a Postgres URL on a remote box and read the schema. The repository even carries a sample.sqlite3 at the top level, which suggests the maintainer expects people to try it against a file before wiring up a server.

What it is not: a migration tool, an administration console or a query library. The feature list in the README is four items, and three of them are read-oriented pages (overview, tables, queries). There is no mention of schema editing, user management or backups. Treat it as an explorer and the scope holds together.

How the Rust binary serves the UI, and why the build order matters

The architecture is visible in Cargo.toml. The server is warp, the runtime is Tokio, and the UI is embedded into the binary through the include_dir crate. That last dependency explains the contributing instructions: before cargo run works, you must build the frontend, because "the rust app statically embedded the UI files in the binary". The ui/ directory holds a separate npm project; the Rust side does not compile it for you.

Each database engine gets its own client crate rather than a shared abstraction: tokio-rusqlite with the bundled feature for SQLite, libsql for libSQL, tokio-postgres with tokio-postgres-rustls for PostgreSQL, mysql_async for MySQL and MariaDB, clickhouse for ClickHouse, tiberius with the tds73 feature for Microsoft SQL Server, and duckdb with the bundled and parquet features. TLS for the pure-Rust clients comes from rustls and webpki-roots, so certificate handling is compiled in rather than delegated to the system store.

The release profile is tuned for size: strip = true, opt-level = "z", lto = true, codegen-units = 1. That is a deliberate trade of compile time for a smaller artifact, which is consistent with the single-binary pitch. It also means local release builds are slow, and the dist profile softens this with lto = "thin" for packaged builds.

Installing sql-studio and opening your first database

The README gives three installation routes. On macOS and Linux, a shell script pulls the prebuilt binary for release 0.1.53:

curl --proto '=https' --tlsv1.2 -LsSf https://github.com/frectonz/sql-studio/releases/download/0.1.53/sql-studio-installer.sh | sh

On Windows, the equivalent PowerShell one-liner is:

powershell -ExecutionPolicy Bypass -c "irm https://github.com/frectonz/sql-studio/releases/download/0.1.53/sql-studio-installer.ps1 | iex"

Nix users can skip both and run it from nixpkgs:

nix shell nixpkgs#sql-studio

Once installed, the smallest real use is a local SQLite file. The README's first example is exactly this, and the repository ships sample.sqlite3 to point it at:

sql-studio sqlite sample.sqlite3

The binary opens a browser window by default. You should land on the overview page with table metadata, then be able to move to the tables page and the queries page, where the README promises "Rich SQL IntelliSense for custom queries".

For a server engine the pattern is the same with a connection URL. PostgreSQL, for example:

sql-studio postgres postgres://localhost:5432/

ClickHouse takes four positional arguments instead of a URL string, and Microsoft SQL Server takes a connection argument. Check the README block for the exact shape of each before you script it.

Running sql-studio in Docker against a remote Postgres

The Docker section is the only place the README explains the server flags, and it is worth reading closely because the binary's defaults assume a desktop. The published image is frectonz/sql-studio on Docker Hub, and the documented example runs the Postgres driver on port 3030:

docker run -p 3030:3030 frectonz/sql-studio /bin/sql-studio \
  --no-browser \
  --no-shutdown \
  --address=0.0.0.0:3030 \
  postgres \
  postgres://localhost:5432/

Three flags carry the weight here. --no-browser stops the container from trying to launch a browser it does not have. --no-shutdown keeps the process alive instead of exiting when the UI disconnects, which is what you want for a long-running container. --address=0.0.0.0:3030 binds outside the container loopback so the published port reaches it. Note that the connection string in the example points at localhost:5432, which inside a container means the container itself; a real deployment substitutes the host or service name of the database.

The README does not document authentication on the HTTP interface, TLS termination, or a health endpoint. If you expose port 3030 beyond your own machine, that gap is yours to close at the network layer.

Where sql-studio is the wrong tool

The clearest limitation is that the README documents reads, not writes. The four listed features are an overview page, a tables page, a queries page and an infinite scroll row view. Nothing in the README describes altering a schema, creating an index, managing roles or exporting results. A user who opens sql-studio expecting the administrative reach of a full client will be disappointed, and the project does not claim otherwise.

The second limitation is credential handling. Every server driver takes its connection string or password as a positional argument, as the ClickHouse signature (URL, USER, PASSWORD, DATABASE) makes plain. That means the password appears in your shell history, in the process list, and in any Docker command you save to a script. There is no documented secrets file or environment-variable path in the README, although clap is compiled with the env feature, so environment support may exist without being written down. Verify it in the source before you rely on it.

The third is documentation depth. The README points at an external documentation site, but the repository's own docs/ directory and README do not cover rollback, backup, multi-user access or error recovery. For a read-only explorer that is tolerable. For anything you would call operational infrastructure, it is not.

How sql-studio differs from a full database client

The obvious alternative is a mature desktop client for the engine you already use, such as the official Microsoft SQL Server tooling or a general-purpose GUI that speaks one protocol well. The difference in approach is architectural rather than cosmetic. A traditional client is a native application that connects directly from your machine and keeps a persistent connection profile on disk with saved credentials. sql-studio is a local web server: the Rust process holds the database connection and the browser is only a view onto it.

That distinction has practical consequences. The web-server model is what makes the Docker example possible at all, since you can run the binary next to the database and reach it over a port instead of opening a firewall rule from your laptop. It is also what makes the Parquet and CSV drivers coherent, because reading a local file through a browser tab is otherwise awkward.

The cost is that you inherit web-server concerns: binding addresses, port exposure, and the absence of documented authentication. A native client has none of those, at the price of a heavier install and one engine per tool. Neither model is better in the abstract. If your work is a single Postgres instance on your own machine, the native client is simpler. If your work is opening nine different file and server formats from one binary, the web-server model is the reason sql-studio exists.

Maintenance, releases and what the MIT licence leaves you

The last push to the repository was on 2026-08-26, and release 0.1.53 was published the same day, after 0.1.52 on 2026-08-25 and 0.1.51 on 2026-03-08. The gap between 0.1.51 and 0.1.52 shows the cadence is not fixed, so pin a version rather than tracking latest. The version in Cargo.toml matches the release tag, which keeps source builds and prebuilt binaries aligned.

Upgrades are handled by a companion binary the installer drops alongside the main one:

sql-studio-update

That command is the documented update path, and it is the reason the install script is worth preferring over a manual download. If you installed through Nix or Docker, you are on those ecosystems' update mechanisms instead, and the README does not claim sql-studio-update works for them.

The licence is MIT, which is permissive and places few obligations on how you redistribute or modify the binary. The repository also carries dist-workspace.toml and flake.nix, so both cargo-dist and Nix packaging are wired in. This is not legal advice, and if you embed the tool in a product you should read the LICENSE file at the repository root rather than a summary of it. One practical note: because the UI is statically embedded from the npm build, any fork that changes the frontend must rebuild ui/ before cargo build produces a matching binary.

Editorial conclusion

Adopt sql-studio if you want to open a SQLite file, a Parquet export or a Postgres URL in a browser without installing a heavyweight client, and if you are comfortable reading the source when the docs run out. Skip it if you need write-oriented administration, saved query management or a supported commercial product behind the tool. Before rolling it out, check the exact driver subcommand you need against the README, confirm the address and port your deployment will bind, and confirm that your database credentials are ones you are willing to pass on a command line.

Frequently asked questions

Official sources

1. frectonz/sql-studio on GitHub
2. License: MIT
3. Project website
4. README
5. Releases