Designing Data-Intensive Applications
Ch. 2

Relational Model Versus Document Model

The relational and document models represent data differently — and each shines for different access patterns.

At the heart of every database is a data model: the abstraction it exposes to applications. For decades, the relational model dominated. The rise of web applications brought document databases back into focus, each arguing they better fit modern development.

The Object-Relational Mismatch

Object-oriented code thinks in nested structures; relational tables are flat rows. ORMs bridge this gap but introduce impedance mismatch — awkward joins, N+1 queries, and schema migrations that fight your object model.

In practice

Stripe and GitHub run core workloads on PostgreSQL with strict schemas and migrations. Product catalogs and mobile backends often use MongoDB or DynamoDB where documents map cleanly to JSON APIs. Prisma and Drizzle ORMs target PostgreSQL; Mongoose targets MongoDB — the ORM choice often follows the data model.

Airbnb at scale

Listings, guests, and payments live in normalized PostgreSQL tables joined at query time. Canva stores entire design documents — layers, fonts, assets — as nested BSON so the editor loads one record per canvas open.

typescript — Relational joins vs embedded documents
// Airbnb-style booking: relational joins across tables (PostgreSQL + Prisma)
const booking = await prisma.booking.findUnique({
  where: { id: bookingId },
  include: { listing: true, guest: true, payments: true },
});

// Canva-style design doc: nested document (MongoDB)
const design = await db.collection("designs").findOne({
  _id: designId,
  // layers, fonts, assets embedded — one read for the whole canvas
});
When documents win

If your application mostly reads or writes whole records together (user profile + settings + preferences), embedding in a document avoids joins and maps naturally to JSON APIs.

  • Relational: strong for ad-hoc queries, joins, and enforcing referential integrity.
  • Document: strong for hierarchical data, flexible schemas, and horizontal scaling.
  • Graph: strong when relationships are the primary query pattern (covered next).
Key Takeaways
  • Relational databases normalize data into tables with foreign-key relationships.
  • Document databases embed related data together for locality of reference.
  • One-to-many and many-to-many relationships are easier in relational schemas.
  • Schema flexibility favors documents for rapidly evolving product data.
  • Neither model is universally superior — match the model to your query patterns.
  • PostgreSQL handles both relational tables and JSONB columns; MongoDB stores BSON documents natively.
relational modeldocument modelPostgreSQLMongoDBnormalizationimpedance mismatch