Migration from New Relic Infrastructure (Postgres integration)

New Relic's Postgres support is part of NR Infrastructure — generic system monitoring with a Postgres plugin attached. It surfaces TPS, connections, replication lag, the basic vital signs. What it doesn't do: query-level analysis, plan capture, index advice, bloat tracking. If your reason for monitoring Postgres is "I want to know if something is wrong," NR Infra answers that. If your reason is "I want to know what is wrong and what to do about it," you'll outgrow it.

MonPG is built around pg_stat_statements + auto_explain + pgstattuple + hypopg. The whole product orients around query-level reasoning and capacity planning, not host-level health checks.

Replacement vs. complement: if NR is just your Postgres tool, replace it. If you have a heavy NR APM investment and want unified dashboards, push MonPG metrics back into NR via the OTLP exporter and keep one pane of glass.

What's the same

Both create a read-only role on your database — NR uses newrelic, we use monpg_monitor_*. They sit side by side without conflict. Run them in parallel for a week or two while you compare.

What you get extra

Top queries by total_time, mean_time, or I/O — instead of NR's aggregate counts. Plan capture from auto_explain with bottleneck-node labeling. Index advisor that uses hypopg to simulate index creation and predict speedup before you build. VACUUM advisor with bloat percentages from pgstattuple. And 37 Postgres-specific health-check rules out of the box (autovacuum off on big tables, orphaned replication slots, missing pg_stat_statements, that kind of thing).

Cutover

Recreate your existing NR alerts as MonPG rules first — the rules guide covers the four kinds. Once parity is confirmed, disable the Postgres integration in newrelic-infra config, drop the newrelic role from PG, and either drop the NR Infra plan if NR was only for DB or just remove the integration if you keep NR for other workloads.