SurrealDB

Beta: the SR corpus runs locally behind --engine=surrealdb over .surql migrations: schema changes SurrealDB accepts without checking the records already stored, OVERWRITE resetting permissions, DROP tables, whole-table writes, unclosed transactions, index builds without CONCURRENTLY, and credentials written into SurrealQL.

SurrealDB checks a schema change against new writes, not against the records already stored. DEFINE FIELD with a required TYPE, a new ASSERT, READONLY, a switch to SCHEMAFULL or to TYPE RELATION: each succeeds, and then every old record that does not fit fails its next write, even a write that never touches the field. A plain DEFAULT does not help, it only fills the field on CREATE. REMOVE FIELD leaves the values in every record, and on a SCHEMAFULL table those records can no longer be written at all. DEFINE TABLE OVERWRITE resets the permissions it does not restate to NONE, and a DROP table accepts every write and keeps none of them.

The corpus is in beta: 31 static rules over the official SurrealQL grammar, no live-schema context yet. Every rule ships fixture migrations in both directions, and every "SurrealDB does this" claim is re-proven against a real SurrealDB 3 in the test suite, which also checks that every fixture parses there. The credential rules cover plaintext DEFINE USER passwords, JWT signing keys and literal passwords hashed in SQL, and findings never quote the secret. It runs in the public CLI with --engine=surrealdb (and detects surrealdb-migrations projects), not in the hosted service, the Action or team policy yet, and a clean result means no rule fired, not that the migration is safe.

npx bolvrk check migrations/*.surql --engine=surrealdb

Also in Databases

• PostgreSQL 13–17
• MySQL & MariaDB
  planned
• SQLite
  beta