All rules Rule SL035 · OP
SQLite · beta
note
OP · Operational safety
free in the CLI, --engine=sqlite

Which SQLite pragmas are connection-scoped and useless in a migration?

Connection-scoped pragma in a migration

Note: this works, but it is a documented trap or a cost the author may not have meant.

What happens

cache_size, synchronous, temp_store, mmap_size and busy_timeout live on the connection that set them. In a migration they tune the runner's connection for a few seconds and reach the application never, and synchronous=OFF removes durability for exactly the connection doing the schema change.

Why it is dangerous on a populated table

SQLite holds one write lock for the whole database, so anything that rebuilds a table blocks every writer for as long as the copy takes, and that time grows with the table.

Fires on

PRAGMA synchronous = OFF;
PRAGMA mmap_size = 268435456;
ALTER TABLE orders ADD COLUMN region TEXT;

The safe pattern

Set connection pragmas where connections are opened, in the application, so every connection gets them. Leave migrations to the schema.

ALTER TABLE orders ADD COLUMN region TEXT;
-- application connection setup: PRAGMA synchronous = NORMAL; PRAGMA mmap_size = 268435456;

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)

cache size
PRAGMA cache_size = 10000;
ALTER TABLE orders ADD COLUMN region TEXT;
synchronous off
PRAGMA synchronous = OFF;
ALTER TABLE orders ADD COLUMN region TEXT;

Stays silent (2)

no pragma
ALTER TABLE orders ADD COLUMN region TEXT;
persistent pragma
PRAGMA journal_mode = WAL;
ALTER TABLE orders ADD COLUMN region TEXT;

How to check locally

Catch this before it ships

SQLite support is in beta: this rule runs locally in the free CLI, static only, and not in the hosted service yet. No install, nothing leaves your machine:

npx bolvrk check migration.sql --engine=sqlite