Data Lake Architecture: Zones, Catalog, Medallion

By the InfiniSynapse Data Team · Published: 2026-07-15 · Last updated: 2026-09-17 · We design storage layers regularly; this blueprint is the zone, catalog, and medallion rules for data lake architecture—not a vendor poster.

---

Table of Contents

1. TL;DR
2. How We Approach It
3. What It Is
4. The Core Layers
5. The Zone Model
6. Medallion: bronze → silver → gold
7. Catalog and Governance
8. Open table formats
9. Lake vs lakehouse architecture
10. Batch and streaming ingestion
11. Security and identity by zone
12. AWS / Azure / GCP mapping
13. Anti-Patterns to Avoid
14. Designing for Longevity
15. Architecture in the Age of AI
16. Architecture Scorecard
17. Common Misconceptions
18. Frequently Asked Questions
19. Conclusion

---

TL;DR

Direct answer: data lake architecture is the layered design — ingestion, zoned storage, catalog, processing, and serving — that lets a lake store raw data of any type cheaply while staying discoverable and trustworthy. In 2026, good data lake architecture is defined by its zones and catalog more than its storage, because the difference between a useful lake and a data swamp is governance structure, not the underlying object store.

Who this is for: architects and engineers designing data lake architecture in 2026.

What you'll learn: the core layers, the zone model and medallion promotion rules, catalog vs table format, ingestion and security by zone, and how AI is changing data lake architecture.

This guide sits under the warehouse and lakehouse hub.

For the plain definition, see what a data lake is. The one-sentence data lake definition is the starting point for the zones below.

Also see data lakehouse. Grain and star/snowflake for the serving layer live on data warehouse design.

How We Approach It

Governance and risk expectations are framed by UK NCSC AI development guidelines when programs need an external control reference.

We approach data lake architecture as swamp prevention, because a lake without structure decays predictably. Every recommendation reflects lakes we have watched thrive or rot. Primary references are AWS’s building-data-lakes whitepaper and Databricks medallion architecture—not a warehouse SKU or a document store.

The table below maps the layers of data lake architecture.

Practical example: a team's data lake architecture was one flat bucket, and it became a swamp within a year. Adding zones and a catalog — the same discipline Azure’s lake scenario treats as core, not polish — made the same data discoverable and trustworthy again.

Scope note: Mid-market and enterprise patterns for data lake architecture, not legal advice or a vendor runbook.

What It Is

Key Definition: data lake architecture is the layered design of a data lake — ingestion, zoned object storage, a metadata catalog, on-read processing, and serving — so diverse raw data stays cheap, discoverable, and trustworthy. Storage is simple; zones and catalog are the product.

The Core Layers

Teams evaluating this topic often cross-check the Apache Iceberg documentation when storage must become tables without locking one engine.

Sound data lake architecture is organized into layers, each with a clear job. Ingestion brings data in from batch and streaming sources; storage holds it in zones; a catalog describes it; processing applies structure on read; and serving delivers it to analysts and models.

The layering in data lake architecture separates concerns so the lake stays manageable. AWS Lake Formation exists for the same reason: keeping ingestion, storage, and processing distinct means each can scale and change independently, and a problem in one layer does not cascade into the others. This separation is what lets a lake grow to petabytes without becoming impossible to reason about.

The Zone Model

The heart of good data lake architecture is the zone model, which organizes storage by refinement. A raw (or bronze) zone holds data as ingested; a cleaned (silver) zone holds validated, standardized data; and a curated (gold) zone holds business-ready datasets.

Zones give data lake architecture a gradient of trust. Databricks medallion architecture is the named practice: raw zones stay permissive so data lands fast and cheap, while curated zones enforce quality so downstream consumers can trust them. This graduated model captures data quickly without sacrificing trustworthiness, avoiding both the over-controlled lake nobody uses and the ungoverned swamp nobody believes. Data is promoted zone to zone as it earns trust, which keeps the whole lake legible.

Medallion: bronze → silver → gold

