Medallion architecture is a lakehouse data design that organizes data into bronze, silver, and gold layers as quality improves. Teams use it when data teams need a shared pattern for raw ingestion, cleaned data, curated analytics, and trusted consumption. In plain English, it gives operators a named control for clear data quality stages, ownership boundaries, and reusable analytics products instead of leaving the decision hidden in a portal setting, script, or deployment file. Treat it as production-ready only when the owner, dependencies, permission boundary, monitoring signal, and rollback evidence are clear.
Medallion architecture is a lakehouse data design that organizes data into bronze, silver, and gold layers as quality improves. Teams use it when data teams need a shared pattern for raw ingestion, cleaned data, curated analytics, and trusted consumption. In plain English, it gives operators a named control for clear data quality stages, ownership boundaries, and reusable analytics products instead of leaving the decision hidden in a portal setting, script, or deployment file. Treat it as production-ready only when the owner, dependencies, permission boundary, monitoring signal, and rollback evidence are clear.
Technically, medallion architecture sits in the lakehouse architecture, data quality, and analytics consumption layer. Azure represents it through bronze, silver, and gold tables or folders, pipelines, notebooks, catalogs, lineage, permissions, and quality checks. It usually interacts with Fabric lakehouses, Databricks, Delta tables, Data Lake Storage, pipelines, catalogs, governance tools, and BI reports. The key boundary is that the pattern organizes data maturity, but teams still need permissions, lineage, testing, and clear product ownership. Architects should document scope, identity path, network assumptions, deployment method, monitoring hooks, and fallback behavior before production use.
Why it matters
Medallion architecture matters because it makes clear data quality stages, ownership boundaries, and reusable analytics products visible, testable, and owned. Without that clarity, teams can change the wrong scope, miss hidden dependencies, or troubleshoot symptoms caused by configuration drift rather than application code. It also gives reviewers a common language for security, reliability, operations, cost, and performance decisions. A good implementation states who owns the setting, what workload depends on it, how changes are approved, and which metric or log proves the result. That keeps audits, migrations, incidents, and release reviews from becoming guesswork. Keep the decision visible in runbooks, diagrams, tags, and support notes.
⌁
Where you see it
Signals, screens, and Azure surfaces where this term usually becomes operational.
Signal 01
In the Azure portal, medallion architecture appears in configuration, monitoring, or access views where teams verify ownership, dependencies, permissions, readiness, and rollback evidence before changes.
Signal 02
In CLI, IaC, or query output, medallion architecture appears as properties, status, scope, and dependency evidence that operators compare with the approved design during reviews.
Signal 03
In architecture reviews, medallion architecture appears when teams discuss ownership, access, reliability, cost, performance, and evidence needed to prove the design is safe during reviews.
✦
When this becomes relevant
Specific situations where this term helps solve real Azure design, operations, migration, security, reliability, cost, or governance problems.
Use Medallion architecture to make ownership, configuration evidence, monitoring, and rollback behavior explicit.
Review Medallion architecture during design reviews, release readiness checks, incident response, and post-change validation.
Document Medallion architecture with related identities, network paths, policies, cost drivers, and operational runbooks.
◆
Real-world case studies
Different enterprise-style examples that show the term being used to hit measurable objectives.
Case study 01
Retail lakehouse quality layers
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
EverGreen Grocers, a grocery retail organization, had raw point-of-sale files, supplier feeds, and loyalty data mixed in one lake folder, making reporting inconsistent. The team used medallion architecture to create a controlled Azure pattern with clear ownership, measurable evidence, and safer production handoff.
🎯Business/Technical Objectives
Reduce report reconciliation defects by 60%.
Separate raw and curated data access.
Create trusted sales tables for BI.
Improve pipeline failure isolation.
✅Solution Using Medallion architecture
Data architects defined bronze tables for raw files, silver tables for cleaned and conformed store data, and gold tables for sales, margin, and inventory analytics. Azure Databricks jobs transformed Delta tables between layers, and ADLS Gen2 permissions separated raw ingestion operators from report consumers. Data quality checks ran at each transition, while Power BI pointed only to gold tables approved by finance and merchandising owners. Runbooks captured owners, approval evidence, monitoring signals, and rollback steps so support teams could repeat the pattern without guessing during incidents. The design also included CLI validation, activity-log review, and architecture notes that connected the Azure configuration to business accountability.
📈Results & Business Impact
Report reconciliation defects fell 72%.
Raw loyalty data was removed from BI access paths.
Gold sales tables became the standard source for daily reporting.
Pipeline triage time dropped from four hours to 90 minutes.
💡Key Takeaway for Glossary Readers
Medallion architecture makes lakehouse data quality visible instead of burying raw and trusted data in the same place.
Case study 02
Energy forecasting data product
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
HelioGrid Energy, a renewable energy analytics organization, needed turbine, weather, and market-price data organized so forecasting models and operations reports did not use conflicting inputs. The team used medallion architecture to create a controlled Azure pattern with clear ownership, measurable evidence, and safer production handoff.
🎯Business/Technical Objectives
Create one trusted forecasting input table.
Reduce model-training data prep by 50%.
Keep raw telemetry immutable.
Track quality issues by source system.
✅Solution Using Medallion architecture
The team stored unmodified telemetry and market feeds in bronze, created silver tables with cleaned time zones and validated units, and published gold features for forecasting models. Data Factory orchestrated ingestion, Databricks handled transformations, and Unity Catalog governed access by layer. Operations dashboards used gold aggregates, while data scientists could request controlled access to silver tables for feature investigation. Runbooks captured owners, approval evidence, monitoring signals, and rollback steps so support teams could repeat the pattern without guessing during incidents. The design also included CLI validation, activity-log review, and architecture notes that connected the Azure configuration to business accountability.
📈Results & Business Impact
Model-training prep time fell 58%.
Raw telemetry remained unchanged for audit.
Forecast accuracy improved 7.5%.
Data-quality defects were traced to source systems within one day.
💡Key Takeaway for Glossary Readers
Medallion architecture helps analytics teams align operational reporting and machine learning around the same governed data progression.
Case study 03
Water analytics layer separation
Scenario, objectives, solution, measured impact, and takeaway.
📌Scenario
Mariner Public Works, a municipal government organization, wanted transparent water-usage analytics but had citizen records, meter reads, and billing data at different quality levels. The team used medallion architecture to create a controlled Azure pattern with clear ownership, measurable evidence, and safer production handoff.
🎯Business/Technical Objectives
Protect citizen-identifiable raw data.
Publish reliable district-level usage metrics.
Reduce manual cleansing by 40%.
Support open-data reporting without exposing PII.
✅Solution Using Medallion architecture
Architects used bronze for raw meter and billing files, silver for standardized readings with validation status, and gold for district-level usage aggregates. Sensitive fields were masked before data entered gold tables. Pipelines tagged records with source and quality state, and operators reviewed storage paths and Databricks jobs during each monthly release. Public dashboards consumed only approved gold tables. Runbooks captured owners, approval evidence, monitoring signals, and rollback steps so support teams could repeat the pattern without guessing during incidents. The design also included CLI validation, activity-log review, and architecture notes that connected the Azure configuration to business accountability.
📈Results & Business Impact
Open-data reports shipped with no citizen identifiers.
Manual cleansing work dropped 46%.
District usage metrics matched billing totals within 1.2%.
Privacy review approved the layer-based access model.
💡Key Takeaway for Glossary Readers
Medallion architecture gives public-sector teams a simple way to explain where raw data ends and trusted public reporting begins.
Why use Azure CLI for this?
Azure CLI is useful for medallion architecture because it turns the live configuration into repeatable evidence. Operators can inventory scope, compare settings with IaC, confirm identity and network assumptions, and export facts for change reviews or incidents without relying on screenshots.
CLI use cases
Inventory Medallion architecture settings across subscriptions or resource groups before reviews, migrations, and ownership cleanup.
Inspect live Medallion architecture configuration before a release, audit, incident, rollback, or support handoff.
Export Medallion architecture evidence so teams can compare portal state, IaC intent, activity logs, and monitoring results.
Before you run CLI
Confirm tenant, subscription, resource group, scope, and service-specific permissions before inspecting or changing Medallion architecture.
Know whether the command is read-only or changes production behavior, cost, routing, identity, or network exposure.
Choose JSON, table, or TSV output deliberately so the result can be reviewed, scripted, or attached to evidence.
What output tells you
The output shows whether medallion architecture exists, where it is scoped, and which resource or workload currently owns it.
Status, identity, network, SKU, policy, metric, or dependency fields reveal whether live configuration matches the intended design.
Repeated output over time can prove drift, confirm remediation, or show that a change reached the correct Azure resource.
Mapped Azure CLI commands
Medallion architecture Azure CLI checks
az databricks workspace show --resource-group <group> --name <workspace>
az databricks workspacediscoverAnalytics
az storage fs directory list --account-name <storage> --file-system <filesystem> --path bronze
az storage fs directorydiscoverAnalytics
az storage fs directory list --account-name <storage> --file-system <filesystem> --path silver
az storage fs directorydiscoverAnalytics
az storage fs directory list --account-name <storage> --file-system <filesystem> --path gold
az storage fs directorydiscoverAnalytics
Architecture context
Technically, medallion architecture sits in the lakehouse architecture, data quality, and analytics consumption layer. Azure represents it through bronze, silver, and gold tables or folders, pipelines, notebooks, catalogs, lineage, permissions, and quality checks. It usually interacts with Fabric lakehouses, Databricks, Delta tables, Data Lake Storage, pipelines, catalogs, governance tools, and BI reports. The key boundary is that the pattern organizes data maturity, but teams still need permissions, lineage, testing, and clear product ownership. Architects should document scope, identity path, network assumptions, deployment method, monitoring hooks, and fallback behavior before production use.
Security
Security for Medallion architecture starts with least privilege and clear ownership. The main risk is copying sensitive data through layers without preserving classification, masking, access controls, and lineage evidence. Review who can create, update, delete, assign, invoke, or read it, and whether access comes from direct roles, inherited roles, managed identities, secrets, or deployment pipelines. Prefer managed identity, scoped RBAC, private access, encryption, and logged approvals when the service supports them. For production, keep evidence of permission scope, network exposure, diagnostic logging, and rollback authority so a security review can verify live state rather than trusting documentation alone. Keep the decision visible in runbooks, diagrams, tags, and support notes.
Cost
Cost for Medallion architecture is driven by storage across layers, transformation compute, optimization jobs, retention, data movement, and duplicated datasets. The spend may be direct, such as SKU, capacity, storage, throughput, replicas, retention, or network transfer, or indirect through support time and failed changes. FinOps reviews should identify the owner, billing tag, usage metric, and cheaper configuration that still meets the workload requirement. Do not reduce cost by weakening security, durability, compliance, or recovery needs without written approval. Track changes over time so teams can distinguish intentional scaling from forgotten resources, stale test deployments, and inefficient defaults. Keep the decision visible in runbooks, diagrams, tags, and support notes.
Reliability
Reliability for medallion architecture depends on pipeline health, table freshness, data quality rules, lineage, rollback capability, and layer-specific SLAs. Operators should know what happens during deployment, scale changes, failover, maintenance, dependency loss, and operator error. Some effects are direct, such as availability, recovery, throughput, or dead-letter behavior; others are indirect because the setting makes drift easier to detect and reverse. Document region assumptions, backups, health probes, retry behavior, dependency limits, and rollback steps. A reliable implementation lets support teams prove current state quickly before making emergency changes. Keep the decision visible in runbooks, diagrams, tags, and support notes. Review the evidence again after deployment so drift is caught early.
Performance
Performance for medallion architecture depends on pipeline duration, table layout, file size, query latency, optimization, cache behavior, and curated table reads. The effect may appear as latency, throughput, IOPS, connection wait time, replica behavior, query duration, pipeline runtime, or faster operational troubleshooting. Measure before and after important changes instead of assuming the setting helps. Useful evidence includes metrics, logs, traces, activity records, deployment output, load-test results, and user-impact signals. When performance is indirect, state that clearly and focus on how the term improves diagnosis speed, configuration consistency, or workload routing. Keep the decision visible in runbooks, diagrams, tags, and support notes.
Operations
Operationally, medallion architecture needs a repeatable inspection path. Teams should know which portal blade, CLI command, Resource Graph query, metric, activity log, workbook, or deployment artifact shows the live state. Runbooks should describe normal ownership, approved change windows, escalation contacts, rollback steps, and evidence to capture after changes. Avoid undocumented portal-only edits in production. Use IaC, tags, CLI exports, and monitoring so operators can compare actual configuration with the intended design during releases, incidents, and audits. Keep the decision visible in runbooks, diagrams, tags, and support notes. Review the evidence again after deployment so drift is caught early. Tie every change to an owner, monitoring signal, and rollback path.
Common mistakes
Changing medallion architecture without checking dependent resources, owner tags, alerts, permissions, and rollback steps first.
Assuming the portal label is complete instead of validating live state through CLI, IaC, metrics, or activity logs.
Granting broad permissions for convenience, then forgetting to remove temporary access after troubleshooting or deployment.