Ranked by what they are best at rather than by popularity. The list covers the four categories you actually need — a client, a migration tool, a performance tool and a connection layer — because most "database tools" articles only cover the first.
| Tool | Engines | Best for |
|---|---|---|
| DBeaver CE | Anything with a JDBC driver | Working across mixed engines in one window; free and open source |
| TablePlus | Postgres, MySQL, SQLite, Redis, more | Fast native UI on macOS and Windows; the free tier limits open tabs |
| DataGrip | Most SQL engines | Real SQL refactoring and completion that understands your schema |
| pgAdmin | Postgres only | Server administration, roles, extensions; heavier than a query tool needs to be |
| Beekeeper Studio | Postgres, MySQL, SQLite, SQL Server | A clean open-source alternative when DBeaver feels like too much |
psql is still the most capable Postgres client that exists — \d+ tablename, \timing, \copy and \watch 5 cover most of what people open a GUI for. Add pgcli for autocompletion and syntax highlighting, or mycli for MySQL. Pipe wide results through pspg and you get a proper scrollable pager with frozen headers, which removes the last reason to reach for a GUI on a remote box.
Schema changes belong in version control and in CI, not in a GUI. Flyway runs plain SQL files in order and is the simplest thing that works. Liquibase adds changelogs and rollbacks in exchange for its own format. Atlas takes a declarative approach — you describe the desired schema and it plans the diff. Whichever you choose, run migrations in the deploy pipeline and make them idempotent, or the first failed deploy will leave the schema half-applied.
Enable the pg_stat_statements extension and query it sorted by total_exec_time. That one view identifies the queries actually costing you money, which is almost never the query someone complained about. EXPLAIN (ANALYZE, BUFFERS) tells you whether a plan is doing sequential scans and how much it read from disk versus cache. For log-based analysis, pgbadger turns Postgres logs into a report of slow queries, lock waits and checkpoint behaviour.
Postgres allocates a process per connection, so a few hundred idle application connections are pure overhead. PgBouncer in transaction pooling mode sits between your app and the database and collapses them into a small pool. This is frequently the single change that fixes "the database falls over under load" without any query tuning at all.
The sqlite3 CLI plus Datasette — which publishes a SQLite file as a browsable, queryable web interface — is the fastest path from a CSV to something colleagues can explore. For local analytics, DuckDB queries Parquet and CSV files directly with SQL and no server at all.
DBeaver or TablePlus for exploration, psql with pgcli on servers, Flyway for migrations, pg_stat_statements for tuning and PgBouncer in front of production. All but two of those are free, and the paid ones have usable free tiers.