What does DROP do on a SurrealDB table?
Existing table redefined as DROP
Critical: SurrealDB refuses the migration, loses data, or leaks a credential.
What happens
Observed on SurrealDB 3.0.2: after DEFINE TABLE OVERWRITE event_log DROP, CREATE event_log:2 returns the record as if stored, and SELECT * FROM event_log still lists only the record written before the change.
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
DEFINE TABLE OVERWRITE event_log DROP;The safe pattern
Use DROP only for new tables whose writes exist to fire events or feed table views. To stop storing records in an existing table, stop writing them in code.
DEFINE TABLE page_view DROP;
DEFINE TABLE page_view_daily AS SELECT count() AS views FROM page_view GROUP ALL;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)
DEFINE TABLE OVERWRITE event_log DROP SCHEMALESS PERMISSIONS NONE;DEFINE TABLE OVERWRITE event_log DROP;Stays silent (2)
DEFINE TABLE page_view DROP;DEFINE TABLE OVERWRITE event_log SCHEMALESS PERMISSIONS NONE;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