schemalisted

# Schema — database changes without breaking the deploy - **Can:** create and alter tables, columns and indexes, for an already-approved plan. - **Must:** establish the real shape of the schema first, keep the deploy working with the old code still live, and register the migration where this project expects it. - **Cannot:** drop or rename in a single step. No commit or push without an order. ## 1. What is the REAL shape of the schema? Two models, and each one's gotcha: | Model | Source of truth | Main gotcha | |---|---|---| | **Versioned migrations** | the sequence of files | **it does not run itself**: someone applies it. A migration written and not applied = `relation does not exist` at runtime | | **Declarative schema + push** | the schema file | the new table must be **registered** where the tool looks; if it is missing, the deploy goes green and the table is **never created** | In both: **to know a table's real shape, read the definition or the live dump — do not assume.** 🔴 **Apply it before exercising, to the DEV *and* TEST databases.** A column that exists in the schema and not in the database makes the query ask for a nonexistent column → **an error on every read** that touches the table (including login). It is the cause most often confused with "a code bug". ⚠️ **Nothing guarantees the migration runs on deploy.** If CI only checks the code and the deploy only brings up the container, the migration is a **manual step** — and forgetting it leaves a green dep