# Medallion by Default, Not by Design

**Author:** Akshaya Parthasarathy, Data Engineering & Analytics Consultant, Intelligen
**Date:** 14 October 2026

Say "medallion architecture" in any data engineering conversation today, and three words follow almost automatically: bronze, silver, gold. For many teams it's become less of a deliberate design decision and more of a starting point taken for granted, and starting points are worth examining before they're simply followed.

That instinct toward staged data isn't new. Long before Databricks gave it a sports-themed vocabulary, Bill Inmon and Ralph Kimball were already debating how data should be staged —centralised and normalised versus dimensional and business-friendly. Different philosophies, same underlying principle: raw data moves through stages before it becomes trustworthy enough to use.

Databricks' Medallion architecture gave that principle a clean, memorable shorthand. Microsoft adopted it across its unified data platform, and it has since become the default blueprint across the industry regardless of the engine underneath.

Strip away the branding and the stages are simple:

Bronze: raw, unprocessed source of truth
Silver: cleaned and enriched data
Gold: presentation-ready data intended for business users

That simplicity is part of its appeal, and part of why it's rarely questioned. Three layers make for a clean story and an easy pitch in a design review, so teams tend to build all three regardless of whether their data actually calls for it. Popularity, though, isn't the same as necessity, and not every business needs, or makes full use of, all three stages.

The question isn't whether medallion architecture works. It's whether every layer is actually doing the work it's supposed to.

This is where inherited pipelines tend to give themselves away. Pick up a data estate someone else built, or one stitched together in a hurry to hit a deadline, and it's worth pausing before assuming silver is doing real work. More often than not, it's simply copying bronze through with minimal change, waiting for business rules to actually reshape the data once it reaches gold and reporting.

It is especially true when bronze is already a mirrored copy of a well-defined source, such as a platform like Dataverse, or any other system that hands you clean, structured data on arrival.

It's an easy assumption to overlook. After all, if a pipeline is running and the data is reaching its destination, there may be little reason to question the architecture behind it. But a functioning pipeline isn't necessarily an efficient one.

None of this is free. An unnecessary silver layer still costs storage, still costs compute, and on capacity-metered platforms like Fabric, it still eats into a shared ceiling. All for a step that, functionally, just moves data from one shelf to another and calls it progress.

It's the data equivalent of paying a removalist to carry boxes from your lounge room to your hallway and back again: plenty of effort, nothing actually unpacked.

Beyond the bill, there's a quieter cost, one of responsibility and governance. Every unnecessary hop is one more thing to monitor, one more place lineage has to pass through, one more layer someone new to the project has to learn before they understand where the real logic lives.

And over time, these seemingly small architectural decisions can become a much larger operational burden. What started as an attempt to follow best practice can end up making the platform harder to maintain, troubleshoot and evolve.

Assessing the need for any layer starts with one simple question: can you say, out loud, exactly what happens to the data at this stage?

Not "it gets cleaned" in the abstract, but the actual transformation: deduplicated, conformed to a schema, validated against a business rule, tracked for change over time.

If you can answer that clearly, you're most of the way to knowing whether the layer earns its place. If the honest answer is "it moves", you don't have a silver layer. You have another bronze, with a different name.

And that's where the distinction between following an architecture and designing one becomes important.

Silver earns its place when you're working with multiple sources that genuinely need to be unified into one shape, when history needs to be tracked over time, or when the cleaning and transformation involved is substantial enough to warrant its own stage.

Renaming and reshaping, on the other hand, can usually be achieved through modelling at the gold layer. Many data teams today lean toward a self-serve gold layer, where analysts and business users shape the data to fit their own needs. If that's where the real flexibility lives, ask what silver is contributing on the way there.

The point isn't to remove layers simply to reduce complexity. It's to make sure that the complexity introduced serves a clear purpose. Every additional stage should contribute something meaningful, whether that's improving data quality, supporting governance or making data more useful to the people who rely on it.

None of this is an argument against medallion architecture. It remains a genuinely useful pattern when the conditions call for it. The point is simply to arrive at it by evaluating the actual state of your data, rather than reaching for it as a default because it's what everyone else does.

Good architecture isn't about following a framework perfectly. It's about knowing when the framework makes sense, when it doesn't, and having the judgement to recognise the difference.

The goal isn't to avoid defaults. It's to make sure each one was actually a considered choice, not an assumption carried over from habit.