A PostgreSQL server can be reachable while connections, queries or database resources are under pressure. Postgres Exporter queries supported database measurements and exposes them to Prometheus, making those observations available alongside application metrics. Teams use it to build a more useful picture than a simple connection check. Its database permissions and collectors must match the intended monitoring scope, and the exporter’s ability to connect does not establish that an old PostgreSQL release still receives security support.
Current guidance
The historical entry is PostgreSQL metrics export, now documented in prometheus-community/postgres_exporter. Current upstream lists its CI-tested database versions and separates database permissions, connection configuration and secret handling. Treat the original broad compatibility claim as historical; an exporter being able to connect does not extend PostgreSQL’s security-support lifecycle.
Choose a sidecar or a controlled multi-target deployment based on the database environment. Upstream calls multi-target support optional and useful when a sidecar cannot be installed, such as a managed database. Use predefined authentication modules so database passwords do not enter scrape URLs, and review permissions for every enabled collector or custom query.
When changing chart or exporter version, compare database labels, collector defaults, query files, TLS verification and dashboard expectations. Test one intentionally limited account and a known unhealthy connection, and inspect scrape duration so expensive monitoring queries do not compete with application traffic. Preserve enough old and new samples to validate alert changes before removing the previous exporter. This review does not certify a specific database/exporter combination.
Historical upstream link check · 2026-10-09
The recorded upstream address redirects to https://github.com/prometheus-community/postgres_exporter and returned HTTP 200 on 2026-10-09. GitHub does not mark prometheus-community/postgres_exporter archived or disabled; this does not establish active maintenance, support or compatibility. GitHub resolves the old repository identity to prometheus-community/postgres_exporter. Link availability does not certify the historical installation instructions or current security support.
Website availability is separate from project, chart and image support. Use the current guidance and primary sources on this page to assess the distribution.
Historical Kubedex content
Preserved for context. Commands, versions, prices and results below reflect the original research.
This chart bootstraps a Prometheus Postgres exporter deployment on a Kubernetes cluster using the Helm package manager. Prometheus exporter for PostgreSQL server metrics. Supported Postgres versions: 9.1 and up. This repository contains a service that runs user-defined SQL queries at flexible intervals and exports the resulting metrics via HTTP for Prometheus consumption.
Installing the Chart
To install the chart with the release name my-release:
$ helm install –name my-release stable/Prometheus-Postgres-exporter
The command deploys Postgres exporter on the Kubernetes cluster in the default configuration. The configuration section lists the parameters that can be configured during installation.
Uninstalling the Chart
To uninstall/delete the my-release deployment:
$ helm delete my-release
The command removes all the Kubernetes components associated with the chart and deletes the release.
The dashboard allows to monitor:
- rows fetched/returned/inserted/updated/deleted per second
- total qps based on commits and rollbacks
- buffers state
- deadlocks and conflicts graph
- cache hit ratio graph
- number of active connections
The author assumes that the metrics are scraped from various hosts and databases. That’s why there are placed two templates: $host and $db. Graphs would change accordingly to the selected value.
Requirements: Dashboard is based on the https://github.com/wrouesnel/postgres_exporter metrics
Disabling default metrics
To work with non-officially-supported Postgres versions you can try disabling (e.g. 8.2.15) or a variant of Postgres (e.g. Greenplum) you can disable the default metrics with the –disable-default-metrics flag. This removes all built-in metrics and uses only metrics defined by queries in the queries.yaml file you supply (so you must supply one, otherwise the exporter will return nothing but internal statuses and not your database).
Sources & further reading
Spotted something that needs another look?
Help improve this page →