DEV Community: Dave

7 PostgreSQL monitoring tools every DBA should know in 2026

Dave — Sun, 15 Feb 2026 12:47:06 +0000

Running PostgreSQL in production without proper monitoring is like driving at night with the headlights off. You might get away with it for a while, but eventually something goes wrong and you won't see it coming. Whether it's slow queries piling up, connections maxing out or disk space running low, monitoring gives you the visibility to catch problems before they become outages.

This article covers seven monitoring tools that work well with PostgreSQL. Some are purpose-built for Postgres, others are general-purpose but have strong PostgreSQL support. Each has its own strengths. The right choice depends on your team size, infrastructure complexity and how deep you need to go.

1. pg_stat_statements

This is the starting point for PostgreSQL monitoring. pg_stat_statements is a built-in extension that tracks execution statistics for all SQL statements. It records how many times each query ran, how long it took, how much I/O it consumed and more. If you're not using it yet, enable it today.

To enable pg_stat_statements, add it to your postgresql.conf:

shared_preload_libraries = 'pg_stat_statements'
pg_stat_statements.track = all

After a restart, you can query it directly:

SELECT
  query,
  calls,
  total_exec_time,
  mean_exec_time,
  rows
FROM pg_stat_statements
ORDER BY total_exec_time DESC
LIMIT 20;

This gives you the top 20 queries by total execution time. That's usually where your biggest optimization opportunities are. A query that runs 50,000 times a day with a mean execution time of 200ms is probably a better target than a query that runs once and takes 10 seconds.

pg_stat_statements doesn't give you dashboards or alerts. It's raw data. But it's the foundation that many other tools build on. It's free, it ships with PostgreSQL and it has minimal overhead. There's really no reason not to use it.

2. pgAdmin

pgAdmin is the official administration and monitoring tool for PostgreSQL. It's a web-based interface that lets you manage databases, run queries and view server activity. It's been around for a long time and most DBAs are familiar with it.

For monitoring, pgAdmin provides a dashboard that shows active sessions, transactions per second, tuples in and out and server resource usage. You can see running queries, lock information and database statistics. It's not the most powerful monitoring solution, but it's solid for day-to-day operations and quick troubleshooting.

The dashboard refresh interval is configurable and you can drill into individual databases or tables for detailed statistics. pgAdmin also lets you view and cancel long-running queries directly from the UI, which is handy during incidents.

Where pgAdmin falls short is in historical data and alerting. It shows you what's happening right now, but it doesn't store metrics over time or send you notifications when something goes wrong. For production monitoring with alerts and historical trends, you'll want something more specialized. But for ad-hoc monitoring and administration, pgAdmin is hard to beat.

3. Prometheus with postgres_exporter

Prometheus is one of the most popular open-source monitoring systems, and it integrates well with PostgreSQL through the postgres_exporter. This combination gives you time-series metrics, alerting and integration with Grafana for dashboards.

postgres_exporter collects metrics from PostgreSQL's system catalog views and statistics collectors. It exposes them in Prometheus format so you can scrape, store and query them. Out of the box, you get metrics for:

Active connections and connection states
Transaction rates (commits, rollbacks)
Tuple operations (inserts, updates, deletes, fetches)
Table and index sizes
Replication lag
Lock counts
Cache hit ratios

Setting up postgres_exporter is straightforward. You point it at your PostgreSQL instance and Prometheus scrapes it on a regular interval. Then you build Grafana dashboards to visualize the data.

Feature	Details
Cost	Free, open source
Setup complexity	Medium (requires Prometheus infrastructure)
Alerting	Built-in with Alertmanager
Historical data	Yes, configurable retention
Custom metrics	Supported via custom queries
Scaling	Handles large fleets of PostgreSQL instances

The main downside is setup effort. You need to run Prometheus, configure exporters and build dashboards. It's not a plug-and-play solution. But if you're already using Prometheus for other infrastructure, adding PostgreSQL monitoring is trivial.

4. Datadog

Datadog is a managed monitoring platform with deep PostgreSQL support. It collects metrics from PostgreSQL automatically using its agent, correlates database performance with application metrics and provides pre-built dashboards. If you want comprehensive monitoring without managing your own infrastructure, Datadog is a strong option.

What makes Datadog stand out for PostgreSQL monitoring is its Database Monitoring feature. It goes beyond basic metrics and shows you:

Query-level performance with execution plans
Wait event analysis to understand what queries are waiting on
Active session history
Explain plans captured automatically
Host-level metrics correlated with database activity

Datadog normalizes and aggregates query patterns, so you see "SELECT * FROM users WHERE id = ?" as a single entry regardless of the specific parameter values. This makes it easy to spot problematic query patterns.

