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

The gap dblab fills: interactive SQL without leaving the shell

Most database work splits into two modes. You either open a GUI client, which means leaving the terminal and often installing a runtime, or you type queries into psql or mysql, which gives you no persistent result view, no schema browser and no query history. dblab targets the space between them. The README describes it as an "Interactive client for PostgreSQL, MySQL, SQLite3, Oracle and SQL Server" and states the project was created as an attempt to build a very simple and portable application for local or remote databases. The audience is the command line user who wants a persistent connection, a sidebar tree of tables, and a scrollable result set, without a browser or an Electron shell. The README's own framing is direct: the description line calls it "the database client every command line junkie deserves." That is the intended user, and the feature list is written for them: Vim-style editing, key rebinding per panel, a help modal on the question mark key. If you are not comfortable in a terminal, the design decisions here will read as obstacles rather than features.

What the Go single-binary choice actually buys you

The README states the main idea behind using Go for backend development is to utilize the compiler's ability to produce zero-dependency binaries for multiple platforms. That is the architectural claim, and it drives the distribution model. Installation options listed are Homebrew (brew install --cask danvergara/tools/dblab), a manual download from the release page, or a shell script at scripts/install_update_linux.sh. There is no package manager dependency on a JVM, a Python environment or a Node runtime. The practical consequence is that you can drop the binary on a jump host, a container image or a colleague's laptop and it runs. The cost is that the binary carries the database drivers for five engines, so it is larger than a client for one engine would be. The README does not publish a binary size, so I cannot state one. It also means driver behavior is whatever the Go driver implements, and the README's flag list reflects that: --sslcert and --sslkey are described with PostgreSQL defaults (~/.postgresql/postgresql.crt and ~/.postgresql/postgresql.key), which suggests those flags are Postgres-shaped rather than uniform across all five drivers.

The query editor, multi-statement tabs and the ctrl+r distinction

The editor is the part of dblab with the most documented behavior. It has normal and insert modes and line-oriented editing commands, in the Vim tradition. Two execution paths exist and the difference matters. The README states that multi-query execution lets you write multiple SQL statements separated by semicolons and run them concurrently, with results displayed in separate tabs. Separately, pressing ctrl+r executes only the query on the current cursor line, without running the other statements in the editor. That second binding is the one to internalize. In a file full of statements, ctrl+r gives you a single-statement run scoped to where the cursor sits, which is closer to how people actually iterate on one query. The concurrency claim for multi-query execution is worth reading carefully: the README says results are displayed in separate tabs, but it does not say whether the statements run on one connection or several, and it does not describe ordering guarantees. If your statements depend on each other, semicolon-separated execution is the wrong tool and you should run them one at a time.

Connection profiles, the keyring and the .dblab.yaml file

Connection data can come from flags or from a config file. The help output lists --config with default locations of the current directory, $HOME/.dblab.yaml or $XDG_CONFIG_HOME/.dblab.yaml, and --cfg-name to select a named section. The --save-as flag saves the connection as a named profile for later reuse, and the connect subcommand re-uses saved profiles. The README states credentials are stored securely in the OS keyring, which is the better default than a plaintext password in a dotfile, though it does mean profile portability depends on the keyring being available on the target machine. Key bindings live in the same file, activated by --keybindings or -k. The README notes that the query editor, the sidebar tree, the result set panel and the panel navigation each have their own section in .dblab.yaml, so every panel can be rebound independently. That granularity is unusual and useful if you have an existing muscle-memory setup, but it also means a partial config is easy to get wrong, since a binding you forget to override keeps the default. The README does not document the YAML schema in the excerpt available, so check dblab.app before writing one by hand.

Remote access, read-only mode and schema switching

