dblab: a terminal database client for PostgreSQL, MySQL, SQLite3, Oracle and SQL Server

What dblab solves, and who actually wants it

Most database work happens in one of two places: a heavyweight GUI that needs a desktop session, or a raw psql or mysql prompt that gives you no structure. dblab sits between them. It is an interactive terminal UI application for PostgreSQL, MySQL, SQLite3, Oracle and SQL Server, written in Go, and the README describes the motivation directly: the compiler produces zero-dependency binaries for multiple platforms, so the tool ships as one file you can copy onto a server. The target reader is a command line user who connects to local or remote databases, wants a sidebar of tables, a query editor, and result sets in tabs, and does not want to install a runtime or a driver stack. The README also states the app is fast and lightweight, which is a claim about the binary rather than a benchmark, and no numbers are given. The topics list on the repository points at cli, tui and tview, which matches the pitch: this is a terminal application first and a database abstraction second.

The architecture: Bubble Tea, sqlx, and one driver per engine

The dependency list in go.mod tells you most of the design. The interface is built on charm.land/bubbletea/v2, charm.land/bubbles/v2 and charm.land/lipgloss/v2, the Charm stack for terminal applications. Data access goes through github.com/jmoiron/sqlx over database/sql, with one driver per engine: github.com/lib/pq for PostgreSQL, github.com/go-sql-driver/mysql for MySQL, modernc.org/sqlite for SQLite3, github.com/sijms/go-ora/v2 for Oracle, and github.com/microsoft/go-mssqldb for SQL Server. modernc.org/sqlite is a pure-Go implementation, which is consistent with the zero-dependency claim: no cgo, no system SQLite library. Configuration parsing uses github.com/kkyr/fig, the CLI uses github.com/spf13/cobra, and credential storage uses github.com/zalando/go-keyring, which is what backs the connection profiles feature. The tree view in the sidebar comes from github.com/Digital-Shane/treeview/v2, and SQL is assembled with github.com/Masterminds/squirrel. The data flow is conventional: a connection string built from flags or a config file opens a sqlx handle, the sidebar queries the catalog for tables, and the editor sends statements through the same handle. The interesting part is that the UI and the database layer are cleanly separated, which is why the same binary can target five engines without five different front ends.

Installing dblab and running a first query

The README gives three installation paths. Homebrew works on Linux as well as macOS. The first block installs the cask from the project's own tap.

brew install --cask danvergara/tools/dblab

After that, dblab should be on your PATH. The README also offers a tap-then-install pair of commands and a manual binary release for Linux, macOS and Windows, plus a shell script for automated installation or update. The README warns to verify what you pipe into bash before running that script, which is reasonable advice for any curl-to-shell installer.

For a first connection, the Makefile in the repository shows the exact flag set the maintainer uses against a local PostgreSQL instance.

DBLAB_DEBUG="" ./dblab --host localhost --user sakila --db sakila --pass sakila --schema public --ssl disable --port 5432 --driver postgres --limit 50 --save-as sakila -k

The flags map one to one onto the help output: --host, --user, --db, --pass, --schema, --ssl, --port, --driver and --limit. The --limit flag sets the size of the result set for the table content query and defaults to 100; the help text states it should be greater than zero, otherwise the app errors out. The --save-as flag stores the connection as a named profile, and -k loads key bindings from the config file. Once connected, the README documents ctrl+r to execute only the query on the current cursor line, ctrl+s to switch the active schema on PostgreSQL and Oracle, ? to open the help modal, and alt+f for full-screen mode. Multiple statements separated by semicolons run concurrently with results in separate tabs.

Connection profiles, keyrings, and the SSH tunnel path

