# Ship or recover safely

Prompt · Workflows · DBR05

A schema change or a restore you have actually tested.

## Prompt

```text
Ship or recover safely A schema change or a restore you have actually tested.
Work through this in order and check in with me after each step. Stay read-only until I approve a change.

1. Start: PG17 for a change about to ship; PG15 for rebuilding or recovery.

Are our database changes safe before we merge? (PG17)
Review this database change against the live schema, existing consumers, prior migrations and deployment process. Establish whether it preserves current records, supports old and new application versions during rollout, and can be verified on an isolated database. Identify the smallest necessary migration and a realistic recovery path before approving it.

Can we rebuild this database from its sources? (PG15)
Determine whether this database can be reconstructed from the repository, migrations, original source material and retained operational records. Identify anything that exists only in production, any transformations that cannot be reproduced, and data that would be permanently lost. Where possible, test the reconstruction on an isolated database and compare the resulting records and relationships.

2. If needed: G02 for deploy timing; R06 for half-finished failures; PG04 when past results must not move.

Database changes during a deploy (G02)
Trace what happens during the deployment window when a new database migration or API schema change goes live while previous client bundles, active background workers, or queue consumers are still running. Identify column renames, non-nullable additions, or contract changes that break backwards compatibility before the old code finishes draining.

Half-finished failures (R06)
Trace error, timeout and cancellation paths for transactions, locks, file handles, temporary files, worker jobs and network connections. Identify paths that leave resources held or state half-committed, and demonstrate them with controlled failure injection where practical.

Reproduce what the database believed in the past (PG04)
Choose important historical records and determine whether the system can reproduce what was known and reported at a specific past date, using the definitions and evidence available then. Distinguish later source corrections from later classification changes. Find where current logic silently rewrites historical meaning and recommend the smallest reliable solution.

3. Change: Run migrations and restores on a separate database, check compatibility, and plan the recovery.

4. Done when: A migration or restore tested on a separate database, and no claim about production that wasn't proved.
```

## Related

- [Reproduce what the database believed in the past](https://www.atlasscope.dev/prompts/reproduce-what-the-database-believed-in-the-past): Past reports, backfills, restatements or changed classification rules matter.
- [Can we rebuild this database from its sources?](https://www.atlasscope.dev/prompts/can-we-rebuild-this-database-from-its-sources): You worry about disaster recovery, production-only state, or whether the data could be rebuilt.
- [Are our database changes safe before we merge?](https://www.atlasscope.dev/prompts/are-our-database-changes-safe-before-we-merge): A migration, or a change to functions, views, RLS, types or column meaning, is about to ship.
- [Database changes during a deploy](https://www.atlasscope.dev/prompts/database-changes-during-a-deploy): Checks that each database change works with the old code that is still live while a release finishes.
- [Half-finished failures](https://www.atlasscope.dev/prompts/half-finished-failures): Finds what is left behind when something fails halfway.

Source: https://www.atlasscope.dev/prompts/ship-or-recover-safely