Medallion Architecture: When Bronze, Silver, and Gold Make Sense

Databricks defines medallion architecture as a multi-layered approach to a single source of truth. Bronze holds raw, source-fidelity data. Silver is validated, cleaned, and typically the first non-aggregated trustworthy representation. Gold is enriched and often aggregated for analytics, ML, and applications. Databricks calls this a recommended best practice, not a requirement.

When the pattern earns its place

• Multiple sources must be reprocessable from raw.
• Analysts and jobs should not each clean the same feed differently.
• Consumption needs a stable grain and performance-optimized tables.
• You need a clear place for quality tests and quarantine.

When it is being misused

• Three schemas exist, but bronze is already “cleaned” and gold is a copy of silver.
• Every domain duplicates the same conformed dimensions with no owner.
• Streaming and batch each have their own unofficial medallion.
• Nobody can name the consumer of a gold table.

Layer responsibilities, briefly

Bronze: append-only landing, minimal validation, preserve unexpected schema. Silver: schema enforcement, deduplication, late data, joins that create a usable entity. Gold: business-aligned models, aggregations, query optimization. Databricks also notes you may have more than one gold surface (finance vs. operations) because domains differ.

If a dataset is a small static dimension, a full three-hop path may be ceremony. If a feed is the backbone of revenue reporting and ML features, skipping silver is how you debug production with raw JSON.

Name layers after contracts, then keep the bronze/silver/gold vocabulary if it helps the organization. The words are optional. The contracts are not.