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

Does REMOVE TABLE delete all the records in SurrealDB?

REMOVE TABLE

Critical: SurrealDB refuses the migration, loses data, or leaks a credential.

What happens

Observed on SurrealDB 3.0.2: after REMOVE TABLE audit_log, SELECT * FROM audit_log fails with "The table 'audit_log' does not exist" and INFO FOR DB no longer lists it.

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

REMOVE TABLE audit_log;

The safe pattern

Retire a table in steps: stop writing it, release code that no longer reads it, export the records, and remove it in a later migration. Suppress the finding with that reason once it is true.

-- after the release that stopped reading audit_log, and an export:
-- bolvrk-ignore SR007: archived to cold storage, unused since v42
REMOVE TABLE audit_log;

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)

remove if exists
REMOVE TABLE IF EXISTS audit_log;
remove table
REMOVE TABLE audit_log;

Stays silent (2)

created here
DEFINE TABLE import_staging SCHEMALESS;
INSERT INTO import_staging [{ sku: 'a' }];
REMOVE TABLE import_staging;
remove index
REMOVE INDEX audit_log_at ON TABLE audit_log;

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