Try a migration on a fork

An agent about to run a migration, a backfill or a DELETE … WHERE it is unsure of can try it on a copy first.

Ask for it

Before you run the new migration on the dev database, try it on a fork and show me the row counts before and after.

1. briq_fork({ briq: "<the database>" }): a running copy with its own DATABASE_URL.
2. briq_exec on the fork: the migration, then your queries.
3. The agent reports; the original is untouched.
4. It runs the migration on the original, or not, and destroys the fork.

Two approaches at once

Fork the database twice. Try a new column with a backfill on one and a view on the other. Tell me which is faster on the report query.

Two forks, db-fork and db-fork-2, each with its own DATABASE_URL. The agent compares them and destroys the one it does not keep.

Fork the whole app

When the change spans more than the database, fork the stack:

briq_fork({ stack: "shop", into: "shop-v2" })

Every briq gets a copy in shop-v2 under the same name, so the forked API talks to the forked database. Expose the forked API to click through it, then destroy the shop-v2 briqs.

Good to know

• Memory is not copied: the forked database starts on the copied disk as after a power cut.
• A fork keeps the source's credentials; only the host changes.
• Forks count against the agent's policy: with maxConcurrentBriqs: 2, a two-briq stack cannot be forked while it runs.