Remote work is handled through flags rather than a config file for the SSH side: --ssh-host, --ssh-port, --ssh-user, --ssh-key, --ssh-key-pass and --ssh-pass. The presence of --ssh-key-pass indicates support for passphrase-protected private keys, which is a detail many CLI clients skip. Read-only mode is a single flag, --readonly, and the README states it forces the database session into read-only mode, supported for PostgreSQL, MySQL, SQLite, Oracle and SQL Server. That is the correct implementation approach: enforcing at the session level rather than filtering statements client-side. Schema switching is bound to ctrl+s and opens a filterable list; the README scopes it to PostgreSQL and Oracle, and only when no schema was pinned at startup. The active schema is always shown in the status bar. If you connect with --schema, expect ctrl+s to be inert. That is a reasonable design, but it is the kind of constraint that reads as a bug until you find the sentence in the docs.

Where dblab is the wrong tool

dblab is interactive by construction. There is no documented non-interactive mode, no output format flag such as CSV or JSON, and no batch execution path described in the README or the help output. If you need to run a migration in CI, dump a query result to a file, or wire a database check into a script, dblab does not do that and the flag list gives no indication it intends to. The --limit flag is a case in point: it controls the size of the result set for the table content query and defaults to 100, with the help text warning it should be greater than zero or the app will error out. That is a UI guardrail, not an export control. A second limitation is the platform matrix. The README advertises cross-platform support for macOS, Linux and Windows at 32 and 64 bit, but the automated install script is Linux-specific (scripts/install_update_linux.sh), so Windows and macOS users are directed to Homebrew or a manual release download. A third is the driver surface. Five engines behind one TUI means engine-specific behavior, such as schema switching, is unevenly available, and the README itself qualifies several features by engine.

The alternative: psql and mysql, and what changes

The obvious alternative is the vendor client you already have, psql for PostgreSQL or the mysql shell. The difference is not the query language, it is the interaction model. psql is line-oriented and scriptable: you can pipe a file into it, use -c for a single command, and capture output with standard shell redirection. dblab inverts that. It holds a persistent connection, renders results in a scrollable panel, keeps query history across sessions, and requires a terminal. Neither is a superseded version of the other. If your work is exploratory (browse the schema, poke at a table, iterate on a join), dblab's sidebar tree and tabbed result sets remove the retyping that psql forces on you. If your work is repeatable (run this file, check this exit code, compare this output), psql is the better instrument and dblab has nothing to offer. The honest framing is that dblab replaces the GUI client you open for ad hoc inspection, not the psql invocation inside your deploy script. Teams often need both, and nothing in dblab's design suggests it is trying to absorb the scripting role.

Maintenance, release cadence and the MIT licence

The release history shows a steady cadence: v0.48.1 on 2026-08-17, v0.49.0 on 2026-08-27, and v0.50.0 on 2026-09-09, with the last push to the default branch on the same day as the latest release. That pattern suggests active maintenance rather than a dormant project, though the version numbers are still in the 0.x range, which conventionally signals that the maintainer has not committed to interface stability. For a tool you install as a binary and drive from a terminal, that is a modest risk. For a tool whose config file format you script around, it is worth tracking: the .dblab.yaml key binding sections are exactly the kind of surface that changes before 1.0. The project is MIT licensed, which permits commercial use, modification and redistribution with the licence and copyright notice preserved. That is a permissive arrangement, but I am not a lawyer and this is not legal advice; if you are redistributing dblab inside a product, read the LICENSE file in the repository rather than this paragraph. Upgrade cost is low by design: the automated install script exists for Linux, and Homebrew handles the cask elsewhere, so moving between minor versions is a re-install rather than a migration.

Editorial conclusion

Adopt dblab if you already live in a terminal, connect to remote Postgres or MySQL over SSH, and want a single binary without a runtime dependency. Do not adopt it if your database work is scripted, embedded in CI, or needs a graphical result grid. Before committing, verify that your driver's flags behave as you expect: run dblab --readonly against a scratch database and confirm the session rejects a write, and check that --limit is set above zero, because the help text states the app errors out otherwise.

Official sources

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