Introduction

The medallion architecture: bronze, silver, and gold data layers, started as a lakehouse design pattern from Databricks and has since become popular across modern data platforms.

In this post, we’ll explain what medallion layers mean in practice, why teams attempt to use them, the challenges that often arise, and our recommendation at Weld: keep the model flexible, intuitive, and aligned with your team’s real needs.

What is the medallion architecture?

At its core, the medallion framework organizes data into three stages (bronze, silver, gold). The term was popularized by Databricks, where it originated as a best practice for managing large-scale data lakes. The idea is simple: define layers of increasing quality and usability.

Medallion architecture
  • Bronze (Raw): Data ingested directly from source systems, with minimal transformation.
  • Silver (Refined): Cleaned, structured, and enriched data that’s ready for broader analysis.
  • Gold (Business-ready): Aggregated, curated data models optimized for reporting, dashboards, and decision-making.

This layered approach creates a shared language inside the data team. Instead of arguing over what’s “ready,” everyone understands what state the data is in and what it can be used for.

Why do teams apply medallion layers?

So why are data teams increasingly adopting the medallion architecture model? The appeal lies in bringing structure and clarity to rapidly evolving data environments. By organizing data into layered stages teams create a clear, repeatable framework for managing data transformation and access.

The benefits usually look like this:

  • Clarity: Distinguishes raw data from analysis-ready data
  • Role alignment: Engineers focus on bronze/silver; analysts work with gold
  • Separation of concerns: Minimizes risk by isolating raw data from transformations
  • Scalability: Provides repeatable patterns as data volume grows

For many teams, this is a useful abstraction that brings order to the complexity of a modern data stack. But as always, the theory doesn’t always match practice.

Common challenges of the medallion architecture

While the bronze-silver-gold framework provides a clean conceptual model for organizing data transformations, real-world implementation often presents several challenges:

  • Access Control and Permissions: Managing data access across multiple layers can become complex. If roles, privileges, or access patterns aren't carefully designed, downstream layers (e.g., gold referencing silver) may encounter failures or unauthorized access.
  • Environmental Sprawl: Attempting to mirror development environments (e.g., DEV, QA, STG, PROD) across all layers can lead to a proliferation of environments and datasets, creating unnecessary overhead and confusion in naming, deployment, and maintenance.
  • Multi-Tenancy and Data Isolation: In scenarios involving multiple clients or business units (e.g., schema-per-client or database-per-client), layering the architecture adds redundancy. Variations in client data structures can make it difficult to maintain uniform pipelines and governance.
  • Cost and Storage Overhead: Persisting every dataset at every layer, especially bronze data, can lead to significant storage and cost concerns. In some cases, direct ingestion into curated (silver) layers might be more practical.
  • Inconsistent Layer Definitions: Teams often interpret the purpose of each layer differently. Without clear, shared definitions of what constitutes "bronze," "silver," or "gold," inconsistencies can emerge in how data is modeled and transformed across teams or projects.
  • Tooling and Platform Limitations: While the medallion model is conceptually platform-agnostic, not all data platforms support it equally. Limitations in cross-database queries, metadata management, or orchestration can hinder smooth implementation.

Best practices for medallion layers

The good news is that medallion architecture can work well, if you adapt it to your team’s needs and platform constraints. Based on what we’ve seen with data teams, a few practices make the difference between success and frustration:

  • Choose Logical vs. Physical Layering Thoughtfully: Decide whether to separate layers using schemas, folders, or entirely separate environments. Logical separation (e.g., using schemas or prefixes) often simplifies maintenance, but physical separation may be necessary for security or compliance.
  • Standardize Naming Conventions: Whether you use "bronze/silver/gold" or "raw/staging/core," consistency in naming across projects and teams is crucial. Clear naming helps with discoverability, governance, and onboarding.
  • Define Access Controls Early: Establish roles and permissions as part of your architecture design. Clear access boundaries between layers help prevent accidental exposure of raw or sensitive data and reduce broken dependencies.
  • Avoid Unnecessary Duplication: Don't blindly persist every dataset in every layer. Be intentional about what data moves through the pipeline and where it should land. In some cases, skipping the bronze layer (e.g., direct ingestion into silver) might make sense.
  • Use the Framework as a Guideline, Not a Rulebook: Medallion architecture is a helpful mental model, but it shouldn’t be applied dogmatically. Adapt it to fit your data sources, team workflows, and operational constraints.
  • Document Layer Purposes Clearly: Ensure that everyone understands what each layer is meant to represent. This prevents misalignment and encourages consistent implementation.

In other words: keep the framework simple and aligned with your actual use cases.

Weld’s perspective

At Weld, we see teams get bogged down by architectural theory. The real win comes when data becomes accessible, trusted, and usable, without unnecessary engineering complexity.

Our goal is to support users with simple, reliable pipelines driven by clarity and real business needs, not rigid architectural models.

Conclusion

Medallion architecture can be highly effective, but only when applied with intention. Start simple. Be deliberate about access control, naming standards, and documentation. Most importantly, adapt the model to fit your team’s needs and workflows, rather than forcing your team to fit the model.

After all, the real goal isn’t perfect layering, it’s delivering reliable, actionable data that fuels better decisions.

Further reading & sources