Should a SurrealDB migration run REBUILD INDEX?
REBUILD INDEX without CONCURRENTLY
Warning: the statement succeeds, then writes fail, access changes, or the table is held up.
What happens
Observed on SurrealDB 3.0.2: REBUILD INDEX ... CONCURRENTLY is refused with "Database index is currently building" while a concurrent build of the same index is still running.
Why it is dangerous on a populated table
SurrealDB checks a schema change against new writes, not the records already stored, so an empty table hides it: on a populated one every old record is a write waiting to fail, and whole-table work runs for the length of the table in one transaction.
Fires on
REBUILD INDEX purchase_customer ON TABLE purchase;The safe pattern
Add CONCURRENTLY, or run the rebuild from an operational job outside the deploy.
REBUILD INDEX purchase_customer ON TABLE purchase CONCURRENTLY;Fixtures
The rule ships with these files and the test suite runs them on every change: the first set must fire, the second must stay silent.
Fires (2)
REBUILD INDEX IF EXISTS purchase_customer ON purchase;REBUILD INDEX purchase_customer ON TABLE purchase;Stays silent (1)
REBUILD INDEX purchase_customer ON TABLE purchase CONCURRENTLY;How to check locally
SurrealDB support is in beta: this rule runs locally in the free CLI over .surql migrations, static only, and not in the hosted service yet. No install, nothing leaves your machine:
npx bolvrk check migration.surql --engine=surrealdb