Scry captures your real query workload, replays it against your proposed change on a pinned copy of production data, and tells you exactly which queries got faster, slower, or stayed the same — with a reproducible proof attached. Schema migrations, version upgrades, index and type changes, query optimizations.
Other tools guess from metrics and hallucinate. Scry runs your real workload on a pinned shadow and proves the result — a regression caught, or an optimization confirmed.
Each result pins the data snapshot, frozen stats, workload window, and Postgres version — re-run the exact experiment and get the same verdict. Verdicts rest on logical I/O and plan shape, frequency-weighted across your workload; wall-clock is reported with confidence intervals, never as the sole story.
Scry sits transparently between your application and database. It estimates the impact of a change in sub-seconds, then replays your real workload against it on a shadow — so you see exactly how your change performs under real load before you ship.
Planner what-if analysis estimates each query's change in cost in sub-second time. Cheap triage ranks candidates and kills the obvious losers before any workload runs.
Then Scry replays your actual captured workload — real timing, real concurrency, real data shapes — against the change on a pinned shadow. No synthetic scripts to write.
Scry captures every production query transparently, with bind parameters and timing
Planner what-if estimates the per-query impact and triages candidates in sub-seconds
Execute the real captured workload against the shadow running your proposed change
Emit a reproducible receipt: which queries regressed, improved, or stayed stable
If a change can alter how your queries perform, Scry can prove its impact against your real workload first — the same predict-then-replay loop, whatever the change.
The proof engine is the foundation. On top of it, Scry is growing into an agent that finds the change, proves it, and brings you the receipt.
You bring a schema change, upgrade, or optimization. Scry predicts, replays your real workload, and hands back a reproducible proof of the impact.
Scry watches your workload and schema continuously, proposes the change itself — a missing index, a better type, a partition — and opens a PR with the proof already attached. Autonomy is a dial you control: recommend-only, auto-open-PR, or auto-apply within your guardrails.
After a change merges and ships, Scry compares production reality to its prediction — "predicted −38%, delivered −35%" — and calibrates. Trust is earned, not assumed.
Scry was born from real-world pain. After executing 100+ production database migrations at enterprise scale, we knew there had to be a better way to change a database than hoping staging caught everything. So we built the proof engine we wished we had.
Hands-on experience changing critical production databases at scale
Every failure mode we've seen is built into Scry's design
Background in high-throughput systems serving critical workloads
We believe changing a database shouldn't be high-stakes gambling. Scry brings empirical, reproducible proof to every database change — and is growing into an agent that proposes those changes and proves them for you. We built the tool we wished we had; now we're sharing it.
Oracle Real Application Testing validated this category with two tools: SQL Performance Analyzer (predict the per-statement impact of a change) and Database Replay (replay real production workload with true timing and concurrency). Scry brings that same predict-then-replay capability to PostgreSQL and the open stack. It captures live traffic continuously through a wire-protocol proxy — no synthetic scripts to write — keeps a shadow current with CDC so you test against real data shapes and volume, and attaches a reproducible proof to every verdict. No Oracle license, no lock-in.
Shadow database testing means applying your proposed change to a copy of your database that's receiving real production traffic — before you deploy. Scry proxies queries between your application and PostgreSQL, captures every query, and replays it against the shadow running your change. If a query that ran in 3ms now takes 200ms, you know before your users do — and you get a reproducible proof of the result.
pt-upgrade is a Percona Toolkit utility that replays MySQL slow-log files against two instances to validate version upgrades. Scry validates the full range of database changes — schema migrations, version upgrades, index and type changes, query optimizations — against real production workloads. The key differences: Scry captures live traffic continuously via a wire-protocol proxy rather than replaying static log files, uses CDC replication to keep the shadow current with production data, and proves each verdict with a reproducible receipt grounded in logical I/O and plan shape.
Less than 1ms per query at p50, benchmarked on commodity hardware against PgBouncer as the baseline. At 100 concurrent connections, scry-proxy adds roughly 1% latency. Event publishing to the replay pipeline is fully async and best-effort — if the buffer fills, oldest events are dropped rather than slowing down queries. Observability never sits in the query path.
Join platform engineers, database architects, and SREs who prove their database changes against real production workloads before they ship.
