Buyer’s Guide - August 2026

The 8 best PgBouncer monitoring tools, ranked

Q: How do I monitor PgBouncer with Prometheus?

Deploy the prometheus-community/pgbouncer_exporter, which exposes metrics at :9127/metrics. Add ignore_startup_parameters = extra_float_digits to pgbouncer.ini and restart PgBouncer, then configure Prometheus to scrape the exporter and import a community Grafana dashboard such as ID 14022. Note the exporter requires PgBouncer 1.8 or higher since exporter v0.11.0.

Q: Does Datadog monitor PgBouncer?

Yes. The PgBouncer check is included in the Datadog Agent (integration version 8.11.0, minimum Agent 6.0.0). You create a stats user in pgbouncer.ini and add the password to userlist.txt. The check tracks connection pool metrics, traffic, query and transaction rates, and a pgbouncer.can_connect service check. Log collection from PgBouncer is supported but disabled by default.

Q: Does Zabbix have a PgBouncer template?

There is no official Zabbix PgBouncer template. Community templates exist, such as Lelik13a/Zabbix-PgBouncer and pgSpotter, which check status and discover pools via low-level discovery. Monitoring typically requires user parameters that run SQL queries against PgBouncer’s admin console. Template quality and maintenance vary, so verify them against your PgBouncer version before relying on them.

Q: Is PgBouncer monitoring included in Percona PMM?

Yes, but it is not a first-class managed integration. PMM is an open-source database observability platform for MySQL, PostgreSQL, and MongoDB, and PgBouncer can be added as a monitored service via community guides that show Prometheus exporter configuration and importing a Grafana dashboard. If PgBouncer monitoring is the only goal, PMM is a heavy choice.

Q: What causes PgBouncer client connections to wait?

Clients wait when every server connection in a pool is busy. The key metrics are cl_waiting, maxwait, and total_wait_time. Common causes include a pool_size set too small, slow queries holding server connections, the pooling mode in use (transaction versus statement), or PostgreSQL max_connections limits. Monitoring server connection utilization tells you whether pools are sized correctly.

Q: Can I monitor PgBouncer with Grafana Cloud?

Yes. Grafana Cloud has an official PgBouncer integration with 3 pre-built dashboards and 4 alerts. You still deploy pgbouncer_exporter yourself, and Grafana Alloy scrapes it; you also need ignore_startup_parameters = extra_float_digits in pgbouncer.ini and a restart. Pricing is usage-based, so PgBouncer pool cardinality increases active series and therefore the bill.

PgBouncer sits between your applications and PostgreSQL, so the metrics that matter are pool-level: active versus waiting clients, server connection saturation, maxwait, and query throughput. This ranking grades eight tools on whether they actually collect PgBouncer’s own SHOW STATS and SHOW POOLS views, how fresh the data is, and what the bill looks like when your pool count grows.

Start with Netdata (free) Jump to rankings

Why this list exists

Most teams that go shopping for PgBouncer monitoring already own a PostgreSQL monitoring tool, and they assume the pooler comes along for free. It usually does not. PgBouncer exposes its health through an admin console (SHOW STATS, SHOW POOLS, SHOW DATABASES), and unless your tool has a collector, exporter, plugin, or template that speaks to that console, you get nothing but process-level CPU and memory. Several platforms on this list have no native PgBouncer integration at all; they get in because the community built one around them.

The second trap is resolution. Connection spikes and wait-time bursts in a pooler can appear and clear within seconds. A 15 to 60 second scrape interval smooths those events into an average that looks fine while your clients were queuing. When an incident review depends on seeing maxwait at the moment it spiked, collection granularity stops being a spec-sheet detail and becomes the whole story.

Three dimensions decide most of the outcome in this category:

Native PgBouncer coverage. Does the tool query the admin console itself, or do you deploy and maintain a separate exporter, foreign data wrapper, or community template?
Metric resolution. Per-second collection catches transient pool exhaustion; typical scrape intervals do not.
Cost shape. PgBouncer pool metrics are per-database and per-user, so per-series or per-GB pricing grows directly with pool cardinality. Flat per-node pricing does not.