The trade-off is cost. Datadog charges per host per month, and Database Monitoring is an additional cost on top of the base infrastructure monitoring. For a small team with a few PostgreSQL instances, it might be overkill. For larger organizations running dozens of PostgreSQL servers, the time savings and visibility often justify the expense.

5. pgwatch

pgwatch is an open-source monitoring tool specifically designed for PostgreSQL. Unlike general-purpose tools, pgwatch understands PostgreSQL deeply and comes with pre-configured metrics and dashboards tuned for Postgres-specific concerns.

pgwatch collects metrics through SQL queries against PostgreSQL's system views. It stores the data in a time-series database and provides Grafana dashboards out of the box. The default metric set covers the essentials:

Bloat monitoring for tables and indexes
Replication lag and status
Lock monitoring and deadlock detection
Checkpoint frequency and duration
WAL generation rate
Autovacuum activity
Sequence usage (approaching max values)

One of pgwatch's strengths is detecting problems that general monitoring tools miss. Things like index bloat creeping up over weeks, sequences approaching their maximum value or autovacuum falling behind on specific tables. These are PostgreSQL-specific issues that tools like Prometheus won't catch unless you write custom queries.

Setup is simple. pgwatch ships as a Docker container with everything included. Point it at your PostgreSQL instances and you get dashboards immediately. No need to configure exporters or build custom dashboards from scratch.

Feature	Details
Cost	Free, open source
Setup complexity	Low (Docker-based, batteries included)
Alerting	Via Grafana integration
PostgreSQL-specific metrics	Extensive, pre-configured
Custom metrics	Supported via SQL
Best for	Teams that want PostgreSQL-focused monitoring fast

For teams that want solid PostgreSQL monitoring without the overhead of managing a full Prometheus stack, pgwatch is an excellent choice.

6. Percona Monitoring and Management (PMM)

PMM is an open-source monitoring platform from Percona that supports PostgreSQL, MySQL and MongoDB. It combines metrics collection, query analytics and alerting in a single package. Think of it as a self-hosted alternative to Datadog's database monitoring.

The Query Analytics feature in PMM is particularly useful. It captures query execution statistics from pg_stat_statements and pg_stat_monitor, then presents them with detailed breakdowns of execution time, rows examined, I/O wait and more. You can sort queries by various dimensions, see their explain plans and track how performance changes over time.

PMM includes pre-built dashboards for:

PostgreSQL instance overview
Query analytics and top queries
Replication monitoring
Table statistics and bloat
Checkpoint and WAL metrics
Node-level performance (CPU, memory, disk)

What sets PMM apart is that it's self-hosted and free. You get Datadog-level query analytics without the monthly bill. The trade-off is that you need to run and maintain the PMM server yourself. But it's packaged as a Docker container and reasonably easy to operate.

PMM also has an advisor system that runs automated checks against your PostgreSQL configuration and alerts you about common misconfigurations. Things like shared_buffers being too small, autovacuum being disabled or old PostgreSQL versions with known vulnerabilities.

7. check_postgres

check_postgres is a Nagios plugin for monitoring PostgreSQL. It might seem old-school compared to modern tools, but it's still widely used and incredibly reliable. It runs health checks against PostgreSQL and reports results in a format that any monitoring system (Nagios, Icinga, Zabbix) can consume.

check_postgres performs specific checks rather than collecting continuous metrics. Each check targets a specific concern:

Connection count and proximity to max_connections
Database size and growth rate
Replication lag
Transaction ID wraparound risk
Bloat levels
Long-running queries
Lock contention
Last vacuum and analyze times

The beauty of check_postgres is its simplicity. Each check is a single command that returns a status (OK, WARNING, CRITICAL) and a message. You configure thresholds and your monitoring system handles the rest. No dashboards to build, no time-series database to maintain.

Transaction ID wraparound monitoring deserves special mention. This is one of PostgreSQL's nastier failure modes. If transaction IDs aren't cleaned up by VACUUM, PostgreSQL will eventually refuse to process new transactions to prevent data corruption. check_postgres monitors this and warns you well before it becomes a problem.

For teams that already run Nagios or similar tools, check_postgres is a natural fit. It's lightweight, well-tested and covers the critical health checks that prevent outages.

Choosing the right tool

There's no single best monitoring tool. The right choice depends on your situation. Here are some practical guidelines.

For small teams with a few PostgreSQL instances, start with pg_stat_statements and pgwatch. You get PostgreSQL-specific monitoring with minimal setup. Add check_postgres if you need basic alerting without building a full metrics pipeline.

