Data Architecture Decision Matrix: Choose the Smallest System That Can Work

Who should read it?

Readers who have followed the series and now have to pick one, plus anyone who inherited a platform decision they did not make.

Intro

There is no universally best architecture, only architectures that fit or fail against a specific set of use cases, constraints, and people. That claim is easy to agree with and hard to act on. At some point a decision has to be made, a budget signed, a platform chosen. We consolidate into the tool for that moment: the comparison matrix. We walk through criterion by criterion, and then apply against your answers and not against marketing.

Be warned

A matrix like this gets misused in one predictable way: someone scans it for the column with the most green, and buys that column. That is the shopping-list reflex the whole series argues against. The matrix works in the opposite direction. You bring the requirements, the matrix tells you which architectures fail them. The output is a shortlist plus a list of things you cannot have at the same time, which is usually the more valuable output.

The 6 columns

6 architectures, in the order the series met them:

• The relational data warehouse (RDWH, 1980s workhorse)
  • relational storage, schema-on-write, one tightly coupled compute engine, built for reporting.
• The data lake (DL, 2010)
  • object storage in raw format, schema-on-read, no built-in compute, cheap and flexible and dangerous.
• The modern data warehouse (MDWH, 2011)
  • the deliberate combination of both, lake for staging and exploration, RDWH for serving, security, and compliance.
• The data fabric (DF, 2016)
  • the MDWH with an advanced layer for access, governance, and discoverability, data access policies, metadata catalog, lineage, MDM, virtualization.
• The data lakehouse (DLH, 2020)
  • the lake only, plus a transactional table layer (Delta Lake, Iceberg, Hudi) that adds warehouse behavior.
• The data mesh (DM, 2019)
  • not a technology at all but a decentralized operating model, each domain owning its data, its compute, and its storage.

Notice what that list already tells you. 5 of the 6 are centralizations, and they differ mostly in how they split storage from compute and serving. The 6th is a different kind of decision entirely. If part 5's readiness test sent you away, your real choice was never 6 options. It was 5.

The matrix

Score the 6 architectures against 12 characteristics, grouped by what they cost you. The values are: qualitative grades that describe typical cases, not laws.

Structural facts

These 2 rows are not judgments, they are identities.

• "Year of introduction"
  • is only about history.
• "Centralized vs. decentralized" matters more
  • data warehouse, data lake, MDWH, data fabric, and data lakehouse are centralized
  • the data mesh is the only decentralized entry, with storage, schema, security, and latency all domain-specific.

Costs and speed

• "Time to value"
  • is low for the data lake, MDWH, data fabric, and data lakehouse, medium for the RDWH
  • is high for the data mesh, which is the price of the organizational shift.
• "Total cost of solution"
  • runs from low (data lake) through medium (MDWH), medium to high (data fabric), low to medium (data lakehouse), to high (RDWH, data mesh).
• "Difficulty of development"
  • follows the same gradient from low (RDWH) to high (data mesh).
• "Company skill set needed"
  • is the row to read before the cost row: low for the RDWH, low to medium for the data lake, medium for the MDWH, medium to high for data fabric and data lakehouse, high for the data mesh.
  • An architecture your team cannot operate is not cheap at any price.

What you get

• "Data security"
  • is high for the RDWH and the data fabric, medium to high for the MDWH, medium for the data lakehouse, low to medium for the raw data lake.
• "Data latency"
  • is low for the RDWH, high for the data lake, low to high for MDWH and data fabric (depending on which layer you query), medium to high for the data lakehouse.
• "Supported use cases"
  • is the row that quietly decides most purchases: low for the pure RDWH, low to medium for the data lake, medium for MDWH, medium to high for the data fabric, high for the data lakehouse and the data mesh.
• "Technology maturity"
  • is high for the RDWH, medium for the data lake, medium to high for MDWH and data fabric, medium to high for the data lakehouse's table formats, and low for the data mesh, which is a concept, not a product line.

Read the last two rows together and you have the series in miniature: the lakehouse scores high on use cases but its maturity row is still moving; the data fabric is broad and secure but medium to high on cost and skills; the data mesh supports the widest range of use cases and costs the most in time, difficulty, skills, and organizational change.

How to actually use it

Part 1 ended with 7 questions: users, decisions, latency, data types, quality, compliance, team capabilities. This is where they connect. The procedure:

1. Score your own seven answers, honestly, including the one about team capabilities most teams lie to themselves about.
2. Strike every architecture that fails a hard constraint. A regulatory latency requirement fails the pure lake. A two-person data team fails the mesh and strains the fabric. A single-copy cost mandate fails the MDW's second copy.
3. On the survivors, weight the criteria by how much each one hurts. There is no objective weighting; a bank and a startup weight the same row differently, and both are right.
4. Choose the smallest surviving system that can work. Not the most future-proof, not the most impressive in a slide, the smallest one that satisfies the hard constraints with margin you can afford.
5. Write down the criteria you sacrificed. You will need them when the architecture creaks in two years, because the creak will come from exactly those rows.

Step 4 deserves its own paragraph. Every architecture in the matrix is someone's answer to a problem that was too big for the previous architecture, and every one of them became a problem when adopted without the problem that justified it. The lake as a dumping ground. The fabric as an org chart purchase. The mesh in a company of 40 people. The lakehouse with millisecond dashboard requirements bolted on afterward, which part 4 showed ends in an RDWH copy anyway, that is, an MDWH you built by detour. Choose smallest, and you keep the option to grow. Choose biggest, and you have pre-spent the growth budget on complexity you did not yet need.

What the matrix cannot decide

3 things sit outside of it.

The first is the platform conversation versus the operating model conversation. The matrix compares 5 platforms and 1 operating model in the same table, which is convenient and slightly dishonest. The mesh column is not a product you shortlist alongside Delta Lake; it is an answer to "who owns the data?" that you can, in principle, combine with any of the storage architectures. Treat the mesh row as a gate: part 5's readiness test decides whether the column even applies to you.

The second is timing. The matrix is a snapshot. The lakehouse's maturity row will keep moving. Those formats have kept hardening. Maturity values age faster than structural facts. Re-read the matrix against the current state of the tools when you actually decide.

The third is people. Every row in this table has a human multiplier. Skills needed is a hiring plan. Difficulty of development is a project-risk profile. Time to value is how long your sponsors stay patient. The matrix can tell you what a choice costs. Only your organization can tell you what it can pay.

The takeaway

One table, 12 rows, 6 columns, and the shortest sentence as its conclusion:

The best architecture is the smallest system that can work, operated by people who understand it.

The matrix does not make the decision for you. It makes the decision honest, which is the most any framework can do.

Series

1. Your Data Architecture Is a Business Decision, Not a Shopping List
2. Data Warehouse, Data Lake, or Both? The Architecture Timeline That Makes It Clear
3. Data Fabric Is Not Magic: What It Adds to a Modern Data Warehouse
4. The Data Lakehouse Promise: One Repository, Fewer Pipelines, New Trade-offs
5. Data Mesh Is an Operating Model, Not a Tool You Can Install
6. Data Architecture Decision Matrix: Choose the Smallest System That Can Work