The Relational Model

The Model

 data as RELATIONS (tables) of TUPLES (rows):

 ┌──────────┬─────────┬──────────┬────────────┐
 │ trip_id  │ rider_id│ city     │ fare_cents │
 ├──────────┼─────────┼──────────┼────────────┤
 │ t-1001   │ u-77    │ london   │ 1450       │
 │ t-1002   │ u-12    │ nyc      │ 2300       │
 └──────────┴─────────┴──────────┴────────────┘

 rules that make it work:
 - each row UNIQUELY identifiable (key)
 - each column TYPED (int, text, timestamp...)
 - no duplicate rows; cell values atomic (1NF baseline)
 - relationships expressed by SHARED VALUES, not pointers

Why It Endured Fifty Years

Property	Consequence
Declarative queries	Ask what, planner finds how
Ad-hoc access	ANY question answerable without redesign
Integrity constraints	Correctness enforced at storage
Mature tooling	ORMs, BI, backups, replication — everything
Schema discipline	Data contracts teams can build on

The killer property is ad-hoc access: relational data answers questions nobody predicted at design time. That flexibility is why analytics, finance, and every back office run on it.

Schemas Are Contracts

 CREATE TABLE trips (
   trip_id     UUID PRIMARY KEY,
   rider_id    UUID NOT NULL REFERENCES riders,
   driver_id   UUID REFERENCES drivers,
   city        TEXT NOT NULL,
   fare_cents  INT CHECK (fare_cents >= 0),
   status      trip_status NOT NULL DEFAULT 'requested',
   created_at  TIMESTAMPTZ NOT NULL DEFAULT now()
 );

 the schema IS documentation + validation + query optimizer input.
 changes are deliberate, versioned, migrated (own lessons).

The Relational Algebra Underneath

 queries compose from a tiny operator set:
   SELECTION   WHERE clauses filter rows
   PROJECTION  chosen columns  
   JOIN        combine relations on matching keys
   AGGREGATION group + compute (SUM/AVG/COUNT)

 everything from dashboards to billing reduces to these five.
 understanding them = reading any query in any SQL dialect.

Where Relational Strains

 honest limits that motivate NoSQL lessons ahead:

 ✗ massive WRITE scale on one node (vertical then shard)
 ✗ rigid schema vs rapidly-evolving nested documents
 ✗ global low-latency distribution (fundamental CAP tension)
 ✗ simple key-value lookups pay join/index overhead

 note what's NOT on this list: "joins are slow" and 
 "SQL doesn't scale" folklore. joins are fine at moderate scale;
 distribution is the real wall.

Interview Framing

Default answer for most product designs remains relational — but justify it: “structured entities with relationships, ad-hoc reporting needs, transactional integrity for payments → Postgres.” Then name your scaling ladder (replicas→cache→shard). Candidates who reflexively pick NoSQL get asked which relational property they’re abandoning and why that’s acceptable — have that answer ready either way.