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`. ## Rules 1. Destructive and hard-to-reverse database changes are the user's call. Schema and migration changes that other code or stored data binds to route through `contract-first`, which owns the approval scope. Data deletion and non-reversible backfills always need explicit approval, because a rollback cannot undo them. An additive, easily reversed change on a development-stage schema proceeds with its shape stated in the close-out. 2. Use the project's existing database unless the task is choosing a store; `architecture` owns store selection. 3. Destructive or tightening changes ship as separate deployable expand-contract phases: expand, migrate, verify, switch, contract. 4. Review the migration SQL and its lock behavior directly, not just the ORM code. Index and constraint creation uses the target engine's online mechanism. SQLite passing is not proof of Postgres behavior; verify engine-specific DDL against the target engine. 5. Every uniqueness invariant is enforced