The Medallion Architecture (Bronze → Silver → Gold) has become the industry’s default standard for building scalable data estates—especially in Microsoft Fabric. It’s elegant, modular, easy to explain to business users, and aligns well with modern ELT workflows.

The Medallion Architecture remains one of the most effective and scalable patterns for modern data engineering because it introduces structured refinement, clarity, and governance into a data estate. By organising data into Bronze, Silver, and Gold layers, it provides a clean separation of concerns: raw ingestion is preserved for auditability, cleaned and conformed data is standardised for consistency, and curated business-ready data is optimised for analytics. This layered approach reduces complexity, improves data quality, and makes pipelines easier to maintain and troubleshoot. It also supports incremental processing, promotes reusability of transformation logic, and enables teams to onboard new data sources without disrupting downstream consumers. For growing organisations, the Medallion Architecture offers a well-governed, scalable foundation that aligns with both modern ELT practices and enterprise data management principles

But as many companies have discovered, a full 3-layer medallion setup can come with unexpected operational costs:

• Too many transformation layers
• Heavy Delta Lake I/O
• High daily compute usage
• BI refreshes duplicating transformations
• Redundant data copies
• Long nightly pipeline runtimes

The result?
Projects start simple but the estate grows heavy, slow, and expensive.

The good news: A medallion architecture is not the only option. There are several real-world alternatives (and hybrids) that can reduce hosting costs by 40-80% and cut daily processing times dramatically.

This blog explores those alternatives—with in-depth explanation and real examples from real implementations.

---

Why Medallion Architectures Become Expensive

The medallion pattern emerged from Databricks. But in Fabric, some teams adopt it uncritically—even when the source data doesn’t need three layers.

Consider a common case:

A retail company stores 15 ERP tables. Every night they copy all 15 tables into Bronze, clean them into Silver, and join them into 25 Gold tables.

Even though only 3 tables change daily, the pipelines for all 15 run every day because “that’s what the architecture says.”

This is where costs balloon:

• Storage multiplied by 3 layers
• Pipelines running unnecessarily
• Long-running joins across multiple layers
• Business rules repeating in Gold tables

If this sounds familiar… you’re not alone.

---

1. The “Mini-Medallion”: When 2 Layers Are Enough

Not all data requires Bronze → Silver → Gold.

Sometimes two layers give you 90% of the value at 50% of the cost.

The 2-Layer Variant

1. Raw (Bronze):
   Store the original data as-is.
2. Optimised (Silver/Gold combined):
   Clean + apply business rules + structure the data for consumption.

Real Example

A financial services client was running:

• 120 Bronze tables
• 140 Silver tables
• 95 Gold tables

Their ERP was clean. The Silver layer added almost no value—just a few renames and type conversions. We replaced Silver and Gold with one Optimised layer.

Impact:

• Tables reduced from 355 to 220
• Daily pipeline runtime cut from 9.5 hours to 3.2 hours
• Fabric compute costs reduced by ~48%

This is why a 2-layer structure is often enough for modern systems like SAP, Dynamics 365, NetSuite, and Salesforce.

---

2. Direct Lake: The Biggest Cost Saver in Fabric

Direct Lake is one of Fabric’s superpowers.

It allows Power BI to read delta tables directly from the lake, without Import mode and without a Gold star-schema layer.

You bypass:

• Power BI refresh compute
• Gold table transformations
• Storage duplication

Real Example

A manufacturer had 220 Gold tables feeding Power BI dashboards. After migrating 18 of their largest models to Direct Lake:

Results:

• Removed the entire Gold layer for those models
• Saved ±70% on compute
• Dropped Power BI refreshes from 30 minutes to seconds
• End-users saw faster dashboards without imports

If your business intelligence relies heavily on Fabric + Power BI, Direct Lake is one of the biggest levers available.

---

3. ELT-on-Demand: Only Process What Changed

Most pipelines run on a schedule because that’s what engineers are used to. But a large portion of enterprise data does not need daily refresh.

Better alternatives:

• Change Data Feed (CDF)
• Incremental watermarking
• Event-driven processing
• Partition-level processing