A note on pricing: we do not quote list prices for any vendor except Netdata. List numbers go stale, discounts distort them, and the number that matters is how your bill scales. We describe each vendor’s pricing shape and link the official pricing page so you can run your own math. Netdata’s per-node pricing is the exception. For hands-on configuration help after you pick a tool, see the operator guides in our PgBouncer guide hub.

We assembled the shortlist from the tools PostgreSQL operators actually reach for: vendor-documented PgBouncer integrations, the official Prometheus community exporter, database observability platforms with PgBouncer coverage, and the community templates that come up in every practitioner thread on the topic. Every claim on this page is drawn from vendor documentation, project repositories, or changelogs linked in the sources below.

Native PgBouncer coverage and metric resolution carry the most weight, because they are the two things you cannot fix with effort after purchase. If the tool does not read SHOW POOLS itself, you own an exporter forever. If it samples every 60 seconds, no dashboard fixes the blind spot. Setup effort and alerting follow, because a tool that takes a week to produce its first pool-saturation alert is a tool that gets abandoned.

Tester credit

Compiled by the Netdata team - Updated August 12, 2026

Sources verified

Scoring criteria

Native PgBouncer coverage 25%
Collects SHOW STATS / SHOW POOLS out of the box, or requires a separate exporter or template.
Metric resolution and freshness 20%
Per-second collection catches connection spikes that 15-60s scrapes smooth over.
Setup and operational effort 15%
Install to a useful PgBouncer dashboard: agent, stats user, exporter, dashboards, alerts.
Alerting and anomaly detection 15%
PgBouncer-specific alerts and detection of unusual pool behavior without hand-written thresholds.
Cost predictability 10%
Flat per node, or a bill that grows with series, GB ingested, and product add-ons.
Ecosystem fit 10%
Fit with Prometheus/Grafana shops, Kubernetes, and existing Postgres monitoring.
Vendor health and maintenance 5%
Active releases and PgBouncer integration kept current with PgBouncer versions.

Vendor 01 / 08 · #netdata

Netdata

Open-source, per-second infrastructure monitoring with a built-in PgBouncer collector and ML-assisted anomaly detection.

Best for

Teams that want PgBouncer pool metrics at per-second resolution without running a separate exporter and Prometheus stack.
Small-to-mid fleets that want a flat per-node price instead of usage-based metering.
Operators who want anomaly detection on pool saturation and wait times without writing alert rules from scratch.

Pricing

Per-node pricing: one price per node with unlimited metrics, logs, users, and retention; no per-GB or per-series charges, so pool cardinality does not inflate the bill.
Netdata Cloud Business starts at $4.50/node/month on annual plans, and the per-node price decreases as node count grows.
Agents are open source (AGPL) and free; a free Cloud tier covers small fleets.
Enterprise on-premise option for air-gapped deployments.

Pros

Built-in go.d collector queries SHOW VERSION, SHOW CONFIG, SHOW DATABASES, SHOW STATS, and SHOW POOLS directly; no separate exporter process to deploy or maintain.
5-second default collection interval, configurable down to 1 second, versus the 15-60s scrape intervals typical of Prometheus-based stacks.
Per-database metrics for client connections (active, waiting, cancel_req), server connections (active, idle, used, tested, login), utilization, wait time, max wait time, transactions, queries, and network I/O.
One collector job can monitor multiple local and remote PgBouncer instances.
Netdata Cloud adds anomaly detection, alerting, and custom dashboards on top of agent data.
Flat per-node cost does not penalize per-database, per-user pool metric cardinality.

Where teams pair it

No PgBouncer-specific alerts ship preconfigured; you create alert rules for pool saturation, maxwait, and waiting clients yourself.
The collector requires manual setup (create a stats user, add a job); it does not auto-detect PgBouncer instances.

Verdict

