The freeze was measured two independent ways and they agree.
writes / sec
live traffic — right now · not the run below
migration console
runs against a throwaway twinrun a multi-step migration (a sequence — optional)
Steps run in order on one twin, so a later step sees the schema the earlier ones produced. You get a verdict per step and the worst-of overall. When this is filled it takes precedence over the single statement above; hostile mode doesn't apply to a sequence.
rehearse your own schema (synthetic data — optional)
One CREATE TABLE only. Brace seeds a bounded sample (up to a few million rows) and projects the result onto the size you give. Your migration above runs against this table instead of orders.
Ctrl↵ to run
crash report this run
awaiting runNo run on record.
- write freeze
- —
- writes died on the twin
- —
- verdict
- —
Run a migration below. This card fills in the moment the twin stops moving.
This rig runs one synthetic dataset. Your data never touches it.
This public lab crashes every migration into the same shared, synthetic 10M-row orders table — so there is nowhere to upload your own schema here, on purpose. One lab cannot, and should not, clone a stranger's production database. To rehearse against your indexes, row widths and traffic, run Brace inside your own infrastructure, where the dump never leaves it.
-
01
Import once
One
import.ymlstands up web · api · postgres on your own Zerops project. -
02
Restore your dump as the template
Every throwaway twin is cloned from it. Turn synthetic seeding off with
BRACE_SEED=off. -
03
Describe your write traffic
BRACE_LOAD_LABELSsets the mix, so casualties are measured against your real workload.