Beyond medallions: A practical, six-layer approach to building a data lakehouse that actually fits your business

The Medallion Architecture for lakehouses (Bronze, Silver, Gold) has done wonders for helping organisations understand and communicate a modern data platform. It’s clean, memorable, and easy.

But while it’s a helpful starting point, it’s not a silver-bullet data strategy. It’s a conceptual model, not a detailed roadmap. And once you begin building a real data lakehouse, cracks start to appear in the model.

Bronze might be “raw,” but do we store data as-is or transform into tables? Silver is “cleaned,” but cleaned by whose definition? Gold is “business-ready,” but to what level? And which metrics do we standardise to include?

The simplicity that makes the Medallion Architecture easy to explain is the same simplicity that makes it hard to manage in practice. As projects progress, teams start debating definitions, quality expectations, and the true purpose of each layer.

Modern organisations simply need more nuance than three metal-themed buckets.

When you design a lakehouse around actual business needs, rather than abstract labels, everything becomes clearer:

• Stakeholders understand where their data is and why.

• Quality improves because expectations are explicit.

• Complexity becomes manageable instead of mysterious.

• Teams stop debating names and start delivering value.

  
  

That’s why the following six-layer breakdown reframes the Medallion Architecture into something far more practical: a set of business-needs–focused layers, each solving a specific organisational problem.

This isn’t about adding bloat or multiplying layers for the sake of it. It’s a more detailed framework you can use to guide conversations beyond “Bronze/Silver/Gold” and explain in crisp, practical terms what’s actually happening inside your data lakehouse.

Depending on your environment, you’re not going to end up with all 6 as distinct layers, you may roll some layers together, rename them, expand them, or ignore/delete them altogether. The point is not the labels — it’s the clarity around purpose, trust, and outcomes.

Layer 1 - Landing

The vital step that lifts data out of storage-optimised systems and into your analytics-optimised lakehouse.

Operational databases are built for transactions - fast writes, concurrency, minimal downtime. Lakehouses are built for something very different: exploration, joins, aggregations, and analysis.

The Landing Layer separates these worlds. It gives you a safe, stable snapshot of source data without placing unnecessary strain on operational systems, and without forcing analysts to directly touch systems-of-record.

Business problems this layer solves

• You need reproducibility and consistent snapshots that don’t interfere with operations.

• You need a clear audit trail of how data entered your lakehouse.

• You need a safe boundary between operational systems and analytics workloads.

  
  

What happens here

• Raw files are ingested exactly as-is (Parquet, JSON, CSV, etc.).

• No cleaning, transformations, or assumptions.

• Every load is timestamped and logged.

• Full source history is preserved for restore and replay scenarios.

  
  

Where it earns its keep

• Minimises operational load through efficient, scheduled extracts.

• Creates a forensic layer for compliance and lineage.

• Makes schema drift manageable instead of disruptive.

• Forms the foundation for rebuilds and disaster recovery.

Layer 2 - Raw

Where your data stops being a pile of files and starts behaving like a dataset.

The Landing Zone data can be messy; dates in arbitrary formats, numbers stored as text, and even corrupted records. The Raw Layer introduces structural sanity without applying any business logic yet.

This layer gives analysts and engineers something predictable to query - not folders full of surprises.

Business problems this layer solves

• You need to remove file-by-file inconsistency.

• You need predictable structures for pipelines and analysts.

• You need to isolate malformed records without losing information.

  
  

What happens here

• Standardised field types (dates behave like dates, numbers behave like numbers etc.).

• Loose files shaped into tables with consistent schemas.

• Bad or ambiguous records flagged but retained.

  
  

Where it earns its keep

• Stops pipelines breaking due to structural issues.

• Removes early friction from analysts exploring unfamiliar sources.

• Makes ingestion scalable and predictable.

• Provides the first stable foundation for downstream transformation.

Layer 3 - Cleansed

Where quality becomes real - and data becomes trustworthy.

Good structure doesn’t automatically mean good data. The Raw Layer still contains duplicates, missing values, contradictory fields, and corrupted logic. As it moves into the Cleansed Layer, trust becomes the priority.

If dashboards show numbers the business doesn’t trust, the entire lakehouse loses credibility. This Layer is where that trust is earned.

Business problems this layer solves

• Stakeholders don’t trust the numbers.

• Analysts rewrite the same cleaning code in every report.

• Data quality is inconsistent across business units.

