databaselisted

# Database ## Iron Law `PROTECT PRODUCTION DATA FIRST: PROVE ROLLOUT, LOCKING, AND RECOVERY BEFORE CHANGE.` ## When to Use - Schema design, migrations, indexes, query plans, isolation levels, connection pools, soft delete, N+1 fixes, online DDL, transactional outbox/CDC, or production data changes. ## When NOT to Use - API contract design; use `api`. - Rollout sequencing outside the database; pair with `release`. - Cache freshness and invalidation; use `performance`. ## Core Ideas 1. Schema, migration, and destructive data changes are the user's call. Route schema and migration changes through `contract-first`; data deletion and non-reversible backfills need the same approval for data safety. An approving design or RFC is not that approval; the concrete schema, migration, or destructive change gets its own sign-off before landing. 2. Use the project's existing database unless the task is choosing a store. For greenfield defaults and store-selection caveats, use `architecture`. 3. Expand, migrate, verify, switch, then contract in separate deployable steps. 4. Review SQL and lock behavior, not just ORM code. 5. Backfills are batched, resumable, observable, and reversible. 6. Constraints enforce invariants. Every uniqueness invariant needs a DB-level `UNIQUE`, `EXCLUDE`, composite, or partial equivalent. Application-layer checks race under concurrency. 7. Indexes and plans follow real access paths. New foreign keys and known `WHERE`, `JO