Year five of a Rails project: four migration directories, a User class with thirty custom methods overriding the ORM defaults, a quarterly meeting about whether to upgrade Rails 4 to 7 or migrate off entirely. The schema is fine. The thing built around it isn't.
A schema with three ways to spell `created_at` (`createdAt`, `created_date`, `date_created`), four PK strategies (BIGINT here, UUID there, two flavors of composite key in the analytics tables), and a deleted_at column on 80% of tables: the 20% that don't have it are the ones whose queries silently return soft-deleted rows. Nobody broke a rule. There was no rule to break.
A counter-cache trigger fires on every comment insert and serializes every concurrent write on the parent post's row lock. A CHECK constraint and an application validator drift apart over five years until a migration tightening the constraint fails on 4,000 legacy rows. Where each rule belongs comes down to scope, cadence, cost, and how many things write to the schema.
An on-call engineer reads `LATEST DETECTED DEADLOCK` and sees `lock_mode S locks rec but not gap` on the unique index. That's a duplicate-key conflict on insert, not the lock-ordering bug everyone assumed. Tuning the retry limit would have hidden it for another quarter. Reading the log first is what separates fixes from cosmetics.
Two correct transactions, locally fine in isolation, kill each other. The cycle forms in the global ordering across concurrent sessions, which no single query can see. The query in the error log isn't wrong; the lock it was waiting for isn't held by a misbehaving process. The bug is the interaction.
An aggregation that ran in 50ms yesterday takes 50 minutes today. No schema change, no query change. EXPLAIN ANALYZE shows a nested loop where there used to be a hash join. The planner's row estimate drifted 100x from reality between yesterday's ANALYZE and today's data. The fix is statistics, not the query.
A column called `status TINYINT NOT NULL` in a table you've never seen. Is `1` active? Pending? Enabled? Is `0` deleted or just inactive? The column type doesn't tell you. Neither does the column name. The fix is one line of DDL nobody writes.
An `INSERT INTO order_items (order_id) VALUES (9999)` against an order_id that doesn't exist. With a foreign key the database rejects the row. Without one, the row lands and the corruption surfaces months later when finance can't reconcile a report or backups have already rotated past the window.