Real Example

A logistics company moved from full daily reloads to watermark-based incremental processing.

Before:

• 85 tables refreshed daily
• 900GB/day scanned

After:

• Only 14 tables refreshed
• 70GB/day scanned
• Pipelines dropped from 4 hours to 18 minutes
• Compute cost fell by ~82%

Incremental processing almost always pays for itself in the first week.

---

4. OneBigTable: When a Wide Serving Table Is Cheaper

Sometimes the business only needs one big denormalised table for reporting. Instead of multiple Gold dimension + fact tables, you build a single optimised serving table.

This can feel “anti-architecture,” but it works.

Real Example

A telco was loading:

• 12 fact tables
• 27 dimensions
• Dozens of joins running nightly

Reporting only used a handful of those dimensions.

We built a single OneBigTable designed for Power BI.

Outcome:

• Gold tables reduced by 80%
• Daily compute reduced by 60%
• Power BI performance improved due to fewer joins
• Pipeline failures dropped significantly

Sometimes simple is cheaper and faster.

---

5. Domain-Based Lakehouses (Micro-Lakehouses)

Rather than one giant medallion, split your estate based on business domains:

• Sales Lakehouse
• Product Lakehouse
• HR Lakehouse
• Logistics Lakehouse

Each domain has:

• Its own small Bronze/Silver/Gold
• Pipelines that run only when that domain changes

Real Example

A retail group broke their 400-table estate into 7 domains. The nightly batch that previously ran for 6+ hours now runs:

• Sales domain: 45 minutes
• HR domain: 6 minutes
• Finance domain: 1 hour
• Others run only when data changes

Fabric compute dropped by 37% with no loss of functionality.

---

6. Data Vault 2.0: The Low-Cost Architecture for High-Volume History

If you have:

• Millions of daily transactions
• High historisation requirements
• Many sources merging in a single domain

Data Vault often outperforms Medallion.

Why?

• Hubs/Links/Satellites only update what changed
• Perfect for incremental loads
• Excellent auditability
• Great for multi-source integration

Real Example

A health insurance provider stored billions of claims. Their medallion architecture was running 12–16 hours of pipelines daily.

Switching to Data Vault:

• Stored only changed records
• Reduced pipeline time to 45 minutes
• Achieved 90% cost reduction

If you have high-cardinality or fast-growing data, Data Vault is often the better long-term choice.

---

7. KQL Databases: When Fabric SQL Is Expensive or Overkill

For logs, telemetry, IoT, or operational metrics, Fabric KQL DBs (Kusto) are:

• Faster
• Cheaper
• Purpose-built for time-series
• Zero-worry for scaling

Real Example

A mining client stored sensor data in Bronze/Silver. Delta Lake struggled with millions of small files from IoT devices.

Switching to KQL:

• Pipeline cost dropped ~65%
• Query time dropped from 20 seconds to < 1 second
• Storage compressed more efficiently

Use the right store for the right job.

---

Putting It All Together: A Modern, Cost-Optimised Fabric Architecture

Here’s a highly efficient pattern we now recommend to most clients:

The Hybrid Optimised Model

1. Bronze: Raw Delta, incremental only
2. Silver: Only where cleaning is required
3. Gold: Only for true business logic (not everything)
4. Direct Lake → Power BI (kills most Gold tables)
5. Domain Lakehouses
6. KQL for logs
7. Data Vault for complex historisation

This is a far more pragmatic and cost-sensitive approach that meets the needs of modern analytics teams without following architecture dogma.

---

Final Thoughts

A Medallion Architecture is a great starting point—but not always the best endpoint.

As data volumes grow and budgets tighten, organisations need architectures that scale economically. The real-world examples above show how companies are modernising their estates with:

• Fewer layers
• Incremental processing
• Domain-based designs
• Direct Lake adoption
• The right storage engines for the right data

If you’re building or maintaining a Microsoft Fabric environment, it’s worth stepping back and challenging old assumptions.

Sometimes the best architecture is the one that costs less, runs faster, and your team can actually maintain.

---