• Historical tracking is unreliable or missing.

  
  

What happens here

• Deduplication and merging of overlapping records.

• Business-wide data quality rules enforced (e.g., “an order must have a customer”).

• Null-handling, sanity checks, and validation logic.

• Slowly Changing Dimensions applied for proper history.

  
  

Where it earns its keep

• Executives stop asking “why does this number look wrong?”

• Analysts reduce rework and focus on insight.

• Organisation-wide data quality becomes consistent and governed.

• Reliable historical analysis becomes possible.

Layer 4 - Enriched

Where inconsistent systems become one coherent business model.

Every system has its own idea of a "customer", "product", or "location". Without harmonisation, cross-department reporting becomes a nightmare. The Enriched Layer applies shared business definitions, so the entire organisation speaks the same analytical language.

Business problems this layer solves

• Fragmented, conflicting definitions across teams.

• Silos that prevent cross-functional reporting.

• Inconsistent business concepts across source systems.

• Analysts spending hours reconciling definitions manually.

  
  

What happens here

• Conforming disparate systems into shared business entities.

• Standardising attributes across departments.

• Creating canonical domain models.

• Combining multiple cleansed sources into unified datasets.

  
  

Where it earns its keep

• Enables company-wide reporting.

• Reduces complexity in curated BI models.

• Makes analytics scalable and consistent.

• Removes silos and aligns how teams describe the business.

Layer 5 - Metrics

Where your organisation stops reinventing metrics - and starts relying on them.

Few things destroy trust faster than competing KPIs. When different teams calculate metrics differently, alignment becomes impossible.

The Metric Layer centralises, governs, and standardises business metrics so everyone works from the same definitions.

Business problems this layer solves

• Conflicting versions of KPIs across dashboards.

• Endless arguments over definitions of “revenue”, “gross margin”, or “active customer”.

• Duplicate logic scattered across reports.

• Non-transparent metric calculations.

  
  

What happens here

• Clear facts, dimensions, and relationships defined.

• Aggregated, analytics-ready models built.

• Business-wide metric definitions enforced and versioned.

• Metrics made discoverable and reusable.

  
  

Where it earns its keep

• No more “duelling dashboards”.

• Analysts reuse, not reinvent.

• Insights become stable and comparable over time.

• Finance, Sales, Ops, and BI speak the same numeric language.

Layer 6 - Consumption

Where data becomes usable - and your lakehouse turns into business value.

A lakehouse only matters if people can use it. The Consumption Layer delivers your curated, governed data into tools the business already understands - dashboards, semantic models, notebooks, apps, or APIs.

This is the layer where value is realised.

Business problems this layer solves

• Users can’t access trusted data without help.

• Analysts spend more time wrangling data than analysing it.

• Non-technical teams need usable, governed datasets.

• Data literacy and adoption need to grow, not stagnate.

  
  

What happens here

• Publish trusted datasets into BI tools.

• Apply role-based security and access controls.

• Make self-service possible without exposing complexity.

• Expose metrics and models in business-friendly formats.

  
  

Where it earns its keep

• Everyone works from the same source of truth.

• Decision-makers get insights quickly and confidently.

• Analysts focus on analysis, not cleanup.

• Data literacy grows naturally across the organisation.

• The lakehouse becomes a business asset - not just a technical one.

Wrapping up: building a lakehouse that solves actual business problems

The Medallion Architecture is a great starting point - a shared language that makes modern data engineering more approachable. But in practice, it rarely maps cleanly to the real problems organisations need to solve.

Breaking it down into clearer, business-aligned layers gives you:

• Clarity: Every layer has a purpose the business can understand.

• Trust: Data quality and metric definitions are consistently enforced.

• Scalability: New sources and use cases fit naturally into the structure.

• Alignment: Technical design maps directly to business workflows.

  
  

This isn’t about discarding the Medallion concept - it’s about translating it into something more practical, more communicative, and far more useful in real organisations.

When you design your lakehouse around how your business truly works, everything gets easier: governance, communication, adoption, and ultimately, insight.

And if you want help building a lakehouse that is genuinely fit-for-purpose, not just theoretically correct, Data Wranglers specialises in designing modern data platforms that actually make sense to the people who use them.

If you’re planning a new lakehouse, modernising an existing one, or trying to bring order to a lakehouse that’s grown out of control, get in touch.

We’ll help you design something clean, scalable, and completely aligned to the way your organisation works.