Database Migration Testing Platform

Ship database changes without migration-day anxiety. Test schema changes, version upgrades, and query optimizations against real production workloads before deployment.

The Challenge

Major database changes carry significant risk. Schema migrations, version upgrades, and query optimizations can break production in unexpected ways. Traditional staging environments lack production scale, traffic patterns, and edge cases that only emerge under real load.

  • No visibility into query behavior at scale
  • Performance regressions discovered too late
  • Breaking changes slip through testing
  • Circuit breaker trips on migration day

The ScryData Solution

Built in Rust with Tokio, ScryData eliminates migration-day anxiety by validating database changes against real production workloads. Catch breaking changes in hours, not after deployment.

  • Reduce risk with production workload validation
  • Save time by testing in hours instead of weeks
  • Prevent costly outages with automatic circuit breaking
  • Deploy confidently with ~100μs production overhead
  • Integrates with GitHub Actions via a single scry ci command

See ScryData in Action

ScryData sits transparently between your application and database, capturing production traffic and replaying it against your shadow database—with full instrumentation to see exactly how your changes perform.

ScryData architecture: query capture, shadow replay, and comparison pipeline
Fully Instrumented Shadow Testing

Replay production queries against your shadow database with complete telemetry—see exactly how your changes perform under real load

Optional Query Transforms

Adapt incoming queries to match new schemas or query patterns—test breaking changes without breaking production

Side-by-Side Comparison

Compare latencies, catch errors, and spot result mismatches between production and shadow databases

The Shadow Database Workflow

1
Capture

ScryData captures every production query transparently

2
Transform

Optionally rewrite queries to match your new schema or data patterns

3
Replay

Execute queries against your shadow database with your proposed changes

4
Analyze

Full instrumentation reveals performance impact, errors, and regressions

Built for Production

~100μs
Proxy overhead
Zero-copy
Query parsing
PostgreSQL
Protocol support

Proof It Works

Real regression caught before production. No pages. No incident channel.

The Regression

92x

query slowdown from a missing index

Before Fix

184ms

sequential scan on 25,000 rows

After Fix

3ms

index scan, regression eliminated

A teammate added a region column to the orders table — backfilled, CI green, PR approved. Staging never caught it. ScryData replayed production traffic against the shadow database and flagged the regression before the PR merged. Three-line fix. Zero customer impact.

Read the full post-mortem →

Built by Database Migration Veterans

ScryData 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 validate database changes without the anxiety.

100+
Production Migrations

Hands-on experience migrating critical production databases at scale

Hard-Won
Lessons Learned

Every failure mode we've seen is built into ScryData's design

Enterprise
Scale Experience

Background in high-throughput systems serving critical workloads

Our Mission

We believe database migrations shouldn't be high-stakes gambling. ScryData brings production-scale validation to every team, eliminating the anxiety and risk of migration day. We built the tool we wished we had—now we're sharing it with you.

Frequently Asked Questions

What is shadow database testing?

Shadow database testing means applying your proposed schema change to a copy of your database that's receiving real production traffic — before you deploy. ScryData proxies queries between your application and PostgreSQL, captures every query, and replays it against the shadow. If a query that ran in 3ms now takes 200ms after your migration, you know before your users do.

How does ScryData compare to pt-upgrade?

pt-upgrade is a Percona Toolkit utility that replays MySQL slow-log files against two instances to validate version upgrades. ScryData is built primarily for schema migrations — validating that your index additions, column changes, or table restructures don't regress query performance before you deploy. It also works for upgrade testing (new database version, same schema). The key technical differences: ScryData captures live traffic continuously via a wire-protocol proxy rather than replaying static log files, and uses CDC replication to keep the shadow database current with production data, so you're always testing against real data distribution and volume.

What is the production overhead?

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 shadow 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.

More questions →

Early Access Program

Join platform engineers, database architects, and SREs derisking major database changes with production-scale validation.

Your information is used solely for ScryData early access notifications.