Migrations, locks, credentials, and what changes when an agent writes the SQL. Follow along with the Atom or RSS feed.
A single idle transaction, one ALTER TABLE queued behind it, and every read on the table queued behind that. Measured, with the pg_locks output, and the lock_timeout setting that turns a 26 second outage into a 2 second retry.
Measured on a 20 million row table: what a plain index build does to writes, what the concurrent build costs instead, the failure mode nobody mentions, and the cases where the plain form is the right call.
A plain ADD CONSTRAINT ... FOREIGN KEY validates every row while holding locks on the child and the parent. The NOT VALID and VALIDATE split that avoids it, the index nobody adds, and why the same trick works for CHECK and NOT NULL.
SQLite supports a fraction of ALTER TABLE and fails the rest at run time, in every environment. What it does and does not allow, why DROP COLUMN rewrites the file, and the documented rebuild procedure that replaces the missing statements.
We asked a coding agent for forty ordinary Postgres migrations and ran the free rule set over the result. Twenty-seven were flagged. The pattern in what it got right and wrong is more interesting than the count.
The four ways a credential gets into a migration file, what happens to it after the commit, and why the fix is scanning the diff rather than hoping the reviewer notices.
A column drop is safe in the schema and fatal in the running code. The two-release pattern that separates the two, why renames are the same problem in disguise, and what a checker can and cannot know about your deploy window.
The most searched migration error in Postgres, what actually happens inside the server when it runs, what changed in Postgres 11, and the three-step version that works on a table with rows in it.
Letting the model drive is fine. Letting it drive into production without a gate is not. A short, practical split between the parts of a change you can vibe and the parts that need a deterministic check.
Coding agents write database migrations quickly and confidently, and the mistakes they make are the same ones people make. Why the check that catches them has to be a rule, not another model.