Netdata is the only tool in this list whose PgBouncer support is a built-in collector that reads the admin console directly, at 5-second (or 1-second) resolution, with per-database breakdowns of every connection state that matters. That combination is exactly what pooler incidents demand: when clients start queueing, you see the waiting count, the server saturation, and the maxwait climb in near real time instead of in a 60-second average. The honest caveats are that you write your own PgBouncer alert rules and set up the stats user by hand, and Prometheus-centric shops cannot scrape the collector without extra work. For pool health visibility per dollar and per hour of setup, it leads this category.

Start free ->

Vendor 02 / 08 · #prometheus-grafana

Prometheus + Grafana

The open-source metrics stack: pgbouncer_exporter scraped by Prometheus, visualized in Grafana.

Best for

Teams already running Prometheus and Grafana who want PgBouncer metrics in the same stack.
Kubernetes shops that deploy the exporter as a sidecar or via Helm.
Organizations that prefer to own and operate their monitoring stack end to end.

Pricing

Open source and self-hosted: you run and operate Prometheus, Grafana, and the exporter yourself, and the real cost is infrastructure plus engineering time.
Cost grows with the storage and retention you provision and the exporter fleet you maintain.
Grafana Cloud is the hosted alternative, billed per active series and per GB ingested.

Pros

pgbouncer_exporter is an official Prometheus-community project (Apache-2.0), exposing metrics at :9127/metrics.
Exports the full pool metric set: client active/waiting, server active/idle/login/tested/used, maxwait, query and transaction counts and durations, bytes sent and received.
Multiple community Grafana dashboards exist (including dashboard ID 14022) for quick visualization.
Prometheus alerting rules can be written against any exported metric.
Works with any Prometheus-compatible backend: Grafana Cloud, VictoriaMetrics, Thanos.

Cons

You run and maintain a separate exporter process for every PgBouncer instance.
Requires editing pgbouncer.ini to add ignore_startup_parameters = extra_float_digits, then restarting PgBouncer.
Typical scrape intervals of 15-60s miss connection spikes that live between scrapes.
No built-in alerting or anomaly detection; you write and maintain the PromQL rules.
The exporter requires PgBouncer 1.8 or higher (since exporter v0.11.0).

Verdict

This is the de-facto open-source answer, and the metric coverage via pgbouncer_exporter is genuinely complete. If your organization already speaks PromQL and runs Grafana, adding PgBouncer is a known quantity: exporter, scrape config, imported dashboard, hand-written alerts. What you sign up for is the assembly and the upkeep, plus a resolution ceiling set by your scrape interval. It ranks second because the coverage is excellent and the ecosystem is everywhere, not because it is easy.

Read full Netdata vs Prometheus -> Grafana pricing ->

Vendor 03 / 08 · #grafana-cloud

Grafana Cloud

Grafana Labs’ hosted platform with a managed PgBouncer integration built on pgbouncer_exporter and Alloy.

Best for

Teams that want Grafana dashboards without operating their own Prometheus and Grafana servers.
Organizations already in Grafana Cloud that want PgBouncer in the same tenant.
Kubernetes users who can deploy the exporter with the provided Helm chart.

Pricing

Usage-based with volume tiering: billed per active metric series and per GB of logs, traces, and profiles ingested, plus a platform fee on paid tiers.
PgBouncer pool metrics are per-database and per-user, so series count, and therefore the bill, scales with pool cardinality.
A free tier exists with limited active series and ingestion.

Pros

Official integration ships prebuilt pre-built dashboards (cluster overview, overview, logs) and 4 alerts covering client waiting connections, wait time, and server saturation.
Collects both metrics and logs from PgBouncer.
Maintained by Grafana Labs with a documented changelog.
Works with Grafana Alloy for unified metric and log collection.

Cons

You still deploy and run pgbouncer_exporter yourself; the integration only configures Alloy to scrape it.
Requires the pgbouncer.ini ignore_startup_parameters change and a PgBouncer restart, plus enabling a log file for log collection.
Usage-based pricing means pool cardinality directly increases active series and cost.
Scrape interval is set in your Alloy config, typically 15-60s.

Verdict

