New: How Datapace Cut Supabase Dashboard Queries from 61 to 1. Read the case study →
Post-deploy observability

A deploy broke a query. Datapace knows which one, and why.

Datapace watches pg_stat_statements continuously. When a query regresses, it diffs the state before and after each deploy, correlates with commits and ORM call paths, and names the exact change that caused it.

Time to attribute

<1 min

Commit accuracy

to the line

Fix PR

opened automatically

Try it nowGet pricing

The problem

Your monitoring says p99 latency on /api/orders is now 3x what it was yesterday. You had 14 deploys yesterday. Which one broke it?

Without attribution, the on-call engineer has to bisect deploys, read code, and guess which ORM change flipped the plan. Usually they pick the wrong suspect first. The incident drags. The fix takes hours to propose, minutes to deploy.

Queries also drift silently over time. A query that was fine at 100K rows stops being fine at 10M, and no deploy introduced the slowdown. Monitoring shows it. Nobody owns it. Nothing changes.

How Datapace solves this

The fix, automated.

01

Diffs query stats across every deploy

Each deploy is a checkpoint. Datapace snapshots pg_stat_statements, execution plans, and workload stats at deploy time and compares the next hour against the last hour. Any statistically significant regression is flagged with a timestamp and magnitude, not a threshold alert you tuned six months ago and forgot about.

p95 latency · orders_by_userregression detected
deploy
6h ago3h ago1h agonow

before

12ms

after

380ms

detected in

47s

02

Attributes regressions to the exact commit

For every regressed query, Datapace maps the call site in your ORM or SQL file to the Git log and reports the commit, file, line, and author. When a JOIN path changes or a new WHERE clause invalidates an index, you get the diff that caused it, not a hunch. The fix PR is opened automatically and validated against the rest of your workload, so it does not create a new regression elsewhere.

auto-attribution · 14:08 UTCattributed in 47s

regressed query

SELECT * FROM orders

WHERE user_id = $1 AND active = true

p9912ms380ms+3,066%

attributed commit

a3f9c2dPR #342@sarah

src/orders/list.ts:87

the change

-.where({ user_id })
+.where({ user_id, active: true })

no index covers (user_id, active), plan flipped to Seq Scan

03

Tracks slow drift from data growth

Some regressions are not caused by a deploy. Tables grow. Plans flip. Stats go stale. Datapace tracks per-query baselines over time and flags queries that degrade beyond statistical noise, pointing at the row growth or plan change responsible. When the right fix is an index, a partition, or a rewrite, a PR is opened automatically and workload-verified before it lands in your inbox.

baseline drift · events_by_orgdrift detected
baseline ±1σexited baseline
6 mo ago3 mo ago1 mo agonow

correlated with

events table

3.2M → 18M rows

p95

12ms → 47ms

→ partial index on active orgs proposed in PR #289

Who this is for

Teams with high deploy velocity and limited DBA capacity
On-call engineers tired of bisecting deploys at 2 AM
Any production Postgres workload where query performance matters
Teams whose data has outgrown the indexes they shipped at launch

Example workflow

See it in action.

Stop regressions before they ship.

2-minute setup. Read-only Postgres connection. Results delivered in your repo and Slack.

Try it nowGet pricing