Skip to content
certyn logoCertyn
Start Free
RecipesDoc

Rehearse a Database Migration on a Throwaway Environment

Certyn records counts, totals and key workflows before your migration, checks the same after it, and files an issue for each difference.

For teams who want to try a big migration or database upgrade on a copy first.

Your setup

  • A throwaway environment (for example rehearsal) with a copy of production data, reachable only inside your network.
  • The migration is a command in your repo or a job in your CI.
  • You want proof that no data was lost and the main flows still work.

Say this to Certyn

We will migrate our Postgres database next week. Rehearse it on the rehearsal environment: record row counts, order totals and the checkout flow before, then check the same after the migration.

What Certyn does

  1. Opens the runner form if you have no runner. The form routes only the default environment, so for rehearsal set Environments → Execution target to your runner.
  2. Opens a secret form for DATABASE_URL on the rehearsal environment. A read-only database user is enough.
  3. On its Machine on the runner, installs the client (sudo apt-get install postgresql-client, or default-mysql-client) and agrees the checks with you: row counts per key table, sums such as order totals, a few known records.
  4. Says the run length and starts a "before" run (app.run.create type explore, up to 240 minutes). It saves the results to /workspace/migration/before.json, walks the key workflows in the browser, and puts the numbers in its report.
  5. You run the migration and deploy the new version, from CI or by hand. If you ask, Certyn runs your own command from the repo instead, after you confirm.
  6. Starts an "after" run with the same queries and workflows, and compares.

What you get

  • Before and after numbers in the run reports.
  • One Certyn issue per real difference (a lost row, a changed total, a broken flow), with the query output and screenshots.

Limits

  • Certyn has no database connection of its own: it uses a client in the shell with your secret. The chat's Machine uses the variables of the environment in the header, so open the chat on rehearsal.
  • A shell command stops after 30 minutes. A longer one runs in the background with a log.
  • Certyn asks before destructive or production changes. Still, never point this at production or a shared database.
  • It checks only what you agreed on, not every row. Name the expected changes (a split table, a renamed column), or it reports them.
  • Files in /workspace stay only on a runner started with WORKSPACE_PATH. Without it, the "after" run reads the numbers from the "before" run's report.
PreviousTwo Test Organizations, One Cannot See or Change the Other's RecordsNextStripe Webhooks End to End, Subscription Changes and Duplicate Events