Grafana Cloud is the strongest managed Grafana option here because it ships real PgBouncer-specific dashboards and alerts rather than leaving you to import community work. The trade is twofold: the exporter is still yours to operate, and every pool you add is billable series. For teams already paying for Grafana Cloud, this is the obvious path. For teams choosing fresh, weigh the per-series cost against per-node alternatives before pool count grows.

Read full Netdata vs Grafana -> Grafana Cloud pricing ->

Vendor 04 / 08 · #datadog

Datadog

A commercial observability platform with a first-party PgBouncer check built into the Datadog Agent.

Best for

Organizations already standardized on Datadog for APM, logs, and infrastructure.
Teams that want PgBouncer metrics beside application traces and RUM in one UI.
Enterprises that need Datadog’s incident management and SLO tooling around the database tier.

Pricing

Modular, usage-based pricing: per host for infrastructure, per GB for logs, per custom metric, per container, per APM span, and more.
The bill grows with host count, custom metrics beyond included allotments, log ingest, and every additional product enabled.
A limited free tier exists for infrastructure monitoring.

Pros

First-party PgBouncer check (integration version 8.11.0) ships inside the Datadog Agent; no separate exporter to install.
Tracks connection pool metrics, traffic, query and transaction rates, wait times, and a pgbouncer.can_connect service check.
Log collection from PgBouncer is supported via the Agent.
Autodiscovery templates cover containerized PgBouncer deployments.
Metrics flow into Datadog’s broader APM, log, and alerting platform.

Cons

Requires creating a dedicated Datadog stats user in pgbouncer.ini and userlist.txt.
Resolution is tied to the Agent check interval, typically 15s or longer.
Usage-based modular pricing means PgBouncer monitoring rides a per-host platform bill that grows with custom metrics and log volume.
No PgBouncer-specific anomaly detection beyond generic Datadog monitors.

Verdict

Datadog’s PgBouncer check is solid first-party work: enable it, create the stats user, and pool metrics appear with minimal fuss. The fit weakens on economics and resolution. If you only need pooler visibility, you are buying into a broad per-host platform whose bill grows with every product you touch, and 15-second-plus check intervals blunt the connection-spike detail that makes PgBouncer monitoring valuable. For existing Datadog shops it is an easy yes; as a standalone PgBouncer choice it is hard to justify.

Read full Netdata vs Datadog -> Datadog pricing ->

Vendor 05 / 08 · #influxdb-telegraf

InfluxDB + Telegraf

Time-series platform that collects PgBouncer metrics through the Telegraf pgbouncer input plugin.

Best for

Teams already using InfluxDB for time-series storage and Telegraf for collection.
Organizations that want long-term PgBouncer metric retention for capacity analysis.
Users who prefer one agent (Telegraf) collecting many integrations.

Pricing

Multiple models: Cloud Serverless is usage-based across data in, query count, storage, and data out; InfluxDB 3 Core is open source and self-hosted; Enterprise and Dedicated are custom-priced.
On hosted tiers the bill grows with ingestion volume, storage, and query load.
Telegraf itself is open source; you run and operate it.

Pros

Telegraf pgbouncer input plugin collects instance stats and per-pool metrics: cl_active, cl_waiting, maxwait, sv_active, sv_idle, sv_login, sv_tested, sv_used.
Telegraf is a mature, widely deployed open-source collector with 40+ output plugins.
Works with InfluxDB Cloud, InfluxDB OSS, and any Telegraf-supported output.
Configuration is minimal: a connection string or URL.

Cons

No PgBouncer-specific dashboards or alerts ship with the plugin; you build them yourself.
Collection interval follows Telegraf’s global interval, typically 10-60s.
No anomaly detection or ML-assisted alerting.
The plugin is a community input, not a managed integration with support SLAs.

Verdict

Telegraf’s pgbouncer plugin covers the core pool metrics with almost no configuration, which makes this stack respectable for collection. It stops there. Dashboards, alerts, and any PgBouncer-specific analysis are yours to build, and resolution is bound to Telegraf’s global interval. If InfluxDB is already your time-series home, this is a natural extension. As a complete PgBouncer monitoring answer, it is a collector in search of the rest of the product.

