Features · Monitoring · PG Slow-Query Monitor
Monitoring · PG Slow-Query Monitor

pg_stat_statements,
finally somewhere you'd look.

The agent reads pg_stat_statements every 5 minutes and ships the top 25 statements by mean execution time. Parameterised, deduped, sortable. The signal you wanted three years ago for tuning queries.

pg_stat_statements · top mean
SELECT … FROM orders mean 3.9s · 1.2k calls
UPDATE inventory SET … mean 890ms · 4.1k
SELECT … JOIN users mean 420ms · 22k
INSERT INTO events … mean 12ms · 1.1M
sampled every 5 minutes
— Why this matters

Postgres already counted this for you.

01

pg_stat_statements is the source of truth.

It has the calls, the total time and the mean. Reading it beats sampling and guessing.

02

Mean matters more than max.

One 8-second outlier is a story. A 400ms query called twenty thousand times is your afternoon.

— What's included

What is collected.

Top 25 by mean time
Shipped every five minutes.
Parameterised query text
With its queryid hash, so the same shape groups together.
Calls, total, mean and max
Sortable by any of them.
Rows and buffer stats
The numbers that separate a slow plan from a big result.
Shared view with MySQL
Same schema, separated by engine, so both databases read the same way.
— How it works

Postgres already counted it.

1

Read pg_stat_statements

The agent polls the view every few minutes. No query rewriting, no proxy, no sampling of your traffic.

2

Keep the shape, drop the values

Statements arrive already parameterised, so the same query with different arguments stays one row.

3

Rank by mean

Sorted by mean time rather than max, because one slow outlier matters less than a query that is always slow.

— Works with

Connected capabilities

— FAQ

Questions, answered honestly.

Do I need to install anything? +
pg_stat_statements is shipped with Postgres but off by default. Enable it with shared_preload_libraries = 'pg_stat_statements' + CREATE EXTENSION pg_stat_statements. Many managed Postgres (RDS, Crunchy, Supabase) enable it for you.
Performance overhead? +
Negligible — single-digit % per query, kept in shared memory. Postgres documents this as production-safe.
How is it different from EXPLAIN? +
EXPLAIN shows the plan for one specific query right now. pg_stat_statements tells you which queries are actually hot in your workload over time. Use both.
Bind values? +
Postgres strips them before this extension sees them. No email = 'sascha@…' ever lands here — just email = $1.

Stop guessing which query is slow.

PG Slow-Query Monitor included from Starter. Same UI for Postgres, MySQL slow-log shares the schema.

Get early access Back to Monitoring