# Data Modeling, Migrations & Transactions

**Track:** The Full-Stack Substrate — AI-Native Full-Stack Development — complete (30)
**Framework / surface:** web dev (PostgreSQL / schema evolution)
**Level:** Intermediate
**Prerequisites:** Relational Data & SQL, Git as Memory & Reversibility

**In one line:** Design the shape of persistent state, evolve it deliberately, and make related writes succeed or fail together.

## Theory, aesthetics & inspiration

A schema is an executable model of what the application believes exists: columns encode attributes, constraints encode rules, relationships encode structure — product design at the most durable layer. Schemas evolve, and a migration is to data what a commit is to source: a versioned, reviewable transformation with history. The asymmetry deserves respect — reverting code is cheap, but a destructive migration can lose data no rollback recovers, so agent-drafted migrations are precisely where human inspection concentrates. Transactions handle the other integrity problem: Jim Gray formalized the transaction concept around 1981, and Theo Härder and Andreas Reuter named the ACID properties — atomicity, consistency, isolation, durability — in 1983. PostgreSQL wraps related writes between BEGIN and COMMIT so they succeed or fail as one unit: create the order and decrement the inventory together or not at all. Agentic systems intensify the need, because one model decision may fan out into several side effects — and a model's intention is not an atomic, validated state transition until the database makes it one.

**Builder question:** Which operations in your application would leave the system inconsistent if only half of them succeeded?