psql: PostgreSQL
You open a terminal, type `psql`, and suddenly you're facing a prompt that looks like `postgres=#`. No buttons, no menus, no mouse. Just a cursor waiting for SQL.
For those who work with PostgreSQL daily, that's not a limitation. It's the fastest way from thought to query, and back. psql is the standard terminal client that comes with every PostgreSQL installation, on Linux, macOS, and Windows. It's not a graphical tool and doesn't try to be one.
What makes psql special is the combination of two languages. You type regular SQL, but psql also has its own meta-commands that start with a backslash. `\l` shows all databases, `\dt` all tables in the current schema, `\d` details about a single table or view. No consulting system tables, no joins on `pg_catalog`. Just a backslash, one letter, Enter.
Those meta-commands aren't SQL. psql intercepts them before they reach the database and translates them internally into the queries you would otherwise have had to write yourself. It saves typing, but the main thing is that you don't have to step out of your SQL mindset to remember how that one system query was put together again.
The history works as you'd expect from a decent command-line tool. Every query you enter is saved automatically, and in the next session you browse through it with the arrow keys. On Unix-like systems, that history is in `~/.psql_history`, on Windows in `%APPDATA%\postgresql\psql_history`.
If you don't want the history in the default location, you can move it with the environment variable `PSQL_HISTORY`. Put it in your `.bashrc` or `.zshrc` and every session writes to your chosen file. There's also an internal variable `HISTFILE`, which you can set per session. Handy if you work on multiple projects on one machine and want to keep the queries separate. Or if you don't want a colleague to find that `DROP TABLE` from last night in your history.
For those who mainly use psql in scripts, the file commands are more important. With `\i bestand.sql` you read in a SQL file, and with `-f bestand.sql` on the command line you do the same without an interactive session. You capture the output of a query to a file with `\o uitvoer.txt`. This makes psql usable in cron jobs and CI/CD pipelines, exactly where a graphical client has no business.
The connection itself is handled by psql through the same mechanisms as any other PostgreSQL client. SSL encryption, authentication via `.pgpass` or ident, connections over Unix sockets or TCP/IP — it's all there. You can access a production database on another server from a development workstation, or run on a server via SSH without a graphical environment ever being involved.
psql doesn't make backups. For that you have `pg_dump` and `pg_dumpall`. But restoring a backup in plain SQL format you do again with psql: `psql -d databasenaam -f backup.sql`. The program is thus the execution channel for recovery, even though it never made the backup itself.
The PostgreSQL Global Development Group describes psql in the official documentation as a terminal-based front-end to PostgreSQL. That wording has been unchanged since version 7.0, and that says a lot. The program hasn't grown with the fashion of graphical interfaces or web-based dashboards. It has kept doing what it always did: providing a textual interface to a relational database, without frills.
That also means you have to learn something for it. The meta-commands aren't discoverable from the interface itself; you have to know them or look them up. Those used to a clickable database client will regularly type `\?` in the first days to see the list of available commands. That list is long, and honestly that's also psql's weakness: the threshold isn't with SQL, but with remembering all those backslash combinations.
On the other hand, you don't need to install anything extra. Every PostgreSQL installation provides psql, on every supported platform. No separate package, no plugin, no version that doesn't match the server. It's just there, and it works with the version of PostgreSQL you're running.
For those who work with PostgreSQL regularly, psql is therefore not one tool among others. It's the tool you fall back on when the graphical client is too slow, too limited, or simply not available on the server where you need to be. It's the common denominator between a laptop, a production server, and a container running in an environment where nothing graphical exists.
The question isn't whether psql is better than a graphical client. The question is where you work and what you do. Those who occasionally run a query on a local database have enough with a graphical tool. Those who manage servers, run migrations, or restore backups will sooner or later end up in a terminal. And then that one backslash suddenly turns out to be faster than any mouse.