Medallion architecture is how data lake architecture enforces the zone model. Bronze is append-only raw. Silver is typed, deduped, and owned. Gold is the business grain with a reviewer. The concept sketch lives on data lake; the 90-day project plan is the operating calendar. This page locks the promotion rules.

If a new column can appear in gold without a ticket, you do not have medallion — you have three folder names.

Catalog and Governance

Implementation details are commonly grounded in Google Cloud’s big-data analytics architecture when teams translate a catalog into a production landing path.

No data lake architecture survives without a catalog: schema-on-read has no self-describing store, so the catalog records what exists, where it lives, what it means, and who owns it. Split a technical inventory (Glue, Unity, Hive) from the business vocabulary (owner, grain, joins). Mixing both in one wiki is how the lake slides back to swamp. Hub context: warehouse and lakehouse.

Open table formats

Object storage is not a table. Iceberg, Delta, and Hudi are how data lake architecture gets transactions, schema evolution, and time travel on cheap files. Use bronze as files if you must; silver and gold should be tables.

You do not need Iceberg to have a lake. You need it when more than one engine must share silver without two copies. Lakehouse product detail stays on data lakehouse.

Lake vs lakehouse architecture

Data lake architecture is zones + catalog + serving on object storage. Lakehouse architecture is that plus a transactional table layer so the same store can answer warehouse-style questions. If you have folders and a wiki, you have a lake. If you have ACID tables, schema enforcement, and time travel on those zones, you have started a lakehouse.

Do not rename the program until the table format is in the gold path. The comparison of store types is data lake vs data warehouse; this page only answers when the lake becomes a lakehouse.

Batch and streaming ingestion

Data lake ingestion architecture is two failure models on one control plane. Batch lands partitions and checksums. CDC and streams land offsets and order. Both write bronze first. Late events and small files stay in bronze until a compaction job promotes them — otherwise silver inherits swamp physics.

A failed batch must not mark a partial prefix complete. A CDC slot that grows without a named owner is an incident, not a pipeline. Shared evidence: owner, last valid checkpoint, affected consumer.

Security and identity by zone

Data lake security architecture follows the zone, not the bucket. Bronze often holds PII as-landed — restrict it. Silver and gold get role-based access aligned to domains. One shared service account across all prefixes is how data lake architecture becomes a compliance incident.

Encrypt at rest, log who read gold, and refuse to treat a raw dump as a mart. Identity and lake permissions belong in the same review as AWS Lake Formation or your cloud equivalent — not a slide that says “the lake is secure.”

AWS / Azure / GCP mapping

The same data lake architecture maps onto three clouds. This is a layout table, not a product bake-off. Azure depth stays on Azure Data Lake.

Pick the cloud you already run. Do not add a second lake to “try Iceberg.”

Anti-Patterns to Avoid

The anti-patterns in data lake architecture are consistent. The flat bucket — one undifferentiated store with no zones — is the fastest route to a swamp. No catalog means nobody can find anything. And landing data with no ownership or quality checks means nothing can be trusted.

A subtler anti-pattern in data lake architecture is treating the lake as a destination rather than a layer. Data that lands in the lake and is never promoted, cataloged, or served delivers no value; it is just cost. We favor designs where every dataset has a path — from raw through curated to a consumer — because a lake is only worthwhile when its data flows onward into analysis, not when it merely accumulates.

Designing for Longevity

Architecture choices are often checked against Apache Spark’s current docs so processing stays a layer, not the lake itself.

Designing data lake architecture for longevity means zones, catalog, and owners before the flood — plus open table formats and storage/compute split so one engine cannot lock the lake. Data lake architecture cost is labor and small files, not the list price of S3: tier or expire cold prefixes, compact bronze, and drop copies nobody queries. A lake that is cheap per GB and expensive per useful query gets rebuilt.

Architecture in the Age of AI

AI intersects data lake architecture in two ways. Machine learning consumes the raw, diverse data a well-architected lake preserves, and AI-native platforms change how much must be consolidated into a lake first.

