We’re excited to launch the ScryData blog! This is where we’ll share our thoughts on database migrations, testing strategies, and the challenges of maintaining reliable data infrastructure at scale.

What to Expect

We’ll be covering topics like:

  • Migration strategies - Best practices for planning and executing database migrations
  • Testing techniques - How to validate schema changes before they hit production
  • Performance insights - Understanding query behavior under real-world conditions
  • Engineering deep-dives - Technical explorations of how ScryData works under the hood

Why We’re Building ScryData

After executing 70+ production PostgreSQL-to-CockroachDB migrations, we learned that the hardest part isn’t the migration itself—it’s the uncertainty. Questions like:

  • Will this schema change break any queries?
  • How will performance change under production load?
  • What edge cases are we missing?

Traditional staging environments can’t answer these questions because they lack production scale and real traffic patterns. That’s why we built ScryData.

A Quick Example

Here’s a taste of what shadow testing looks like with ScryData:

# scrydata.yaml
shadow:
  enabled: true
  database_url: postgres://localhost:5432/shadow_db

transforms:
  - match: "SELECT * FROM users"
    rewrite: "SELECT * FROM users_v2"

Deploy a proxy, and a backfill container to copy and anonymize your data, and take advantage of our checkpointing system to test a specific period in time over and over again with different schemas, or even database versions.

With this configuration, ScryData captures your production queries and replays them against your shadow database—with the schema changes you’re testing.

Stay Tuned

We have a lot more to share. Follow along as we dig into the technical details of production-scale database testing.

Questions? Reach out through our early access program.