A PostgreSQL Browser: Web Clients, Desktop GUIs, and When psql Is Still Faster

A PostgreSQL browser comes in three shapes: a web application you point at a database and open in a tab, a desktop client you install, or psql, which is a browser too once you know four meta-commands. The web ones are the most convenient and carry a security question the other two do not, because putting a database console on a public URL is putting a database console on a public URL.

The reason to want one is almost never writing queries. It is looking: checking whether a migration landed, seeing what a row actually contains, confirming an index exists, working out why a count is wrong. That is a browsing task, and the tool that browses fastest is the one worth having open.

Table of contents

• Three shapes, three trade-offs
• Web clients, and the exposure question
• Desktop clients
• psql is a browser too
• Read-only is the underused answer
• Choosing one
• How this fits the rest of the stack
• FAQ

Three shapes, three trade-offs

The shapes differ in where they run, which determines everything else about them.

• Web client. Runs as a service somewhere, connects to the database, and you reach it in a browser. Nothing to install, works from any machine, and it is a network-reachable thing holding database credentials.
• Desktop client. Runs on your machine and connects out. Credentials stay local, and it can hold connections to many servers at once. Needs installing, and needs network access from your laptop to the database, which on a properly configured private network it does not have.
• Terminal client. psql, running wherever you can get a shell. Always available, no installation on any machine that has Postgres, and the one that works when everything else is blocked.

That last point about the desktop client is the one people trip on. A managed database on a private network is not reachable from a laptop by design. Connecting means a bastion host or a tunnel, and once you are tunnelling you may as well consider the terminal option, which needs no tunnel at all if you can already reach a machine inside the network.

Web clients, and the exposure question

Web-based Postgres browsers are genuinely pleasant. A single binary that serves a table explorer, a query editor with results as a sortable grid, and a CSV export button covers most of what anyone needs.

The risk is structural rather than a flaw in any particular tool. A web database console is an application with full database credentials, reachable over HTTP. If it is exposed publicly, its authentication is the only thing standing between the internet and your data, and it is usually a much less scrutinised piece of software than the database itself.

If you run one, these are not optional:

• Do not expose it publicly. Bind it to localhost and reach it through an SSH tunnel, or put it on a private network behind a VPN.
• Give it its own database role with only the permissions it needs, rather than the owner or a superuser.
• Make that role read-only unless there is a specific reason not to. Most of the reasons to open a browser are read-only reasons.
• Do not leave it running permanently. A console that exists only while someone is using it has a much smaller window in which to be a problem.
• Never run one on the same host as the application with the same credentials the application uses.

# Bind to localhost only, then tunnel in from your machine
pgweb --bind 127.0.0.1 --listen 8081 --url "$READONLY_DATABASE_URL"

# From the laptop
ssh -N -L 8081:127.0.0.1:8081 user@bastion

Desktop clients

The desktop category splits into two useful groups.

Postgres-specific tools are built around the database’s own concepts and expose the parts a generic client flattens: tablespaces, extensions, roles and grants, vacuum status, replication state. If you administer the server rather than just query it, this is the category you want.

Multi-database tools connect to anything with a driver, which matters when your working day involves more than one engine. The Postgres-specific features are shallower, and the query editor is usually better.

What actually separates the good ones from the rest, in practice:

• Does it warn before running an UPDATE or DELETE with no WHERE clause? This single feature has saved more data than any backup policy.
• Can it open a connection as read-only, visibly, so you can see which mode you are in?
• Does it show the actual query plan in a readable form, rather than a wall of nested text?
• Does it handle a table with fifty million rows without trying to count them all to draw a scrollbar?

That last one eliminates a surprising number of otherwise good tools the first time you point them at real production data.

psql is a browser too

The terminal client has a reputation for being a query prompt. It is actually a competent explorer, and four meta-commands cover most browsing.

\l              list databases
\dt             list tables in the current schema
\d orders       describe the orders table: columns, indexes, constraints, triggers
\du             list roles and their attributes
\dn             list schemas
\df            list functions
\x              toggle expanded display -- essential for wide rows
\timing         show how long each query took