Profiles are the feature most likely to change how you use the tool day to day. The README states that connection profiles store credentials securely in the OS keyring, and the go-keyring dependency confirms the mechanism. The connect subcommand re-uses saved profiles, and the Makefile exposes it as a target that builds the binary first. The catch is that keyring support is platform-dependent by nature; the README does not enumerate which backends are used on Linux, and a headless server without a secret service will behave differently from a desktop. That is worth testing before you rely on it. The SSH tunnel path is equally practical: flags exist for --ssh-host, --ssh-port, --ssh-user, --ssh-pass, --ssh-key and --ssh-key-pass, so you can reach a database that is not exposed publicly. The repository ships docker-compose.ssh.yml alongside the plain docker-compose.yml, which suggests the SSH path is exercised in the project's own setup. The passphrase flag for protected private keys is a detail many clients omit. Note that the README does not document how the tunnel is torn down or what happens when it drops mid-session.

Where dblab is the wrong tool

Three limitations stand out. First, the README does not document rollback, transactions, or any migration workflow. If you need to apply schema changes with a version history, dblab is not that; it is a client, and the repository contains no migration directory or migration tooling. Second, the query editor is modal and vim-style, with normal and insert modes and line-oriented editing commands. That is a feature for the intended audience and a barrier for everyone else. If you do not already know vim motions, the first hour will be spent in the help modal rather than in your database. Third, the --limit default of 100 caps the table content query. On a wide table you will see a partial view until you raise the flag, and the help text is explicit that a value of zero causes an error rather than meaning unlimited. There is also a read-only mode, enabled with --readonly, which the README says forces the session into read-only mode and is supported for PostgreSQL, MySQL, SQLite, Oracle and SQL Server. That is a guardrail against accidental writes, not a security boundary: it constrains the session, not the credentials. The README does not describe how read-only is enforced per engine, so do not treat it as a substitute for a restricted database user.

How it compares with psql, mycli and pgcli

The honest comparison is with the engine-specific interactive clients. psql, pgcli and mycli each target one engine and each assumes you already know that engine's shell conventions. dblab's difference is scope: one binary, five engines, one key binding set. If you work across PostgreSQL and MySQL in the same week, that uniformity is the whole value proposition, and it is the reason the project exists rather than being a thin wrapper around psql. The cost is depth. Engine-specific clients expose engine-specific commands and meta-commands that a cross-engine tool cannot surface without a lowest-common-denominator interface. dblab's answer to that is the query editor and the schema switcher, not a meta-command language. A second comparison is with GUI clients. Those give you a visual schema browser and result grid; dblab gives you a terminal tree and tabbed result sets. Neither is better in the abstract. If your work happens over SSH on a machine with no display, the terminal client wins by default, and that is the case dblab is built for.

Maintenance, licensing and upgrade cost

The repository is not archived, and the last push was on 2026-09-09. Releases are frequent: v0.50.0 landed on 2026-09-09, v0.49.0 on 2026-08-27, and v0.48.1 on 2026-08-17. That cadence means you should expect to upgrade, and the version numbering below 1.0 is a signal that flags and config keys can still move. The .dblab.yaml file at the repository root is the configuration surface, and the README notes that per-panel key bindings live in their own sections of that file, so a config written today may need editing after a release. The upgrade path itself is cheap: Homebrew handles the cask, and the binary release is a single file, so there is no dependency tree to reconcile. The licence is MIT, which permits commercial and closed-source use and requires that the copyright notice and permission notice be included in copies or substantial portions. That is a permissive licence, not legal advice; check your own obligations if you redistribute the binary.

Editorial conclusion

Adopt dblab if you want one binary that talks to PostgreSQL, MySQL, SQLite3, Oracle and SQL Server from a terminal, and you are comfortable with vim-style modal editing. Do not adopt it if you need a GUI, a schema migration tool, or a client that documents a rollback path. Before committing, verify the keyring behaviour on your OS, confirm the --readonly flag actually blocks writes on your engine, and check that the --limit default of 100 is large enough for the tables you query.

Frequently asked questions

Official sources

1. danvergara/dblab on GitHub
2. License: MIT
3. Project website
4. README
5. Releases