PostgreSQL monitoring with postgres_exporter: what it connects and how
Many PostgreSQL estates run without a reliable view of replication lag, WAL growth or connection pressure until one of them causes an outage. postgres_exporter is a community-maintained exporter that runs beside PostgreSQL and exposes its metrics over HTTP so that Prometheus can scrape them. It does not change how the database behaves. It reads statistics that PostgreSQL already keeps, converts them into time series that Prometheus can store, query and alert on, and leaves the database itself untouched. This section explains what the integration connects, so the team can scope the work before anyone changes a production server.
The integration has five parts. The first is a database role that the exporter uses to log in, which should be a least-privilege account rather than a superuser. PostgreSQL's built-in pg_monitor role grants read access to monitoring views, and the team should confirm that it covers every view its chosen collectors read. The second part is the collectors, which are groups of queries that the exporter enables or disables by flag. The third is a Prometheus scrape job that points at the exporter's HTTP endpoint. The fourth is alert rules for lag, WAL growth and connections. The fifth is dashboards. Each part needs an owner and a review step, and the sibling sections on alerting and dashboards cover the last two in more depth.
The exporter is community-maintained rather than an official PostgreSQL project, so its collector names, flags and default behavior can change between releases. Before deployment, the team should read the documentation and changelog for the exact release it will run, confirm the collector list and flags against that release, and record the version in its configuration repository. The same check applies to the database. The metrics that matter depend on the PostgreSQL major version, and the PostgreSQL versioning policy lists version 14 as supported until November 12, 2026, with 13 and earlier unsupported. Teams on older versions should plan an upgrade before they design their alert thresholds, because the thresholds and the views behind them will change.
Several decisions should be made early. The first is where the exporter runs: on the database host, as a sidecar in Kubernetes, or on a separate host that connects over the network. The second is how many exporter instances reach each primary and standby, and whether each instance reports against one database or several. The third is how the connection is protected. Credentials for the monitoring role belong in a secrets store, not in a plain configuration file. Traffic between Prometheus and the exporter should use TLS where it crosses a trust boundary, because basic authentication without TLS sends credentials in cleartext. The team should also count the exporter's own sessions against max_connections, since a monitoring tool that adds sessions can add to the pressure it is meant to measure. If a pooler such as PgBouncer sits in front of the database, confirm which endpoint the exporter scrapes, because the pooler changes what the connection metrics show.
What the team needs before connecting PostgreSQL to Prometheus
Six decisions need to be settled before the first scrape. They form one chain: Prometheus must reach the exporter, the exporter must authenticate to PostgreSQL with a read-only role over an encrypted path, and a named person must own the alerts that result.
Prometheus server and storage
Prometheus pulls metrics from each exporter on a schedule and keeps them in a local time series database, so the server is the first component to size. Local storage is not clustered or replicated, and default retention is 15 days unless you configure limits by time or size. Confirm disk capacity, retention settings, and who backs up or rebuilds the server if it fails.
PostgreSQL versions in scope
Confirm that every monitored instance runs a major version that is still supported. At the time of writing, PostgreSQL 14 through 18 are supported, and version 14 reaches end of support on November 12, 2026, so a cluster on 14 needs an upgrade plan alongside the monitoring project. Record the version of each instance and check it against the exporter release you deploy.
Least-privilege exporter role
Create a dedicated login role for the exporter and grant it membership in pg_monitor, the built-in role for read access to monitoring views. Do not reuse an application or superuser account. Allow the exporter host in pg_hba.conf, store the credential in your secrets system, and test the connection from the exporter host before changing any Prometheus configuration.
Network paths in both directions
Prometheus must reach each exporter's HTTP port, and each exporter must reach its PostgreSQL listener on the database port. Map every hop, including firewalls, security groups, load balancers and any PgBouncer in front of the database, and record which source addresses are permitted. Test both paths from the actual hosts, because network diagrams often lag behind firewall changes.
TLS certificates across boundaries
If the scrape or the exporter-to-database connection crosses a network boundary, such as between data centers, cloud accounts or a DMZ, encrypt it with TLS. Prometheus supports TLS and client certificate authentication with TLS 1.2 as the minimum, and basic authentication without TLS exposes credentials in cleartext. Decide who issues and renews the certificates, where private keys are stored, and how renewal is tested before expiry.
Named owners for alerts and rollout
Name one owner for alert routing who decides which Alertmanager receivers page on-call and who approves threshold changes. Name a second person who can restart the exporter and confirm that scrapes resume during rollout, since role grants and configuration changes may require a restart. Without these two owners, the first failed scrape or alert storm has no clear decision maker.
How Prometheus pulls PostgreSQL metrics through postgres_exporter
Prometheus reaches PostgreSQL indirectly. It does not connect to the database itself. Prometheus scrapes each postgres_exporter instance over HTTP on a schedule, and the exporter opens its own connection to PostgreSQL, runs its queries and returns the results as metrics on that scrape. Every target Prometheus scrapes is therefore a pair of components: the exporter process and the database it queries. Before you deploy, decide where each exporter runs, how many instances will exist, and whether Prometheus will find them through static configuration or service discovery. Static configuration is simple to audit for a small estate. Service discovery suits environments where database hosts appear and disappear, but it moves the question of which hosts are in scope into the discovery rules, which your team must own.
The exporter queries PostgreSQL on every scrape, so scrape interval is also a database load decision. Each scrape runs the enabled collectors, and some collectors, such as the one for statement statistics, read more data than others. Confirm with your database team which collectors are acceptable on production primaries, and test the scrape duration on a non-production copy before you set the interval. The exporter's own connection account should be a dedicated role with the least privilege its collectors need, typically membership in the built-in pg_monitor role rather than a superuser account. Ask the implementation partner, or your own team, to show the exact role grants and the connection settings in the exporter configuration, because a broad credential stored in a scrape config is a common finding in reviews.
Prometheus stores what it scrapes in a local time series database. Samples are written to two-hour blocks, with a write-ahead log for recovery, and the default retention is 15 days. Retention can be set by time or by size, and the choice affects disk sizing more than anything else in the storage plan. Local storage is not clustered or replicated. If the Prometheus server is lost, the history stored on it is lost with it unless you have a copy. Treat the Prometheus host like any other single-node database: plan its disk, its snapshots and its restore procedure, and decide whether a second Prometheus server scraping the same targets is acceptable for resilience. Remote write is the supported route to longer retention. It sends samples to an external long-term storage system, which then carries the retention and replication burden. Choosing that system is a separate design decision and is not covered by the default setup.
Prometheus values reliability over precision, as its documentation states. It is not designed to record every database event exactly, and scrapes can miss short spikes, counters can reset when a process restarts, and a missed scrape leaves a gap. This makes sampled PostgreSQL state well suited to trend lines, capacity planning and alert rules on lag, connection saturation or a stalled replica. It is not suited to billing, chargeback, regulatory audit trails or forensic records of who ran which query. If a stakeholder wants those outcomes from this monitoring, state the limit in the design and point them to the PostgreSQL logs, audit extensions or archiving that your organization already uses for that purpose.
Before you start the build, confirm three things with the team that will run the stack. First, the scrape interval and retention you need, the disk that implies, and who owns that disk. Second, whether the exporter role and connection credentials will be stored and rotated under your existing secrets process. Third, whether the metric history must survive loss of the Prometheus host, which determines whether remote write and a second scrape path belong in the first release or in a later phase. Answering these early keeps the alerting and dashboard work from being rebuilt when retention or access requirements arrive later.
Configuring PostgreSQL monitoring in the order that keeps access narrow
This sequence gives the exporter read-only visibility into each PostgreSQL instance before any metrics leave the database host, then adds collection and scraping in layers. Each step ends with a check so a fault is found where it starts. The result is one exporter per instance, scraped by Prometheus, using a credential that cannot change data.
Create the exporter role with pg_monitor
The database administrator creates a dedicated login role on each instance, sets a strong password from the team's secrets store, and grants membership in the built-in pg_monitor role. The role gets no superuser attribute and no write grants on application schemas. To confirm it works, sign in as the exporter role and run a read query against a statistics view such as pg_stat_database, which should succeed. Then attempt a write in a non-production instance, which should be refused. Only proceed when both results match.
Set the connection string and SSL mode
The platform engineer writes the exporter's data source name with the exporter role, host, port and database, then sets the SSL mode the server requires. If the server enforces TLS, the exporter needs the matching CA certificate file and the mode must not be weaker than the server policy. Keep the connection string in a file readable only by the exporter's service account, not in shell history or unit files. The check is a clean startup with no connection errors in the exporter log, followed by a psql connection from the exporter host using the same parameters.
Enable only the collectors the team needs
The engineer turns on the collectors for replication, write-ahead log activity and statements, and leaves the rest disabled to keep the metric set and query load small. Statement metrics depend on the pg_stat_statements extension being loaded through shared_preload_libraries and created in the target database, along with any settings the team chooses. Confirm the extension and its configuration for the PostgreSQL version in use, because supported versions and extension behavior differ by release. The check is the exporter's metrics endpoint showing the enabled collector families and none of the disabled ones.
Start one exporter per database instance
The operator runs a separate postgres_exporter process for each PostgreSQL instance, each with its own listen port and its own data source name, under the service manager of the host. A single exporter pointed at several instances makes it harder to tell which database a metric came from and widens the blast radius of one credential. Record the port assignments in the monitoring inventory. The check is a local request to each exporter's metrics endpoint returning data that matches the instance it reads from.
Add a scrape job listing each exporter
The Prometheus administrator adds a scrape job to the configuration with one target per exporter, using static configuration or service discovery that the team already runs. Each target gets labels such as instance name and environment so that dashboards and alert rules can separate databases. Because the lifecycle endpoint is disabled by default, reload the configuration with the method the team has approved, such as a signal or service restart. The check is the Prometheus targets view showing every exporter with the state UP and a recent last-scrape time.
Confirm metrics in the expression browser
The engineer opens the expression browser in Prometheus and queries one metric from each enabled collector family, filtering by the instance label. Replication, write-ahead log and statement series should each return values for every database that has the matching feature enabled. If statement metrics are missing, check the extension and its settings on that instance before changing the scrape configuration. The check is a non-empty result for each enabled family on each instance, which becomes the baseline for the alert rules and dashboards that follow.
Protecting the database role, the exporter endpoint and the Prometheus server
A PostgreSQL metrics pipeline has three entry points: the database login the exporter uses, the exporter's HTTP endpoint, and the Prometheus server that scrapes it. Each needs its own access control, and a gap in one can expose the others. The cards below cover these controls in the order an operator would configure them.
Least-privilege monitoring role
Give the exporter its own login role with membership in pg_monitor and no superuser privilege. The role should only read statistics and monitoring views, and it should not own or write to application schemas. Before go-live, test the role against each collector you enable, because some collectors need access that a narrow role may lack. Confirm the required grants in the exporter documentation for your PostgreSQL version.
Connection string kept in a secret store
The exporter's connection string carries the database password, so load it from a secret store or a root-owned environment file at service start. Placing it inline in a systemd unit file exposes it to anyone who can read that unit, and it often lands in configuration repositories and backups. Check that file permissions limit access to the service account, and confirm that rotating the password requires a single change.
Restrict the exporter port
The exporter serves metrics on its own HTTP port, and only the Prometheus servers need to reach it. Limit that port with host firewall rules or security groups that allow only the Prometheus source addresses, and keep it off public networks and shared load balancers. From a host that Prometheus does not use, confirm that the endpoint refuses connections. Recheck after network changes, since a permissive rule added during troubleshooting often stays in place.
TLS and authentication on scrapes
Prometheus supports TLS and client certificate authentication with TLS 1.2 as the minimum version, and it supports HTTP basic authentication with bcrypt-hashed passwords. Basic authentication without TLS exposes those credentials in cleartext on the network, so enable TLS on every scrape path before adding passwords. Confirm that the exporter version you run offers the same transport settings, and test the scrape with the certificate chain that the Prometheus server trusts.
Admin and lifecycle endpoints
Prometheus disables its admin HTTP APIs by default. The --web.enable-admin-api flag enables destructive operations, and --web.enable-lifecycle enables reload and shutdown endpoints. Keep both off on production servers unless a named automation job requires them. If you enable lifecycle endpoints, restrict the hosts that may call them and review the running command line after each change window, since flags added for testing often persist.
SSO in front of the Prometheus UI
Prometheus has no built-in single sign-on, and its security model notes that it has no built-in CSRF protection on mutating endpoints. Place an authenticating reverse proxy in front of the web UI and API, integrated with your identity provider, and make the proxy the only path to the server. Confirm which identity product your team will integrate with, and test that direct access to the Prometheus port is blocked.
Which PostgreSQL signals feed which alert and dashboard
This table maps each PostgreSQL signal group to the alert or dashboard panel it feeds, the role that acts on it and the first check that role runs. Use it to decide which collectors to enable and which thresholds need a named owner before alerting goes live. Take metric names from the postgres_exporter release you deploy, and test every row on a non-production database first.
| Signal group | Feeds which alert or dashboard | Owner and first check |
|---|---|---|
| Replication state and lag on the primary | Lag alert per standby, plus a replication panel showing each standby's position. Set the threshold from your recovery objective. | Database on-call. First check that each standby is connected and streaming, then compare its replay position with the primary. |
| Replication state on standbys | Panel showing whether each hot standby is replaying WAL and accepting read-only queries. Alert when replay stops advancing. | Database on-call. First check whether replay position moves between two samples, then the standby server log for errors. |
| WAL generation and archive status | Panel for WAL write rate and archiver progress. Alert when archiving fails or falls behind the current WAL position. | Backup or recovery owner. First check the archiver status and the last archived WAL segment against the current position. |
| Connection count against the configured maximum | Panel of connections by state. Alert when usage approaches the configured maximum, which is set in the server configuration. | Application platform owner. First check which application or pooler, such as PgBouncer, holds idle or long-lived connections. |
| Statement-level activity | Panel from the statements collector, which needs pg_stat_statements loaded. Alert on sustained growth in total execution time, not single slow calls. | Team that owns the workload. First check the top statements by total time in the interval and any deployment made since the change began. |
| Exporter health and scrape status | Alert when the target is down or a collector reports an error. Without it, other rows show gaps that look like healthy values. | Monitoring owner. First check the scrape status for the target and the exporter log for collector failures after a restart or upgrade. |
| Verification before alerting | Each row's metric names, panels and alert expressions tested against a test database under controlled load before paging depends on them. | Monitoring owner. First check that the metric appears after a scrape and that the alert fires on a deliberate test condition. |
Alert rules for PostgreSQL replication lag and connections
Set each replication lag and connection threshold from your own measured baseline and from the recovery objectives your business has agreed. Start by recording lag on each standby across normal load, nightly batch jobs, and planned maintenance, and record connection counts at peak against the configured limit and against the pool size if PgBouncer sits in front of the server. A generic number from documentation or a blog post says little about your write volume or your failover plan. Ask the database owner and the application owner to agree on how much stale data a read replica may serve and how long a failed standby may stay out of service before the team must act. Those answers become the thresholds.
Use a duration clause, the for setting in a Prometheus alerting rule, so a brief spike does not page anyone. A bulk load can push lag up for a few minutes and then clear by itself, so the rule should fire only when the condition persists long enough to matter for your recovery objective. Split each signal into two levels. The warning rule should reach a channel that people read during working hours, and the critical rule should page the on-call engineer. Keep the critical threshold tied to the point where a failover decision or a standby rebuild becomes necessary. PostgreSQL does not detect a failed primary or notify a standby on its own, so these alerts are one input to whatever external failover tooling you choose, not a substitute for it.
Alertmanager receives the firing alerts from Prometheus and routes them. Group alerts by labels such as cluster and instance so that one failing standby produces one notification rather than a stream of separate messages. Use inhibition so that connection pressure alerts are suppressed when the same instance is already reported as down, which keeps the on-call channel focused on the root cause. Use silences with an expiry time for planned maintenance windows, and make sure each silence names an owner so it does not outlive the work. For high availability, run more than one Alertmanager instance in cluster mode using the --cluster flags, and configure Prometheus to send to every instance directly. Confirm the cluster peer and gossip settings against the Alertmanager documentation for your version before relying on them.
Test every rule by inducing the condition in a non-production environment before you depend on it. On a test standby, pause WAL replay long enough to push lag past the warning threshold, then past the critical threshold, and confirm the alert fires only after the duration clause has elapsed. Open connections with a load script until the pool or the server limit is reached, and confirm the expected receiver gets the notification. Trigger a second, related alert to check that inhibition suppresses it, create a silence to check that it mutes the right alerts, and then clear each condition to confirm that resolved notifications arrive. Repeat the tests after every Prometheus or Alertmanager upgrade and after any change to labels, so that routing still matches your on-call structure.
Common PostgreSQL monitoring failures and their fixes
This table pairs six common failures in a postgres_exporter setup with the likely cause, the fix and where the change belongs: in the database, in Prometheus or in the exporter. Use it as a triage list when a target, metric, count or alert looks wrong after go-live. Most of these failures come from access or configuration, so check the monitoring role and collector settings before you change alert rules.
| Failure | Likely cause | Fix | Where the change goes |
|---|---|---|---|
| Target shows down | The exporter connects with a role that cannot log in, has no password matching the authentication method in use, or has no pg_hba.conf entry for its source address. | Create or correct the monitoring role with login and a password, add a pg_hba.conf entry for the exporter host, then update the exporter connection string or secret and reload. | Database for the role and pg_hba.conf. Exporter for the connection string. |
| Metrics are missing | A collector that produces the metric family is disabled in the exporter, or the view or extension it reads is not installed in the database the exporter connects to. | Enable the collector for the metric family you need and confirm the metric appears in the exporter's own output. For statement-level metrics, confirm the required extension is installed in the target database. | Exporter configuration. Database only if an extension or view is missing. |
| Scrapes time out on busy databases | Expensive collectors run on every scrape, and the scrape timeout is shorter than the time the exporter needs to answer, often on large catalogs or statistics views. | Disable collectors you do not use, measure the exporter's scrape duration, then set the scrape timeout above that duration and below the scrape interval. Move heavy collectors to a longer interval if your version supports it. | Prometheus scrape configuration. Exporter collector settings. |
| Connection counts look low | The monitoring role is not a member of pg_monitor, so pg_stat_activity hides sessions owned by other roles. | Grant the monitoring role membership in pg_monitor, which includes the statistics-reading privileges needed to see other sessions. Compare the exporter's count with a privileged query on pg_stat_activity to confirm. | Database |
| Alerts fire during a planned failover | Standbys were relabeled, or the primary role label moved to another instance, so rules that expect a fixed primary fire against the wrong target during switchover. | Derive role labels from what the database reports at scrape time, and avoid hard-coding instance names in alert rules. Create Alertmanager silences for planned switchover windows. | Prometheus relabeling and alert rules. Alertmanager silences. |
| Retention is shorter than expected | Local retention defaults to 15 days, and the team assumed a longer window without setting retention by time or size on the Prometheus server. | Set the retention time or size on the Prometheus server to the window your reviews need, and size the disk for it. For longer history, plan remote write to external long-term storage, because local storage is not clustered or replicated. | Prometheus server configuration. Storage planning. |
Dashboards, retention and when to add long-term storage
Dashboards turn the postgres_exporter series into something an on-call engineer can read in under a minute, and retention decides how far back those dashboards can look. Build the dashboards in Grafana on top of the Prometheus data source, and split every panel into two groups, primary and standby, so that a lagging replica never hides behind a healthy primary average. The core panels cover four areas: replication lag on each standby, WAL generation and replay progress, active and idle connections against the configured maximum, and statement-level activity from the pg_stat_statements collector. Keep the same panel titles and label filters across both groups so the layouts can be compared side by side during an incident.
Replication panels need the most care. Lag on a standby should be shown in both bytes and time where your exporter version exposes both, because a standby that is ten minutes behind and one that is ten megabytes behind call for different responses. Label the standby role explicitly in the panel query rather than inferring it from instance names, since a failover changes which host is the primary and dashboards built on hostnames will mislead people after a switchover. Confirm with your exporter release notes which lag and WAL metrics it emits, because metric names have changed across versions and a dashboard that silently returns no data is worse than no dashboard.
Retention planning starts from the Prometheus default of 15 days of local storage, which you can change by time or by size. Decide how many days of history your capacity reviews, post-incident analysis and month-over-month connection trends actually need, then set the local retention to cover the common cases and size the disk for it with headroom. Local storage is a single node and is not clustered or replicated, so treat the Prometheus data directory like any other single-node database: back it up or accept its loss, and monitor disk usage so retention limits do not silently drop data you still need.
When local retention is not enough, the documented routes to external long-term storage are the remote write and remote read protocols. Remote write sends samples to a storage system as they are ingested, and remote read lets Prometheus query data held elsewhere. Add long-term storage when you need history beyond what one local disk can hold, when several Prometheus servers must be queried as one, or when you need storage that survives the loss of the monitoring host. Ask the vendor or project of the receiving system to confirm its remote write and remote read support and the version you will run before you commit to the design.
Pairing Prometheus with Grafana in detail, including the data source setup and Grafana alerting compared with Alertmanager, is covered on the separate page for Prometheus and Grafana dashboards and alerting. Before you build the dashboards described here, confirm the retention target with the teams who will use the history, and write it into the scope so that disk sizing, backup decisions and any long-term storage budget are agreed before implementation begins.
PostgreSQL monitoring cost, effort and what your team must provide
How much does PostgreSQL monitoring with Prometheus cost to implement?
The software carries no license fee, so the cost is the implementation work, the infrastructure that runs Prometheus and its storage, and the people who operate it. DeployOpen does not publish a price list. A quote follows from a written scope that lists the instances, collectors, alert rules, dashboards and retention period you need. Ask the quote to split one-time work (design, build, handover) from recurring work (upgrades, rule review and any support retainer). Quotes are only comparable when they cover the same scope, so check each line before comparing totals.
What drives the cost of a postgres_exporter monitoring project?
The main drivers are the number of PostgreSQL instances and clusters, the collectors you enable, how many alert rules you design and how many owners must approve them, the number of dashboards, and how long you keep metrics. Replication, WAL and statement statistics usually add scope beyond basic health metrics. Retention matters because Prometheus keeps local data for 15 days by default. Longer history usually means remote write to external long-term storage, which is extra design and infrastructure work. Internal delivery shifts the cost to salaried time and training, while outsourced work is priced from the written scope.
How long does a PostgreSQL monitoring integration take to complete?
Duration depends on estate size, the number of instances that need collectors, and how quickly database access approvals, network rules and alert owners are confirmed. A small estate with access already approved moves much faster than one where each database team must sign off on a monitoring role and a firewall change. No general duration applies, so the timeline belongs in the written scope and should match your change calendar. Plan a test window for alert validation. In most projects, approvals and the test window set the pace more than the exporter configuration does. Ask for milestones tied to those dependencies.
What must our team provide before a PostgreSQL monitoring project starts?
Your team must supply:
- Database access approvals for a monitoring role with least-privilege access, typically the built-in pg_monitor role granted to the exporter account.
- Network rules that let Prometheus scrape the exporter and let the exporter reach each database.
- Alert owners who accept each rule and act on it.
- A test window in which alerts can fire without paging on-call staff unexpectedly.
Also provide an inventory of instances, PostgreSQL versions and hosting locations. Confirm early whether your security team requires TLS for scrapes and where exporter credentials are stored. Ask for this list to appear in the scope so that delays are visible from the start.
Can one internal engineer set up PostgreSQL monitoring from the documentation alone?
An engineer with Prometheus and PostgreSQL experience can often build a small setup from public documentation. The exporter installation is usually the easiest part. The harder work includes getting access approved, choosing which lag and connection alerts matter for your workloads, designing dashboards that teams will use, and proving that alerts fire correctly. Documentation covers the stable mechanics, while your environment determines the thresholds and ownership. One engineer also becomes a single point of knowledge. Decide whether the handover includes a runbook, named alert owners and a scheduled rule review before the work starts.
What recurring work follows a PostgreSQL monitoring deployment?
Recurring work includes upgrading postgres_exporter and Prometheus, reviewing alert rules as workloads change, and updating scrape targets and dashboards when instances are added or moved. Prometheus starts a new minor release cycle every six weeks, and a minor release generally stops receiving bug fixes after those six weeks, so plan a regular upgrade cadence. Long-term support lines receive bug fixes for one year. The current LTS line is 3.13, supported until July 31, 2027. PostgreSQL minor releases arrive at least every three months, and major upgrades need the monitoring checked again. Ask whether ongoing support will be a retainer or ad hoc work.
Does using Prometheus for PostgreSQL monitoring require a license fee?
Prometheus is licensed under Apache-2.0, and there is no paid enterprise edition of the project itself, so the project carries no license fee. Costs come from the servers and storage that run Prometheus, any long-term storage or highly available Alertmanager you add, the implementation work, and the staff who run the platform. Confirm the license of each component in your bill of materials, including the exporter and any hosted storage service you choose. Prometheus also values reliability over precision, so it suits operational alerting but is not designed for exact per-request billing.
How do PostgreSQL version support dates affect monitoring work?
Support windows set when your databases must be upgraded, and each upgrade is a point where monitoring should be checked again. PostgreSQL 14 is supported until November 12, 2026, 15 until November 11, 2027, 16 until November 9, 2028, 17 until November 8, 2029, and 18 until November 14, 2030. PostgreSQL releases a new major version about once a year and supports each major version for five years. Major upgrades can use pg_upgrade or logical replication, and logical replication can limit downtime to several seconds. Ask for a monitoring review to be part of every upgrade plan.
How DeployOpen scopes, delivers and supports PostgreSQL monitoring
DeployOpen plans and deploys PostgreSQL monitoring with the community postgres_exporter feeding a Prometheus instance you control. Engagements are fixed-scope, so the metrics, access model, alert rules and dashboards are agreed in writing before any build work starts.
How we scope
- Inventory every PostgreSQL major version in use, noting which are still within the community support window.
- Define the least-privilege monitoring role, including pg_monitor membership, and agree who approves it.
- Agree which collectors are enabled for replication, WAL and statements, and which are excluded.
- Record alert thresholds for replication lag and connection counts with the owners who will act on them.
- Fix retention, storage sizing and the dashboard list in the written scope before the build starts.
How we build
- Deploy postgres_exporter on each database host or chosen network location, using the agreed configuration.
- Create the monitoring role with only the privileges the agreed collectors need, then test them against a non-production database.
- Configure Prometheus scrape jobs and recording or alert rules, then verify each target reports expected series.
- Build dashboards on PromQL queries for connections, replication, WAL and statement activity.
- Test alert rules by simulating lag and connection pressure in a controlled window, and record the results.
How we hand over
- Deliver configuration files, role definitions, scrape settings and alert rules in version-controlled form.
- Document each collector, its privileges, its metrics and the reason it is enabled.
- Provide a runbook that explains each alert, its likely causes and the first response steps.
- Walk your operations team through the dashboards and the alert routing into Alertmanager.
- Hand over access to the exporter and Prometheus endpoints, with TLS and authentication configured as agreed.
How we support
- Ongoing support, upgrades and reviews are available as a retainer, separate from the fixed-scope build.
- Plan exporter and Prometheus version updates against the published release cycle and PostgreSQL support dates.
- Review alert noise and threshold accuracy after go-live and agree changes in writing.
- Confirm with your team which support tier, response expectations and recurring costs apply before the retainer starts.
- Revisit the monitoring scope when PostgreSQL major upgrades or topology changes are planned.