See the PgBouncer integration -> InfluxData pricing ->

Vendor 06 / 08 · #crunchy-pgmonitor

Crunchy Data pgMonitor

Open-source PostgreSQL monitoring stack with first-class PgBouncer support via pgbouncer_fdw.

Best for

PostgreSQL-focused teams that want deep PgBouncer and Postgres metrics in one stack.
Organizations using Crunchy Data’s PostgreSQL distribution or Crunchy Bridge.
Teams that prefer SQL-based metric collection through foreign data wrappers.

Pricing

Open source and self-hosted: you run and operate pgMonitor, its exporters, and Grafana yourself.
Crunchy Data sells commercial PostgreSQL support and Crunchy Bridge; pgMonitor itself is open source.
Cost grows with the infrastructure you run and the engineering time to maintain the stack.

Pros

Actively maintained; version 5.2.1 added support for PgBouncer 1.24 (July 2025).
Uses pgbouncer_fdw to query PgBouncer’s admin views through PostgreSQL foreign data wrappers, avoiding a separate exporter process.
Ships Grafana dashboards covering PostgreSQL and PgBouncer together.
Purpose-built for PostgreSQL ecosystems, with connection counts and pool health as first-class metrics.

Cons

Requires installing pgbouncer_fdw and configuring foreign tables, a non-trivial setup.
Tied to the Crunchy Data ecosystem; less useful outside a PostgreSQL-centric stack.
Resolution is bound to the postgres_exporter scrape interval, typically 15-60s.
No PgBouncer-specific anomaly detection; alerting is threshold-based.

Verdict

pgMonitor is the deepest PostgreSQL-ecosystem option on this list, and its PgBouncer support tracks upstream releases more closely than most vendor integrations. Querying the admin console through a foreign data wrapper is an elegant way to avoid running yet another exporter. The cost of that elegance is setup complexity and a strictly Postgres-centric scope. If your world is PostgreSQL and you want the pooler and the database in one Grafana, this is the connoisseur’s pick; everyone else should look higher up the list.

See pgMonitor on GitHub -> Crunchy Data monitoring blog ->

Vendor 07 / 08 · #percona-pmm

Percona Monitoring and Management (PMM)

Open-source database observability platform from Percona for MySQL, PostgreSQL, and MongoDB.

Best for

Database-heavy teams running Percona distributions or PostgreSQL at scale.
Organizations that want a dedicated database observability platform rather than general-purpose monitoring.
Teams that want Query Analytics (QAN) beside PgBouncer metrics.

Pricing

Open source and self-hosted: you run and operate the PMM server and client agents.
Percona sells support subscriptions and consulting; the software itself is open source.
Cost grows with the infrastructure for the PMM server and the time to maintain it.

Pros

Actively maintained open-source database observability platform (PMM 3.x with recent PostgreSQL enhancements).
PgBouncer can be added as a monitored service alongside PostgreSQL, with Grafana-based dashboards.
Includes Query Analytics for PostgreSQL query performance.
A community-documented PgBouncer dashboard is available for PMM.

Cons

PgBouncer support is not a first-class managed integration; community guides show adding it via Prometheus exporter configuration.
Requires running a PMM server plus client agents, a significant footprint for pooler monitoring alone.
No PgBouncer-specific alert templates documented in official PMM docs.
Resolution is tied to the Prometheus scrape intervals configured in PMM.

Verdict

PMM makes sense when PgBouncer is one item in a broader database observability mandate: you get Query Analytics, PostgreSQL depth, and a pooler dashboard in the same Grafana. It does not make sense as a PgBouncer-only deployment, because you are standing up a full server and agent fleet to watch a single lightweight process. The PgBouncer path also leans on community guides rather than an official managed integration. Rank it here if you already run PMM; skip it if the pooler is the whole problem.

See the PMM project -> Percona monitoring ->

Vendor 08 / 08 · #zabbix

Zabbix

Enterprise open-source monitoring platform with community PgBouncer templates.

