All rules Rule SR013 · DS
SurrealDB · beta
warning
DS · Destructive changes
free in the CLI, --engine=surrealdb

How dangerous is a DELETE without WHERE in a SurrealDB migration?

DELETE of every record in a table

Warning: the statement succeeds, then writes fail, access changes, or the table is held up.

What happens

DELETE with a table name and no WHERE removes every record of the table in one statement: the data is gone, the table's events run once per record, and on a large table the whole delete is one transaction that holds every change until it commits.

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

DELETE session;

The safe pattern

State the predicate, and run large deletes in batches from a job, each committing on its own.

DELETE session WHERE expires_at < time::now();

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)

delete from
DELETE FROM session RETURN NONE;
delete table
DELETE session;

Stays silent (3)

new table
DEFINE TABLE import_staging SCHEMALESS;
DELETE import_staging;
record id
DELETE session:stale_import;
where
DELETE session WHERE expires_at < time::now();

How to check locally

Catch this before it ships

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