For medium teams running multiple services, Prometheus with postgres_exporter fits well if you already have a Prometheus stack. You get consistent monitoring across all your services, and PostgreSQL becomes just another data source. PMM is a good alternative if you want better query analytics than stock Prometheus provides.

For larger organizations with dedicated database teams, Datadog provides the least operational overhead and the deepest insights. The cost is justified when you have dozens of servers and need quick incident resolution. PMM is the self-hosted alternative if budget is a concern.

One thing these tools don't cover is backup monitoring. Knowing that your database is healthy is important, but knowing that your backups are running successfully is equally critical. Databasus is an industry standard for PostgreSQL backup tools, providing automated scheduled backups with notifications across Slack, Discord and email so you'll know immediately if a backup fails.

Whatever tools you choose, start simple and expand as needed. pg_stat_statements costs nothing to enable and gives you immediate value. Build from there based on what you actually need, not what looks impressive on a vendor's demo page.

PostgreSQL connection pooling — PgBouncer vs Pgpool-II compared in 5 key areas

Dave — Sat, 14 Feb 2026 21:20:16 +0000

PostgreSQL creates a new process for every client connection. That works fine when you have a few dozen users. But when hundreds or thousands of connections start hitting the database, you'll notice memory usage climbing, response times increasing and eventually connections getting refused. Connection pooling sits between your application and PostgreSQL, reusing a small number of server connections across many clients.

The two most widely used poolers for PostgreSQL are PgBouncer and Pgpool-II. They solve the same core problem but take very different approaches. PgBouncer is a lightweight, focused connection pooler. Pgpool-II is a feature-rich middleware that does pooling alongside load balancing, replication management and more. This article compares them across five areas that matter most when choosing between the two.

Why connection pooling matters for PostgreSQL

Every PostgreSQL connection spawns a new backend process on the server. Each process uses memory (typically 5-10 MB), and the operating system has to manage context switching between them. At 500 concurrent connections, that's already 2.5-5 GB of RAM just for connection overhead, before any queries run.

Most web applications don't need hundreds of active database connections at the same time. A typical request holds a connection for a few milliseconds to run a query, then releases it. Without pooling, the connection is opened, used briefly, closed, and a new one is created for the next request. All that setup and teardown is wasted work.

A connection pooler maintains a fixed set of persistent connections to PostgreSQL and hands them out to clients as needed. When a client finishes, the connection goes back to the pool instead of being closed. This reduces the number of PostgreSQL backend processes and eliminates connection setup overhead.

-- Check current connections and their state
SELECT state, count(*)
FROM pg_stat_activity
GROUP BY state;

-- Check max_connections setting
SHOW max_connections;

If you see connections mostly in "idle" state, pooling will help a lot. Those idle connections are wasting server resources for nothing.

1. Architecture and design philosophy

PgBouncer and Pgpool-II were built with fundamentally different goals. Understanding this difference saves you from trying to force the wrong tool into your setup.

PgBouncer does one thing: connection pooling. It's a single-threaded, event-driven process written in C. It uses libevent to handle thousands of connections with minimal memory. A PgBouncer instance typically uses 2-5 MB of RAM regardless of how many clients are connected. Because it's single-threaded, it avoids locking overhead entirely.

Pgpool-II is a middleware layer. It handles connection pooling but also load balancing across replicas, automated failover, replication management, query caching and parallel query execution. It runs as a multi-process daemon where each child process handles one client connection.

Feature	PgBouncer	Pgpool-II
Primary purpose	Connection pooling only	Pooling, load balancing, HA, caching
Architecture	Single-threaded, event-driven	Multi-process, one process per connection
Memory per connection	~2 KB	~3-5 MB (per child process)
Configuration complexity	Simple (one config file)	Complex (multiple config files)
Codebase size	~15k lines of C	~200k+ lines of C
Protocol support	PostgreSQL wire protocol	PostgreSQL wire protocol + SQL parsing

PgBouncer is easy to reason about. You configure a few settings, point your application at it and it works. Pgpool-II has a steeper learning curve because it tries to do many things. If you only need connection pooling, PgBouncer is the simpler choice. If you need pooling plus load balancing plus failover, Pgpool-II bundles everything into one package.

One important architectural difference: Pgpool-II parses SQL queries to decide where to route them (reads to replicas, writes to primary). This parsing adds overhead but enables features that PgBouncer can't offer. PgBouncer passes queries through without inspecting them.

2. Pooling modes and connection handling

Both tools offer connection pooling but they handle it differently. The pooling mode determines when a server connection is released back to the pool, and this directly affects how many concurrent clients you can support with a given number of backend connections.

