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

Pre-deploy safety

Your new feature is fast on dev. Will it survive prod load?

Datapace extracts every new query from the PR diff, plans it against live production stats, and projects what it will cost at real data volume. If it is going to be slow in prod, you find out before you ship.

Query patterns caught

40+

p99 projection

live stats

Fix suggestion

index or rewrite

Try it now Get pricing

The problem

A new endpoint ships. It runs in 40 milliseconds on your dev machine. It runs in 4 seconds on prod because your dev has 1,024 rows and prod has 12 million. The difference is a sequential scan instead of an index lookup. Your test suite never catches it, because tests run on tiny seeds.

You are not going to seed prod sized data on every dev machine. You are not going to hand-run EXPLAIN on every new query. What you need is in the middle: a check that reads the query, knows your production shape, and says "this will not be fine".

How Datapace solves this

The fix, automated.

Extracts new queries from the PR diff

Datapace walks the diff, parses SQL literals and ORM calls, and isolates exactly what this PR adds or changes. You do not annotate anything. No decorators, no special comments. Prisma, Drizzle, Kysely, raw pg, and plain SQL files are all handled the same way.

PR #384 · query extraction1 new query

src/api/users.ts

export async function searchUsers(q: string) {

+ return db.users.findMany({

+ where: { email: { contains: q, mode: 'insensitive' } },

+ orderBy: { createdAt: 'desc' },

+ take: 20,

+ })

}

Extracted

users.ts:2newPrisma · findMany

SELECT * FROM users

WHERE lower(email) LIKE $1

ORDER BY created_at DESC LIMIT 20;

Projects cost against live production stats

Each extracted query is planned against your live schema, row counts, and index inventory. Datapace reports whether an index covers it, how many rows the plan will scan, and the projected p99 at current volume. For queries that scale with data, it projects three and six months out based on your actual growth rate.

cost projection31x slower at prod volume

your dev

1,024rows

plan: Index Scan

p99: 40ms

live prod

12.4Mrows

plan: Seq Scan

p99: 1,240ms

projected p99 as data grows

now (1.2s)+3mo (3.8s)+6mo (9s)

Suggests the fix, and verifies it is not counterproductive

If the query needs an index, Datapace proposes the exact CREATE INDEX in the PR comment. If it needs rewriting (N+1, unbounded IN, OFFSET pagination, implicit cast blocking the index), it proposes the rewrite.

Every proposed fix is validated against your broader workload before it is suggested. Datapace replays your recent query log through the new plan space and checks that no other queries regress, no duplicate or overlapping index already covers the pattern, and that write amplification stays within your configured budget. An index that fixes this query but slows down five others never gets proposed.

suggested fix83x faster

migration proposal

CREATE INDEX CONCURRENTLY

idx_users_email_lower

ON users (lower(email));

query plan

Seq Scan on usersIndex Scan using idx_users_email_lower

before1,240ms · 12.4M rows scanned

after15ms · 420 rows scanned

workload check

other queries

0 regressions / 14

index overlap

none

write cost

+0.3ms insert

Who this is for

Product engineering teams shipping user-facing features weekly

Platform teams trying to prevent "it was fast in staging" incidents

Startups whose data is growing fast enough to outrun their indexes

Any team where dev seeds are nowhere near prod size

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 now Get pricing