# Relational Data & SQL

**Track:** The Full-Stack Substrate — AI-Native Full-Stack Development — complete (30)
**Framework / surface:** web dev (PostgreSQL / SQL)
**Level:** Intermediate
**Prerequisites:** HTTP, JSON, APIs & Streaming

**In one line:** Persistent application state becomes tables, relationships, and queries rather than an opaque backend service.

## Theory, aesthetics & inspiration

E. F. Codd's "A Relational Model of Data for Large Shared Data Banks" (1970) proposed the abstraction this tutorial rests on: store durable facts as rows in tables, relate them through keys, and query them declaratively — say what data you want, not how to walk the storage. SQL, which grew from IBM's System R project in the mid-1970s, remains that declarative language half a century later, and PostgreSQL — descended from Michael Stonebraker's Postgres project at Berkeley (1986) — is the reference implementation here. The essential vocabulary is small: table, row, column, primary and foreign key, SELECT/INSERT/UPDATE/DELETE, filter, aggregate, and above all JOIN, the conceptual leap that reveals relationships as queryable structure rather than a pile of spreadsheets. Agents and ORMs will write most queries; verification still requires reading them — predicting which rows a query touches is part of checking an agent's work, and agentic systems only raise the stakes, since tool runs, approvals, and memories all need durable representation somewhere.

**Builder question:** What are the durable nouns in your application, and which relationships between them must the database enforce?