Medallion architecture on Databricks: what actually matters

Every Databricks pitch deck has the same three-layer diagram: bronze for raw data, silver for cleaned data, gold for business-ready tables. The diagram is fine. The problems start when teams treat it as an architecture instead of what it really is — a naming convention for a set of decisions you still have to make.

Here’s where those decisions actually bite, based on the lakehouse builds we’ve done.

Bronze: append-only or you’ll regret it

The single most common mistake we see is teams “cleaning up” data on the way into bronze — deduplicating, fixing types, dropping malformed rows. It feels tidy. It’s also how you lose the ability to reprocess history when your parsing logic turns out to be wrong.

Bronze should be an append-only, schema-on-read record of exactly what the source system sent you, with ingestion metadata (_ingested_at, _source_file) and nothing else. Storage is cheap. The ability to replay six months of raw events after finding a bug in your silver logic is priceless.

Silver: this is where your real data model lives

Silver is not “bronze but cleaner.” It’s where you commit to a data model: one row per entity, resolved keys, enforced schemas, quarantined bad records. Two rules that have served us well:

1. Every silver table gets expectations. Delta Live Tables’ expect_or_drop (or plain constraint checks in a batch job) with quarantine tables for the failures. A silver table without declared expectations is a bronze table with a misleading name.
2. Silver models the domain, not the report. If a table exists because one dashboard needs it, it belongs in gold. Silver tables should survive a BI-tool migration untouched.

Gold: let it be boring and duplicated

Gold tables can be denormalized, redundant, and aggressively shaped for one consumer. That’s the point. Resist the urge to build one “canonical” gold layer that serves every team — you’ll end up with a committee-designed table that serves nobody and takes four teams to change.

The parts the diagram doesn’t show

• Unity Catalog from day one. Retrofitting governance onto a running lakehouse is weeks of migration work; starting with it is an afternoon of setup.
• Cost visibility before cost optimization. Tag jobs by pipeline and team first. Most “Databricks is expensive” complaints turn out to be one forgotten streaming cluster or an oversized all-purpose cluster someone uses for ad-hoc SQL.
• A reprocessing story. Decide before launch how you’ll rebuild silver from bronze — full replays, partition-scoped replays, or versioned logic. If the answer is “we’d figure it out,” you don’t have a lakehouse, you have a pile of Parquet.

None of this is exotic. That’s the real lesson: medallion architectures fail on discipline, not on technology. Get the boring parts right and the diagram takes care of itself.