The expanded display toggle is the one that converts psql from unreadable to pleasant. A wide row printed as a table wraps into noise; the same row in expanded mode is one field per line, which is exactly what you wanted to read.

Two more that are worth knowing because no GUI does them as well:

\watch 5        re-run the last query every five seconds
\copy (SELECT * FROM orders WHERE created_at > now() - interval '1 day') TO 'recent.csv' CSV HEADER

The copy meta-command writes a CSV from the client side, so it works without server filesystem permissions. It is the fastest path from a query to a spreadsheet that exists, and it is available on any machine that can reach the database.

Read-only is the underused answer

Most of the risk in every option above disappears if the connection cannot write. Creating a read-only role takes a minute and is worth doing once per database.

CREATE ROLE viewer LOGIN PASSWORD 'use-a-real-secret';

GRANT CONNECT ON DATABASE appdb TO viewer;
GRANT USAGE ON SCHEMA public TO viewer;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO viewer;

-- Cover tables created later
ALTER DEFAULT PRIVILEGES IN SCHEMA public
  GRANT SELECT ON TABLES TO viewer;

Use that role for every browsing tool, and keep the writing credentials for the application and for migrations. The failure mode this prevents is the one everybody has a story about: a query pasted into the wrong window with the WHERE clause not selected.

The default privileges line is the part people forget, and its absence is why a read-only role silently stops seeing new tables three months later.

Choosing one

A reasonable default arrangement, in order of how often you will use each:

1. psql for anything quick, and for anything on a machine you do not control. Learn the seven meta-commands above; it takes an afternoon and lasts a career.
2. A desktop client for real analysis, where you want to sort a result grid, compare two queries and read a plan properly.
3. A web client only when several people need access and none of them should be installing tools or holding credentials, and then only behind a private network with a read-only role.
4. The database browser built into your platform, if it has one, for the common case of looking at a table without setting anything up at all.

The last option is worth checking for before installing anything, because the setup cost of the other three is not zero and the reason you wanted a browser was usually to answer one question quickly.

How this fits the rest of the stack

How much of this matters depends on where the database actually lives, and that is a cost question as much as an access question: an instance, its storage, its backups and the service talking to it are separate numbers. The RunxBuild hosting calculator lists them individually rather than as one figure. A managed Postgres or MySQL instance on RunxBuild sits on a private network with connection limits, backups and user management handled, which makes the read-only role above the right way to hand out access, and managed WordPress carries a database browser in the dashboard for the case where the question is just what is in that table.

Useful related references:

• PostgreSQL 18: How to Upgrade Without Downtime
• SQLite vs PostgreSQL: Which One Your Project Actually Needs
• PostgreSQL Show Tables: \dt, pg_catalog, and information_schema
• Databases on RunxBuild

FAQ

What is the best PostgreSQL browser?

It depends on where you need to run it. psql is the most available and surprisingly good at browsing once you know the describe meta-commands. A desktop client is best for analysis. A web client is best for shared access, and is the one that needs the most care about exposure.

Is it safe to run a web-based Postgres client?

Only on a private network or behind an SSH tunnel, with a dedicated read-only role. A publicly reachable database console is an application holding full credentials, and its login page becomes the only barrier protecting the data behind it.

How do I browse tables in psql?

Use backslash-dt to list tables, backslash-d followed by a table name to describe one, and backslash-x to switch to expanded display so wide rows print one field per line. Those three cover most of what a graphical explorer shows.

Why can my desktop client not connect to my managed database?

Because a managed database on a private network is deliberately not reachable from the public internet. You need a bastion host, an SSH tunnel or a VPN into that network, or you can allowlist your address if the provider supports it and your address is stable.

Should I use a read-only user for database browsing?

Yes, essentially always. It costs one CREATE ROLE and a few grants, and it removes the entire class of accident where a query runs against production without its WHERE clause. Remember the default privileges grant so the role can still see tables created later.