Migration rehearsal
Every lock or rewrite finding on a connected check says how long it would block traffic on your actual table: the published benchmark scaled by the live row count, printed in the PR. Hosted, Team and above.
A finding says an index build takes a SHARE lock. A rehearsal says what that costs you: "on public.orders (12M rows) this blocks writes about 3.9 s as written, under 0.1 s as CREATE INDEX CONCURRENTLY". The line sits under the finding in the pull request comment, on the check run and in the run log, so the reviewer sees the price and the fix in one place.
Nothing runs against your database. The benchmark behind the rule pages measured every lock and rewrite rule’s dangerous and safe form on a 20M-row table under write and read traffic; an index build, a scan or a rewrite is linear in rows, so the measured wait scales by the row count in the schema snapshot your connection already provides. It is an estimate and it says so.
What gets no estimate
A form the server refuses outright, a wait that comes from an idle transaction rather than table size, a table the connection cannot see or has never analysed, and any rule whose measured wait is under a tenth of a second. Silence is better than a made-up number.
The CLI is open source and needs no account: npx bolvrk check migration.sql