Preview
We're still working on this feature, but we'd love for you to try it out!
This feature is currently provided as part of a preview pursuant to our pre-release policies.
The NRDOT Collector reports a wide range of PostgreSQL metrics. New Relic collects the metrics in Default metrics automatically. For deeper insight into performance and health, enable any of the metrics listed in Additional metrics.
Tip
Each metric is scoped to a specific database, table, schema, or index. This context is set on the resource, not as a metric attribute.
These metrics are collected automatically and power the New Relic UI, including the out-of-the-box dashboard.
Metric | Description | Unit | Type | Attributes |
|---|---|---|---|---|
| Number of backend connections |
| sum (cumulative, int) | — |
| Number of allocated buffers |
| sum (cumulative, int, monotonic) | — |
| Number of written buffers |
| sum (cumulative, int, monotonic) |
|
| Number of checkpoints performed |
| sum (cumulative, int, monotonic) |
|
| Total time spent on writing and syncing files to disk by checkpoints |
| sum (cumulative, double, monotonic) |
|
| Number of times the background writer stopped a cleaning scan because it had already written too many buffers |
| sum (cumulative, int, monotonic) | — |
| Number of blocks read |
| sum (cumulative, int, monotonic) |
|
| Number of commits |
| sum (cumulative, int, monotonic) | — |
| Maximum number of client connections allowed |
| gauge (int) | — |
| Number of user databases |
| sum (cumulative, int, non-monotonic) | — |
| Database disk usage |
| sum (cumulative, int, non-monotonic) | — |
| Number of index scans on a table |
| sum (cumulative, int, monotonic) | — |
| Size of the index on disk |
| gauge (int) | — |
| Number of database row operations |
| sum (cumulative, int, monotonic) |
|
| Amount of data delayed in replication |
| gauge (int) |
|
| Number of rollbacks |
| sum (cumulative, int, monotonic) | — |
| Number of rows in the database |
| sum (cumulative, int, non-monotonic) |
|
| Number of user tables in a database |
| sum (cumulative, int, non-monotonic) | — |
| Disk space used by a table |
| sum (cumulative, int, non-monotonic) | — |
| Number of times a table was manually vacuumed |
| sum (cumulative, int, monotonic) | — |
| Age of the oldest WAL file. Requires WAL enabled with at least one replica |
| gauge (int) | — |
| Time between flushing recent WAL locally and receiving notification the standby completed an operation. Requires WAL + at least one replica |
| gauge (int) |
|
Additional metrics
The following metrics are disabled by default but can be enabled for deeper insights into PostgreSQL performance and health. These metrics are organized by functionality.
The out-of-the-box PostgreSQL entity dashboard uses the following additional metrics that must be explicitly enabled:
Metric | Description | Unit | Dashboard widget | Extra requirements |
|---|---|---|---|---|
| Number of database locks |
| Database Locks by Mode/Type | — |
| Number of deadlocks |
| Deadlocks | — |
| Calls made to a function |
| Function Calls/min | Requires |
| Queries canceled due to recovery conflicts. Standby-only; zero on primaries |
| Query Conflicts | — |
| Number of sequential scans |
| Sequential Scans/min | — |
| Total data written to temporary files by queries |
| Temp Files & Temp I/O (MB/min) | — |
| Number of temporary files |
| Temp Files & Temp I/O (MB/min) | — |
Additional database activity metrics not used by the dashboard:
Metric | Description | Unit | Attributes |
|---|---|---|---|
| Disk blocks found already in the buffer cache |
| — |
| Disk blocks read in this database |
| — |
| Rows fetched by queries in the database |
| — |
| Rows returned by queries in the database |
| — |
| Rows inserted by queries in the database |
| — |
| Rows updated by queries in the database |
| — |
| Rows deleted by queries in the database |
| — |
| Total execution time of SQL statements tracked by |
| — |
Metric | Description | Unit | Attributes |
|---|---|---|---|
| Precise replacement for |
|
|
Vector similarity search metrics require PostgreSQL 13+ and the pg_stat_statements and pgvector extensions:
Metric | Description | Unit | Attributes |
|---|---|---|---|
| Vector similarity search executions, grouped by distance function |
|
|
| Cumulative execution time of vector searches |
|
|
| Cumulative rows returned by vector searches |
|
|
| Vectors inserted into pgvector tables |
| — |
| Cumulative execution time of pgvector inserts |
| — |
Query events
The following events are disabled by default but can be enabled to collect query-level telemetry data.
Real-time visibility into currently-running database statements — a point-in-time snapshot taken every scrape, not a complete execution log. This event is disabled by default and requires the monitoring user to hold pg_monitor.
Attribute | Description |
|---|---|
| Name of the database. This is always |
| The SQL statement text |
| APM-correlation comment tags. For more information, refer to Link your PostgreSQL database with APM |
| MD5 of normalized SQL for cross-engine correlation |
| User logged into this backend |
| Current overall state of the backend |
| Process ID of this backend |
| UTC (RFC3339) timestamp the backend/connection started. Stable for the connection's lifetime, unlike |
| Whole seconds since backend start. |
| Name of the connected application |
| Client IP address / TCP port |
| Reverse-DNS hostname of the client |
| When the currently active (or last) query started |
| Wait event name / category, if the backend is currently waiting |
| Identifier of this backend's most recent query |
| Query duration in delta milliseconds |
| Array of PIDs blocking this session. Empty when not blocked |
| UTC timestamp when the current lock wait began. Empty when not blocked |
| Whole seconds waited for a lock. |
| Lock mode / resource type / relation name being waited on. Empty when not blocked |
| UTC timestamp when the current transaction started. Empty when no active transaction |
Aggregated per-normalized-query execution stats from pg_stat_statements, reported as incremental (delta) values since the last collection cycle. This event is disabled by default and requires the pg_stat_statements extension in every scanned database.
Attribute | Description |
|---|---|
| Name of the database. This is always |
| The SQL statement text (normalized, |
| Same as |
| MD5 of normalized SQL for cross-engine correlation |
| Times executed / rows retrieved-affected, delta values |
| Shared block activity, delta values |
| Temp block activity, delta values |
| Hash identifying identical normalized queries |
| Role that executed the query |
| Total execution / planning time, delta milliseconds |
| The EXPLAIN plan for the statement, if obtainable — see EXPLAIN mechanics below |
Execution plan collection (EXPLAIN) mechanics
- Rate limiting:
top_query_collection.max_explain_each_interval(default 1000) caps EXPLAINs per scrape. - Caching:
query_plan_cache_size/query_plan_cache_ttl(default 1000 entries / 1h) cache a plan once obtained, keyed by query ID. - PostgreSQL 12+ requirement: parameterized-query EXPLAIN needs
plan_cache_mode = force_generic_planbeforePREPARE/EXPLAIN EXECUTE— only available on PostgreSQL 12+. On older servers the receiver detects the version and skips EXPLAIN for that query rather than sending aSETthat would fail. - Privilege boundary: by default, EXPLAIN runs directly as the monitoring user, and Postgres checks table privileges at plan time — so row-locking or write statements fail with
permission deniedunless granted write access, which the monitoring user should never have. Useexplain_function_name(see EXPLAIN plan permissions) to work around this without granting write access. - If a plan can't be obtained for any reason,
postgresql.query_planis simply empty for that row — no error surfaced.
Related documentation
Instrumentation in self-hosted environments
Learn how to set up PostgreSQL monitoring in self-hosted environments with New Relic.
Instrumentation in RDS environments
Learn how to set up PostgreSQL monitoring in RDS environments with New Relic.
Troubleshooting guide
Learn how to troubleshoot common issues with PostgreSQL monitoring.