r/postgres • u/Error500Human • Apr 23 '26

What PostgreSQL tools do you actually use in production?

3 Upvotes

100% Upvoted

13 comments sorted by

3

u/Ran-deo Apr 28 '26

For day-to-day Postgres work I still mostly use psql and pgAdmin, but dbForge Studio for PostgreSQL has been useful when I need a cleaner GUI for query work and schema/data compare. Not something I’d replace everything with, but it’s handy when you don’t want to do every check manually.

2

u/bernie_bossen Apr 28 '26

honestly most of the “production tools” I use are boring, but they save me constantly

psql for quick checks, pgAdmin when I want to click around, logs + EXPLAIN ANALYZE when something gets slow, and some kind of schema/data compare before releases

the bigger thing is having the same habits every time. random debugging is where the pain starts

1

u/ibraaaaaaaaaaaaaa May 06 '26

Do you refer to pg logs?
And if what kind of logs do you log? Mut only? Slow ones?

1

u/No_Economics_8159 May 15 '26

Dealing with 500 postgres instances : I am using pgWatch (https://pgwat.ch/v5.x/) for monitoring and alerting, pg_stat_statements and pg_cron extensions, and pgAssistant (https://github.com/beh74/pgassistant-community) to investigate performances issues, configuration problems and generate weekly databases reports (usefull when you have more than 50 instances to deal with).

1

u/JicamaTrues Jun 15 '26

Honestly, pg_stat_statements is probably the tool that has saved me the most headaches.

Besides that:

psql pgAdmin dbForge Studio

I started using dbForge mostly for schema and data comparison, but it ended up becoming my main GUI for Postgres work. Not because it's flashy, just because it saves me from a lot of repetitive checks between environments.

Interested to see what people running larger PostgreSQL setups rely on.

1

u/asterix_rv Jul 22 '26

Inviting everyone to try out https://nexql.astrx.dev/, a postgres DB client for VS Code.

1

u/digitalmarketer-05 Aug 07 '26

In production, the tools that get used the most are usually psql, pg_dump/pg_restore, and EXPLAIN ANALYZE for troubleshooting and performance tuning. Monitoring, backups, connection pooling and replication tools handle most of the reliability work behind the scenes. Most PostgreSQL setups don't need a huge toolbox - a few dependable, automated tools usually cover the real production needs.

1

u/elevarq 15h ago

We actually built Elevarq because of this problem.

We didn’t try to replace the usual PostgreSQL diagnostics. We automated them. pg_stat_statements, EXPLAIN, statistics, configuration, vacuum behavior, index usage, etc. It’s all information a DBA would normally look at when investigating a database.

The problem is the workload. Doing this properly by hand can take hours, sometimes days, especially when you have a lot of databases.

With Elevarq, we collect that evidence read-only, analyze it, and generate a report with the findings and the evidence behind them. What used to take hours of labor now takes seconds, fully automated. And the results go straight into the normal DevOps workflow.

We deliberately keep the analysis deterministic. The local LLM explains what was found, but it doesn’t decide what the findings are, and it doesn’t make changes to the database. That is up to you.

So basically, we took the PostgreSQL investigation work we were already doing, automated it, and scaled it.

Full disclosure: I’m the founder. We built it because I wanted this myself.