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

Is it safe to REMOVE DATABASE in a SurrealDB migration?

REMOVE DATABASE or REMOVE NAMESPACE

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

What happens

REMOVE DATABASE deletes every table and record in the database, REMOVE NAMESPACE every database in the namespace. A migration runs against whatever the connection points at, so the statement that cleans up a test database is the one that empties production.

Why it is dangerous on a populated table

Table size does not change this one: every record in the database or namespace goes, and the only way back is a restore.

Fires on

REMOVE DATABASE app;

The safe pattern

Keep database and namespace lifecycle out of migrations: create and remove them from provisioning, where the target is explicit.

-- provisioning, not a migration:
--   REMOVE DATABASE app_preview_1234;

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 database
REMOVE DATABASE app;
remove namespace
REMOVE NAMESPACE IF EXISTS acme;

Stays silent (2)

define database
DEFINE DATABASE IF NOT EXISTS app;
remove param
REMOVE PARAM $feature_flag;

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