# Try a migration on a fork

URL: https://briq.cloud/docs/guides/try-a-migration-on-a-fork

> Let an agent run a risky change on a copy of the database, then keep it or throw it away.

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:

```text
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.