Getting started
The addisdb command line
Install the addisdb CLI with one curl command, get a full terminal UI for your databases, and call the same work from a script or CI.
‘addisdb’ is one small binary with two jobs. Run it with nothing after it and you get a full-screen terminal UI — your connections, schema browsing and querying, on a machine with no desktop to run the app on. Give it a subcommand instead and it is something a script, a cron job or a CI pipeline can call.
Install it on macOS or Linux
One command. It works out which build matches your machine, downloads it, checks its SHA-256 against the release manifest before trusting it, installs it to ~/.addisdb/bin, and adds that directory to your PATH. You do not need the desktop app — the command line installs and runs on its own.
curl -fsSL https://www.addisdb.com/install.sh | sh
No sudo, and nothing is installed outside your home directory. Open a new terminal afterwards so the PATH change takes effect — or source your shell profile — then run:
addisdb
That opens the terminal UI. From then on it updates itself, so there is no need to run the installer again.
Install it on Windows
The command above is a POSIX shell script, so Windows has its own. Open PowerShell — the one that comes with Windows is fine, there is no need for PowerShell 7 — and run:
irm https://www.addisdb.com/install.ps1 | iex
It does the same things: picks the build for your machine, verifies its SHA-256 against the release manifest, installs it to %LOCALAPPDATA%\AddisDB\bin, and adds that folder to your account’s PATH. No administrator rights, and nothing is written outside your user profile. Open a new terminal afterwards and run addisdb.
On Windows on Arm there is no native build yet, so the installer fetches the x64 one and says so — Windows runs it under emulation.
Which builds exist
macOS on Apple Silicon and Intel, Linux on x86_64, and Windows on x64 — the same four builds every release publishes. There is no Linux arm64 build yet, so the installer stops with an error rather than guessing on one.
Where your connections come from
The command line reads and writes the same connection list and the same encrypted secret store as the desktop app. Set a connection up in either one and it is there in the other, and in the VS Code extension. To see what it can already reach:
addisdb connections list
addisdb connections test <name>
Starting on a machine with nothing saved? Press Ctrl+N in the terminal UI to add a connection — the desktop app is not needed for this, or at all. Where you do have the app, it is the roomier place to do it. You can also bring connections over from another client — pgAdmin, DBeaver, TablePlus, DataGrip, Sequel Ace, MySQL Workbench, Beekeeper, or a .pgpass / my.cnf file — with addisdb connections import, which reports what it found and saves nothing until you add --save.
Where your passwords are kept
In your system’s own credential store: the Keychain on macOS, Credential Manager on Windows, and the Secret Service (GNOME Keyring or KWallet) on a Linux desktop. Never in the config file, and never on our servers.
A headless Linux server runs no Secret Service, so there AddisDB keeps them in an encrypted file in its own config directory, readable only by your user and tied to that machine — copying it somewhere else does not decrypt it. Nothing to configure: it is used only when there is no Secret Service to use instead.
Things worth knowing it can do
Every subcommand has --help, and most take --json so a script can read the output. A few of the ones people reach for:
- addisdb query <conn> "select …" — run a read-only query and print the grid.
- addisdb explain <conn> "…" — see how the database would run it. Nothing is executed without --analyze, so explaining a DELETE is safe.
- addisdb profile <conn> — rank the statements costing the database the most time, read from the engine’s own accounting, so it covers every client and not just AddisDB.
- addisdb compare "…" --project staging — run one read-only query across several databases and diff the results.
- addisdb migrate <conn> <file.sql> — apply a plain .sql file with a per-statement safety plan first.
- addisdb sandbox — try SQL against a disposable clone instead of the real database.
- addisdb monitor <conn> — watch live activity, and cancel or kill a session.
- addisdb workflow run <id> — run a saved workflow unattended; the app’s own scheduler only fires while it is open, so this is what cron or launchd should call.
Using it in CI
Exit codes are the verdict, so a drift check needs no output parsing. ‘addisdb compare’ exits 0 when every database matched, 1 when the data differs, 2 when the comparison could not be made, and 3 when a result hit the row cap and equality past it is unproven. ‘addisdb workflow run’ exits 0 on success, 1 when a step failed, and 2 when the run was refused.
Safety
The same rules as everywhere else in AddisDB. Sessions open read-only and a write is something you ask for; a connection saved as read-only refuses one at the database. ‘addisdb classify’ will tell you what the safety layer makes of a statement without connecting at all.
Updating and removing it
It keeps itself current, but you can ask directly with ‘addisdb update’. To take it off your PATH again, run ‘addisdb uninstall’ — that leaves the binary in place; delete the install folder (~/.addisdb on macOS and Linux, %LOCALAPPDATA%\AddisDB on Windows) to remove it entirely.