Medallion Architecture — the bronze → silver → gold layering pattern — is the default template for lakehouse data organization, but it is a convention, not a requirement. The real alternatives are: Kappa Architecture (streaming-first, one pipeline), Data Vault 2.0 (hub-link-satellite modeling for auditability), data mesh (domain-owned data products instead of central layers), single-layer ELT (land raw, transform directly to marts — the dbt-style approach), and Lambda Architecture (parallel batch and speed layers). Each exists because medallion's assumptions — batch-oriented refinement, centralized ownership, three distinct hops — don't hold everywhere.
We work with medallion designs every week and recommend the pattern often. This is not a takedown — it's the guide we wish more teams read before adopting three layers by default: what each alternative optimizes for, what it costs, and the specific conditions under which it beats bronze-silver-gold.
Why Look Beyond Medallion Architecture?
Teams typically go looking for alternatives when one of these frictions appears:
- Latency — three sequential hops add minutes-to-hours; some products need seconds.
- Cost — every layer stores and reprocesses the data again; for large volumes, that's real storage and compute money.
- Ceremony without payoff — small teams with a handful of well-understood sources end up maintaining bronze and silver tables nobody queries.
- Audit requirements medallion doesn't natively answer — "what did we know, and when did we know it" across changing source systems is a modeling problem, not a layering problem.
- Organizational scale — one central team owning all three layers becomes the bottleneck for every domain's changes.
Each alternative below targets one of those frictions specifically.
1. Kappa Architecture — Streaming-First, One Pipeline
Kappa Architecture treats everything as a stream. There is a single processing path: events land in a durable log (Kafka, Kinesis, Pulsar), stream processors (Flink, Spark Structured Streaming) compute views, and "reprocessing" means replaying the log through new code rather than maintaining a separate batch layer.
When it beats medallion: genuinely event-driven domains — clickstream, IoT telemetry, fraud detection, operational monitoring — where data is born as events and freshness is the product. One codebase instead of parallel batch and streaming logic is a major maintenance win.
The cost: streaming engineering skills are scarcer, backfills-by-replay require the log to be retained and replayable, and truly relational workloads (large joins, slowly-changing dimensions) fight the paradigm. Note that Kappa and medallion are not mutually exclusive — a common hybrid streams into bronze and silver continuously and materializes gold on a schedule.
2. Data Vault 2.0 — Model for Audit and Change
Data Vault 2.0 is a modeling methodology, not a layering scheme: business keys live in hubs, relationships in links, and descriptive attributes in satellites, all insert-only with load timestamps and source tracking. It answers "what did the business know, from which system, at what time" by construction.
When it beats medallion: heavily regulated environments (banking, insurance, pharma) with many source systems that change frequently, where lineage and auditability are compliance requirements rather than nice-to-haves, and where source-system churn would otherwise force constant silver-layer rework.
The cost: steep modeling discipline, table counts that grow quickly, and queries that need a presentation layer on top (vault tables are not analyst-friendly). In practice many enterprises run vault-inside-medallion: raw vault as the silver layer, star-schema marts as gold.
3. Data Mesh — Change Who Owns the Data, Not How It's Layered
Data mesh is an organizational architecture: instead of one central platform team refining all data through shared layers, each business domain owns and publishes its data as a product, on self-serve platform infrastructure, under federated governance standards.
When it beats medallion: large organizations where the central data team has become the queue everyone waits in. If domain teams already have engineering capability, mesh removes the bottleneck that no amount of layer optimization can fix. Note the layers don't disappear — each domain may still use bronze-silver-gold internally — but the centralized medallion pipeline does.
The cost: mesh is an operating-model change that requires real platform investment and governance maturity. Adopted by renaming the existing team structure, it produces distributed silos with extra steps. Small organizations almost never need it.
4. Single-Layer ELT — Land Raw, Transform to Marts
The quiet default across much of the industry: land raw data (one raw zone), then use SQL-based transformation (dbt or similar) to build analyst-facing marts directly, with staging as views or ephemeral models rather than materialized intermediate layers. Effectively two zones instead of three materialized tiers.
When it beats medallion: small-to-mid data teams, mostly-relational sources, batch analytics as the dominant workload. Fewer materialized hops mean less storage, less orchestration, and faster iteration — version-controlled SQL provides the lineage. For many companies this delivers most of medallion's value at a fraction of its ceremony.
The cost: it strains at high data volumes (rebuilding marts from raw gets expensive), with unstructured data, and with ML feature pipelines that want a curated intermediate layer. Growth path: teams that outgrow it usually evolve into medallion by materializing what were staging views into a governed silver layer.
5. Lambda Architecture — Parallel Batch and Speed Layers
Lambda Architecture runs a batch layer for completeness and a parallel speed layer for low-latency views, merging results at query time. It solves the same latency problem as Kappa but keeps batch as the source of truth. We compare it to medallion in depth in Medallion vs Lambda Architecture — the honest summary is that maintaining two codebases for the same logic is a heavy tax, and most greenfield designs now choose either Kappa or a streaming-enabled medallion instead. It remains relevant where batch and real-time results genuinely must be computed differently.
Comparison: Which Pattern Optimizes for What
| Pattern | Optimizes for | Main cost | Best fit |
|---|---|---|---|
| Medallion | Progressive quality, clear contracts | Storage + compute per layer, added latency | Mixed workloads on a lakehouse; sensible default |
| Kappa | Freshness, single codebase | Streaming complexity, replay-based backfills | Event-native domains, real-time products |
| Data Vault 2.0 | Auditability, source-system change | Modeling discipline, table sprawl | Regulated, many-source enterprises |
| Data mesh | Organizational scale, domain ownership | Operating-model change, platform investment | Large orgs bottlenecked on a central team |
| Single-layer ELT | Simplicity, iteration speed, cost | Strains at volume and with ML workloads | Small/mid teams, relational batch analytics |
| Lambda | Real-time + batch completeness | Two codebases for the same logic | Legacy real-time systems; rarely greenfield |
How to Choose: A Short Decision Guide
- Is your data born as events, and is freshness the product? Start from Kappa or a streaming-enabled medallion hybrid.
- Is provable auditability across changing sources a compliance requirement? Data Vault for the core model — often inside a medallion layout.
- Is your bottleneck the central team, not the pipeline? That's an ownership problem; consider mesh principles before re-architecting layers.
- Small team, relational sources, batch analytics? Single-layer ELT will likely serve you for years; add layers when specific pain demands them.
- Mixed batch/streaming/ML on a lakehouse, multiple consumer teams? Medallion earns its keep — its contracts between layers are exactly what multi-team platforms need.
The pattern matters less than the fit. The expensive failure mode we see is not choosing the "wrong" architecture — it's adopting a pattern built for someone else's constraints and paying its costs without having its problems.
Frequently Asked Questions
Is Medallion Architecture outdated?
No. It remains the most widely deployed lakehouse organization pattern and the default recommendation for multi-workload platforms. The alternatives exist for specific constraints — latency, audit, organizational scale, simplicity — not because medallion stopped working.
Can I combine these patterns?
Yes, and mature platforms usually do: Data Vault inside medallion's silver layer, streaming ingestion into bronze (a Kappa-medallion hybrid), mesh-style domain ownership where each domain runs its own medallion internally. The patterns answer different questions — modeling, latency, ownership, layering — so they compose.
Do I always need all three medallion layers?
No. Two-layer implementations (raw + curated) are common and legitimate. Skip a layer deliberately when no consumer needs it, and add it back when one does — the layer count should follow consumers, not the diagram.
Choosing With Your Constraints, Not the Template
If you're weighing these patterns for a lakehouse build or rework, our implementation guide covers the build sequence in detail — or book a call and we'll pressure-test your architecture choice against your actual workloads.