Query planner
The PostgreSQL optimizer is usually right for the data it can see. When it is wrong, the problem is often stale statistics, skewed values, a misleading predicate, or a query shape that hides selectivity.
Estimated rows are far from actual rows
A nested loop runs thousands of inner scans unexpectedly
A plan changes after a deploy with similar SQL
Prepared statements choose a generic plan that fits nobody well
A filter removes most rows after the expensive scan already happened
Bad row estimates explain many bad plans. If actual rows are wildly different, indexes alone may not be the real fix.
EXPLAIN (ANALYZE, BUFFERS, VERBOSE)
SELECT *
FROM orders
WHERE account_id = $1
AND created_at >= now() - interval '30 days';Statistics are the optimizer's map. When the map is stale or too coarse, the route can be expensive.
ANALYZE orders;
SELECT attname, n_distinct, most_common_vals
FROM pg_stats
WHERE tablename = 'orders';MonPG keeps historical query timing so plan regressions are easier to spot after deploys.
Query detail views connect pg_stat_statements, EXPLAIN output, index usage, and buffer behavior.
Alerts can fire when a query family changes shape, not only when the whole database is slow.
Hands-on setup, integration, and troubleshooting guides from the MonPG product docs.
The one-page fleet summary. Active alerts, connection pressure, slowest queries, top size consumers.
Drill into any metric over any time range with full chart controls.
The Queries page is how you find performance outliers. Columns explained + filtering tips.
Diff this hour vs. previous hour, today vs. yesterday — find what regressed.
How Query Advisor parses captured plans and what the bottleneck labels mean.
Proposes indexes for queries that need them, flags indexes that aren't being used.
Find bloated tables, tune autovacuum per-table, and catch XID wraparound before it bites.
Per-table size breakdown, growth trends, and TOAST / index ratios.
Benchmark 48 HNSW configurations against your real pgvector data in 10 minutes. Get the optimal m, ef_construction, and ef_search plus zero-downtime migration SQL.
Paste EXPLAIN ANALYZE output and get an incident-style read of the plan: planner estimate drift, loop explosions, disk spills, buffer pressure, and the evidence SQL to prove the fix.
Model a proposed PostgreSQL index as a production rollout: DDL shape, lock level, WAL pressure, write amplification, replica lag risk, validation SQL, and rollback criteria.
MonPG gives teams query history, alerts, index guidance, vacuum visibility, replication signals, and cloud PostgreSQL monitoring in one place.
Start free