PgBouncer supports three pooling modes:

Session pooling — A server connection is assigned to a client for the entire duration of the client session. When the client disconnects, the connection returns to the pool. This is the safest mode and supports all PostgreSQL features including prepared statements, temporary tables and session-level settings.
Transaction pooling — A server connection is assigned only for the duration of a transaction. Between transactions, the connection goes back to the pool for other clients to use. This is much more efficient for web applications where each request is a short transaction. The downside is that session-level features like prepared statements, SET commands and LISTEN/NOTIFY don't work reliably because different transactions may run on different server connections.
Statement pooling — A server connection is assigned for a single statement. After the statement completes, the connection is released. This is the most aggressive mode but only works if your application never uses multi-statement transactions.

Pgpool-II uses a different model. It maintains a pool of child processes, each handling one client. The child process holds a cached connection to the backend and reuses it across requests from the same client. Pgpool-II doesn't support transaction-level pooling in the same sense as PgBouncer. Its pooling is closer to session-level, where connections are cached per child process and reused when the same user/database combination connects again.

# PgBouncer configuration example (pgbouncer.ini)
[databases]
mydb = host=localhost port=5432 dbname=mydb

[pgbouncer]
listen_addr = 0.0.0.0
listen_port = 6432
auth_type = md5
auth_file = /etc/pgbouncer/userlist.txt
pool_mode = transaction
max_client_conn = 1000
default_pool_size = 25
reserve_pool_size = 5

# Pgpool-II configuration example (pgpool.conf)
listen_addresses = '*'
port = 9999
num_init_children = 100
max_pool = 4
connection_cache = on
backend_hostname0 = 'localhost'
backend_port0 = 5432
backend_weight0 = 1

For web applications running hundreds of short-lived requests, PgBouncer's transaction pooling mode is significantly more efficient. A pool of 25 backend connections can serve 1000+ clients because each client only holds a connection for the few milliseconds it takes to run a transaction. With Pgpool-II's session-based approach, you need roughly one child process per concurrent client, which uses more resources.

3. Performance and resource usage

This is where the architectural differences show up in numbers. PgBouncer's lightweight design gives it a clear advantage for raw connection pooling performance.

PgBouncer adds almost no measurable latency. Because it's event-driven and doesn't parse queries, the overhead per query is typically under 100 microseconds. It can handle tens of thousands of connections simultaneously without significant CPU or memory usage. A single PgBouncer instance on modest hardware can comfortably manage 10,000+ client connections.

Pgpool-II has higher overhead because each client connection requires a dedicated child process. With num_init_children set to 200, that's 200 processes the OS has to manage. Memory usage scales linearly with the number of child processes. Query parsing for read/write splitting adds additional CPU overhead on every statement.

Benchmark results vary by workload, but the general pattern is consistent:

Metric	PgBouncer	Pgpool-II
Query overhead per statement	< 100 microseconds	0.5-2 milliseconds (includes SQL parsing)
Max clients on 2 GB RAM	10,000+	~400 (limited by child processes)
Memory at 500 clients	~10-20 MB	~1.5-2.5 GB
Connection storm (1000 simultaneous)	Handles with minimal resource spike	Needs 1000 child processes or queues
CPU usage under load	Minimal (event-driven)	Higher (process per connection + SQL parsing)

That said, Pgpool-II's overhead is the cost of its additional features. If you're using its load balancing and failover capabilities, the comparison isn't purely about pooling performance because Pgpool-II is doing more work. You'd otherwise need a separate tool for those tasks.

For applications where connection pooling performance is the primary concern, PgBouncer is the clear winner. If you need load balancing and are okay with the additional resource cost, Pgpool-II delivers that in one package.

4. High availability and load balancing

This is Pgpool-II's strongest area and something PgBouncer doesn't attempt to solve on its own.

Pgpool-II offers built-in features for HA and scaling. It parses SQL queries and automatically routes SELECT statements to read replicas while sending writes to the primary. This read/write splitting is transparent to the application with no code changes needed. When the primary server goes down, Pgpool-II can promote a standby and reconfigure itself automatically using a failover script, so the application doesn't need to know about the topology change.

Beyond routing and failover, Pgpool-II continuously monitors backend servers and removes unhealthy ones from the pool through health checking. It can also run in a clustered mode with its watchdog feature, where multiple Pgpool-II instances monitor each other and one takes over with a virtual IP if another fails.

# Pgpool-II load balancing configuration
load_balance_mode = on
backend_hostname0 = 'primary.db.local'
backend_port0 = 5432
backend_weight0 = 1
backend_flag0 = 'ALWAYS_PRIMARY'