That second shift is worth weighing, and we describe it in what AI-native data analysis means. In the InfiniSynapse web app, zero-config federation lets an agent analyze across sources — including object storage and files — without first consolidating everything, so data lake architecture increasingly coexists with federation that queries data where it already lives rather than requiring one central lake.

Architecture Scorecard

Assess your lake architecture (1 point each):

6–8: a durable lake. 3–5: add zones and catalog. Below 3: swamp risk — restructure.

Common Misconceptions

Misconception 1: A lake is just storage. The architecture around storage is what makes it usable.

Misconception 2: Zones are optional. Without zones, a lake becomes a swamp.

Misconception 3: A catalog is nice-to-have. With schema on read, the catalog is essential.

Misconception 4: The lake is the destination. Data must flow onward to deliver value.

Frequently Asked Questions

What is data lake architecture?

It is the layered design of a data lake — ingestion, zoned object storage, a metadata catalog, on-read processing, and serving — that together allow diverse raw data to be stored affordably and at scale while remaining discoverable, governed, and trustworthy. The storage itself is simple and cheap; the architecture's real value is in the zones, catalog, and governance layered around it that keep raw data from becoming an unusable swamp.

What are the zones in a data lake?

A raw or bronze zone holds data exactly as ingested; a cleaned or silver zone holds validated, standardized data; and a curated or gold zone holds business-ready datasets. Zones create a gradient of trust: raw zones stay permissive so data lands fast and cheap, while curated zones enforce quality so consumers can rely on them. Data is promoted zone to zone as it earns trust, keeping the whole lake legible.

Why is a catalog essential?

Because a lake stores data with schema on read, there is no enforced structure to make its contents self-describing, so a metadata catalog is what makes the lake searchable — recording what data exists, where it is, what it means, and who owns it. Without a catalog, users cannot find or trust data and the lake slides toward swamp, so the catalog is the backbone of any governable lake rather than an optional extra.

What are the main anti-patterns?

The flat bucket — one undifferentiated store with no zones — is the fastest route to a swamp; having no catalog means nobody can find anything; and landing data with no ownership or quality checks means nothing can be trusted. A subtler anti-pattern is treating the lake as a destination rather than a layer, so data lands but is never promoted, cataloged, or served, delivering no value and only accumulating cost.

How does AI change lake architecture?

Machine learning consumes the raw, diverse data a well-architected lake preserves, so lakes remain relevant, but AI-native platforms change how much must be consolidated first. Federation lets an agent analyze across sources — including object storage and files — without consolidating everything, so modern lake architecture increasingly coexists with federation that queries data where it lives rather than assuming every dataset must flow into one central lake.

How does a lakehouse relate to lake architecture?

A lakehouse builds on lake architecture by adding a transactional table layer and warehouse-like structure on top of cheap object storage, so the same store can serve both flexible raw data and reliable, governed analytics. In practice it formalizes the zone model with open table formats that support transactions, schema enforcement, and time travel, reducing the need to maintain a separate warehouse. It is best seen as an evolution of lake architecture rather than a replacement, keeping the low-cost storage while closing the trust gap.

Is medallion the same as data lake architecture?

No. Medallion is the zone-promotion pattern inside data lake architecture. You can name bronze/silver/gold and still lack a catalog, owners, and a serving path. Medallion without those three is three prefixes on a swamp.

Do I need Iceberg to have a lake?

No. A lake is zones, a catalog, and a path to a consumer on object storage. Iceberg (or Delta, or Hudi) becomes required when silver/gold must be shared tables with transactions. Files in bronze are still a lake.

Conclusion

Data lake architecture is the layered design — ingestion, zones, catalog, processing, serving — that keeps a lake cheap, discoverable, and trustworthy rather than letting it rot into a swamp. Build medallion promotion, a catalog, and open table formats from the start; give every dataset a path to a consumer; and remember federation can query data in place instead of forcing one central lake.

To see how federated analysis works across sources without consolidating a lake, read what AI-native data analysis means and try the InfiniSynapse web app free on registration.