My PostgreSQL Admin Tool Stack in 2026 — What Actually Works

I spend roughly half my working day in PostgreSQL. My ERP runs on it, my analytics queries hit it, I’ve built a couple AI agents that talk to it directly via MCP, and my nightly cron jobs all write to it. Getting the admin tooling right isn’t optional — it’s the difference between a 5-minute debugging session and a lost afternoon.

Over the past year I’ve cycled through a dozen tools. Here’s what I’m actually using in 2026 and why.

The Stack

Terminal: psql + .psqlrc

I tried pgcli. I really wanted to love it. The syntax highlighting is genuinely nice, and the auto-completion for table names is useful. But here’s the thing: psql with a well-tuned .psqlrc covers 90% of what I need, and it’s already installed on every server I touch.

My config enables \timing on every query (non-negotiable — you need to know your query took 30ms vs 3s), sets \x auto for wide results, and configures a custom prompt showing the database name and connection time. The other 10% — fuzzy table name completion — I miss from pgcli but not enough to justify an extra install on every machine.

GUI: pgAdmin 4 (for schema design only)

I never thought I’d recommend pgAdmin in 2026. It’s slow. The interface feels like a Java swing app from 2005. But the ERD tool (Tools → ERD Tool) is genuinely useful when I’m designing a schema with more than five tables. Seeing the relationships visually catches orphan foreign keys and missing indexes that I’d miss in raw SQL.

For example, last month I was designing a multi-warehouse inventory schema. In the ERD, I noticed my stock_movements table referenced warehouses but had no index on warehouse_id + product_id. That would have been a sequential scan nightmare at 50K rows. Caught it in 30 seconds, while writing raw SQL I might not have noticed until the first production query timed out.

For everything else pgAdmin is still too slow. But the ERD tool has no real competitor at this price (free).

Monitoring: pg_stat_statements + custom views

I enabled pg_stat_statements about a year ago and built three custom views on top. Every morning I run a quick check: top 5 slowest queries from the last 24 hours, ordered by total execution time. Most days there’s nothing to report. Some days I find a sequential scan on a table that’s grown to 50K rows and just needs an index.

The built-in views handle the rest. pg_stat_activity for active connections. pg_stat_all_tables for table bloat and dead tuples. I don’t need Datadog, Grafana, or any paid monitoring service for a single-server deployment. PostgreSQL’s observability built-ins are underrated — they’re free, always available, and tell you exactly what you need to know.

Backups: pg_dump + custom cron script

I run pg_dump nightly via a cron job, encrypt the backup with GnuPG, and upload it to Backblaze B2. The whole script is 30 lines of bash — three lines for the dump, two for the encryption, five for the upload, and the rest is logging and error handling. Restoring is one command: decrypt, then psql -f backup.sql.

No subscription. No vendor lock-in. No “we changed our pricing and now your backups cost five times more.” Just cron, GPG, and S3-compatible object storage.

AI-Assisted Query Drafting: Hermes Agent + psql

This is the only “modern” addition to my stack, alongside the AI junior developer handling ERP tickets. When I get a complex analytics request — “show inventory turnover by warehouse category for the last quarter with YoY comparison and moving average” — I ask Hermes Agent to write the query. It spawns a subagent with read-only PostgreSQL access, explores the schema via information_schema and pg_catalog, understands the table relationships and data types, then drafts the SQL.

I review, tweak if needed, and run it. This alone saves me a couple hours per week. The key is that the subagent actually inspects the schema before writing — no hallucinated column names, no table names it just made up.

What I Don’t Use

• DBeaver — Feature-packed but heavy. Java-based, slow to start. Overkill for my workflow.
• TablePlus — Beautiful native app, but costs $60/year for something psql does for free.
• Grafana + postgres_exporter — Great for teams monitoring multiple databases. For a solo developer managing one server, psql + a morning check is simpler.

The Bottom Line

In 2026, my PostgreSQL admin stack is deliberately boring. psql with a tuned config, the built-in statistics views, cron-based backups, and pgAdmin for the occasional ERD session. No hype tools. No dashboards. No SaaS subscriptions.

The only modern addition is AI-assisted query drafting, which has been a genuine productivity boost — not because it replaces my thinking, but because it handles the mechanical “write me a JOIN across four tables with window functions” part in seconds.

Sometimes the best tool is the one you already have open in your terminal.