Best for

Organizations already running Zabbix for infrastructure and network monitoring.
Teams that want a self-hosted enterprise platform without per-node license fees.
Operators comfortable with Zabbix templates, user parameters, and the agent-based model.

Pricing

Open source and self-hosted: you run and operate it yourself, and the cost is the infrastructure and engineering time to maintain it.
Zabbix sells fixed-price support subscriptions and a hosted Zabbix Cloud SaaS.
Cost grows with infrastructure and support tier, not per monitored host.

Pros

Mature, actively maintained platform with a large template ecosystem.
Community PgBouncer templates exist (Lelik13a/Zabbix-PgBouncer, pgSpotter) that check status and discover pools via LLD.
The agent model can run SQL queries against PgBouncer’s admin console via user parameters.
No per-host license fees; support subscriptions are fixed-price.

Cons

No official Zabbix PgBouncer template; you depend on community templates of varying quality and maintenance.
Setup means writing user parameters or adapting community templates, more work than a purpose-built integration.
Resolution follows Zabbix item intervals, typically 30-60s or longer.
No PgBouncer-specific anomaly detection; alerting is threshold-based.

Verdict

Zabbix can monitor PgBouncer, in the same sense that Zabbix can monitor most things: with enough template surgery and user parameters. There is no official template, so you are betting on community projects and your own SQL against the admin console. For a Zabbix-standardized organization that bet is reasonable, and the fixed support pricing is genuinely predictable. For anyone choosing a tool specifically for pooler visibility, every option ranked above it gets to a useful dashboard faster and at better resolution.

Read full Netdata vs Zabbix -> Zabbix subscriptions ->

Frequently Asked Questions

What is the best PgBouncer monitoring tool?

Netdata ranks first in this comparison because it is the only tool with a built-in PgBouncer collector that queries the admin console directly at per-second resolution, with per-database breakdowns of every connection state. Prometheus + Grafana with pgbouncer_exporter is the strongest open-source self-hosted alternative if you already operate that stack. Grafana Cloud is the best managed option with pre-built PgBouncer dashboards and alerts.

What PgBouncer metrics should I monitor?

Start with connection state per database: client connections (active, waiting, cancel_req) and server connections (active, idle, used, tested, login). Then watch the wait metrics, maxwait and total_wait_time, which reveal queue depth and client starvation before users complain. Track throughput (queries/s, transactions/s, average query and transaction times) and client and server connection utilization percentages so you can see saturation coming.

How do I monitor PgBouncer with Prometheus?

Does Datadog monitor PgBouncer?

Does Zabbix have a PgBouncer template?

What is the difference between monitoring PostgreSQL and monitoring PgBouncer?

PostgreSQL monitoring covers database internals: query performance, replication lag, table and index stats, pg_stat_activity. PgBouncer monitoring covers the pooler: client versus server connections, wait queues, maxwait, pool saturation, and pooled query and transaction throughput. A Postgres monitoring tool does not automatically monitor PgBouncer; most need a separate exporter, plugin, or template. Both matter, because pooler problems appear as connection waits and saturation before they surface in Postgres metrics.

How often should PgBouncer metrics be collected?

Collect PgBouncer metrics every 1 to 5 seconds. Connection spikes and wait-time bursts can appear and disappear within seconds, so resolution matters more here than in most database monitoring. Netdata defaults to 5s (configurable to 1s); typical Prometheus scrape intervals of 15-60s smooth over short-lived saturation events. Choose your interval based on whether you need to catch transient pool exhaustion or only long-term trends.

Is PgBouncer monitoring included in Percona PMM?

What causes PgBouncer client connections to wait?

Can I monitor PgBouncer with Grafana Cloud?

The 8 best PgBouncer monitoring tools, ranked

How we evaluated PgBouncer monitoring tools

Netdata

Prometheus + Grafana

Grafana Cloud

Datadog

InfluxDB + Telegraf

Crunchy Data pgMonitor

Percona Monitoring and Management (PMM)

Zabbix

Frequently Asked Questions

Book Your Free Demo