Skip to content

CONCEPT Cited by 1 source

Separate vs. monolithic data models

The fundamental structural choice when a data warehouse must support multiple product lines or business domains.

Definition

Separate data models create distinct table sets for each product line — keeping data clean and tailored to each domain's unique attributes, at the cost of duplicated logic across models.

Monolithic data models combine all product lines into a single unified table set — maximizing code reusability and consistency, at the risk of becoming unwieldy and poorly suited to domain-specific attributes.

Neither approach is universally superior. The optimal choice depends on the specific business domain, particularly the degree to which product lines share common data attributes (Source: sources/2026-06-09-airbnb-scaling-beyond-one-data-architecture).

Decision criteria

Airbnb identified these considerations for teams choosing between the two approaches:

  • Shared vs. unique product attributes — high overlap favours monolithic; many unique attributes favour separate
  • Future evolution — will the model scale to 4th, 5th product lines?
  • Upstream alignment — how does the production database structure its data?
  • Downstream consumers — how will analysts query this data?
  • Code maintainability — which path leads to cleaner, more modular code?
  • Data volume & performance — can the model handle scale efficiently?
  • Compatibility — how to ensure changes for new products don't break existing reporting?

When to use each

Signal Choose separate Choose monolithic
Product attributes Highly unique per product Mostly shared across products
Cross-product queries Rare Common / essential
Product interaction Independent journeys Conversations/transactions span products
New concepts Fundamentally new structures (e.g. offerings, business hours) Existing abstractions apply (e.g. payments, threads)

Seen in

Last updated · 542 distilled / 1,571 read