backend_hostname1 = 'replica1.db.local'
backend_port1 = 5432
backend_weight1 = 2

backend_hostname2 = 'replica2.db.local'
backend_port2 = 5432
backend_weight2 = 2

PgBouncer doesn't do any of this. It connects to a single PostgreSQL instance. For load balancing, you need an external solution like HAProxy, DNS-based routing or application-level routing. For failover, you need tools like Patroni, repmgr or pg_auto_failover to handle promotion, and then update PgBouncer's configuration to point to the new primary.

A common production pattern is Patroni managing PostgreSQL replication and failover, PgBouncer providing connection pooling and HAProxy routing traffic to the correct server. This approach gives you best-in-class tooling for each concern but requires more components to configure and maintain. Pgpool-II combines these functions, trading some performance for operational simplicity.

If you're running a single PostgreSQL server or your cloud provider handles replication and failover (like AWS RDS), PgBouncer is usually enough. If you're managing your own PostgreSQL cluster and want an integrated solution, Pgpool-II saves you from juggling multiple tools.

5. Configuration and operational complexity

Getting started with PgBouncer takes about ten minutes. Getting Pgpool-II working correctly can take a day or more, especially if you're configuring load balancing and failover.

PgBouncer configuration involves a single INI file. You specify the databases, set the pool mode, define connection limits and point it at an auth file. That's it. The defaults are sensible and most deployments only need to adjust a handful of settings.

The key settings you'll touch are pool_mode (session, transaction or statement), max_client_conn (maximum client connections allowed), default_pool_size (server connections per user/database pair) and reserve_pool_size (extra connections for burst traffic). That covers most deployments.

Pgpool-II configuration involves multiple files: pgpool.conf for general settings, pool_hba.conf for authentication, pcp.conf for management commands and potentially failover scripts. The main config file has hundreds of parameters covering pooling, load balancing, replication, health checking and watchdog clustering.

For monitoring, PgBouncer exposes its stats through a virtual pgbouncer database where you run SHOW commands (SHOW STATS, SHOW POOLS, SHOW CLIENTS). Pgpool-II provides pcp commands and an optional SHOW POOL_NODES SQL command.

PgBouncer supports online reload (RELOAD command or SIGHUP) for most settings without dropping connections. Pgpool-II also supports reload for some settings but others require a full restart.

Troubleshooting is another area where PgBouncer wins on simplicity. PgBouncer issues are usually straightforward: authentication failures, pool exhaustion, wrong pool mode. Pgpool-II issues can be harder to diagnose because there are more moving parts. Query routing bugs, failover script failures and child process crashes all require different debugging approaches.

For teams that just need reliable pooling, PgBouncer's simplicity is a feature. Less configuration means fewer things that can go wrong. For teams that need the full middleware stack, Pgpool-II's complexity is unavoidable but the integrated solution can be easier than managing five separate tools.

Which one should you choose

The decision usually comes down to what you need beyond connection pooling.

Choose PgBouncer when:

Connection pooling is your primary need
You're running a web application with many short-lived connections
You want minimal operational overhead and resource usage
You already have separate tools for load balancing and failover (Patroni, HAProxy)
You're using a managed database service (RDS, Cloud SQL) that handles HA for you

Choose Pgpool-II when:

You need integrated load balancing with read/write splitting
You want automated failover without additional tools
You're managing your own PostgreSQL cluster and want a single management layer
Your team is comfortable with the additional configuration complexity
You need query caching at the middleware level

Or use both. Some setups put PgBouncer in front of Pgpool-II or vice versa. PgBouncer handles efficient connection multiplexing while Pgpool-II handles query routing and failover. This adds another moving part but gives you the strengths of both tools.

Don't forget about backups

Connection pooling keeps your database responsive under load, but it doesn't protect your data. No matter how well-tuned your pooler is, a dropped table or corrupted data needs a backup to recover from. Having a reliable PostgreSQL backup strategy is separate from your pooling setup, but equally important. Databasus is an industry standard for PostgreSQL backup tools, offering scheduled backups with compression and encryption for both individual developers and enterprise teams.

Final thoughts

PgBouncer and Pgpool-II aren't really competitors. They occupy different points on the simplicity-vs-features spectrum. PgBouncer is a scalpel for connection pooling. Pgpool-II is a Swiss Army knife for PostgreSQL middleware. Most production PostgreSQL deployments will benefit from one or the other, and knowing what you actually need makes the choice straightforward.

Start by answering one question: do you need just pooling, or do you need pooling plus routing and failover? That answer picks the tool for you.