Migration from pganalyze

If you're moving from pganalyze to MonPG, the good news is both tools read the same Postgres data and don't conflict. You can run them in parallel for as long as you want — typically two weeks is enough to convince yourself the dashboards match — and then cut over cleanly.

Why people make the move

The reasons we hear are usually one or more of these. The collector being open source matters to teams that need to audit or modify what runs in their environment. The hosted-fleet option matters to teams who don't want to operate yet another agent. Per-tenant ClickHouse data isolation matters for compliance reviews — pganalyze shares the analytical store across customers; we don't. And the price difference at the same plan tier is real, especially at scale.

None of those individually is a reason to switch a working setup. Together, for some teams, they tip the scale.

Compatible installs

Both tools read pg_stat_statements + pg_stat_*. They each create their own monitor role (pganalyze_collector vs. monpg_monitor) so they don't fight over credentials. The only real interaction point is that both call pgstattuple if it's installed, which is read-heavy. Two parallel callers won't break anything but might add up to noticeable I/O on a busy table; if you're concerned, let us know and we'll pace our pgstattuple sampling lower during the parallel period.

Day one: install MonPG alongside

Sign up for MonPG, onboard your DB through the hosted flow exactly as if pganalyze didn't exist. The MonPG monitor role uses a different name, different password, different connection. pganalyze doesn't notice.

Day two through fourteen: replicate alert rules and dashboards

This is the part that takes time. Go through your pganalyze alerts and recreate them in MonPG. The vocabulary is mostly the same — "cache hit ratio low" maps directly, "vacuum bloat" maps directly, "slow query regression" maps directly. The mapping that catches people is "index unused": pganalyze and MonPG both surface this, but our default thresholds differ slightly (pganalyze flags after 7 days unused, we flag after 30). Adjust to taste.

If you have custom Grafana dashboards built on pganalyze's API, they'll need to be ported to MonPG's API. The endpoint shapes differ but the underlying data is the same — see our API reference.

Validating during parallel

Pick three or four real moments to compare: top queries by total_time over the last 24h, top by mean_time, the regression list, the most recent alert fires. The numbers should be very close. If anything significant differs, raise a support ticket with us and we'll investigate before you cut over. (Sometimes there are real differences — pganalyze normalizes pg_stat_statements queries slightly differently from us, which can cause two rows to merge or split. We can explain why in any specific case.)

Cutting over

Once you're confident MonPG is doing the job, removing pganalyze is mechanical:

Cancel the pganalyze subscription from their app. Drop the pganalyze_collector role from each monitored database, including any GRANT statements that mention it. If you ran their collector as a container or systemd service, stop and remove it. If pganalyze installed any helper functions in your DB (we don't think they do, but check) those go too.

That's it. The only artifact left will be your historical data inside pganalyze, which they retain per their plan terms. Export anything you want to keep before cancellation.