Landing zone

What is a landing zone?

A landing zone is the first stop for data coming into a data lake or lakehouse: the place files and records touch down straight from the source, kept exactly as they arrived. Nothing is cleaned, renamed, joined, or reshaped here. A CSV export lands as that CSV, a database extract lands with its original columns and quirks, an API response lands as the JSON it came back as. The one rule of a landing zone is capture everything, change nothing.

That untouched-copy discipline is the whole point. Because the landing zone holds source data as it was at the moment of arrival, it is both a record of what you actually received and a safe restart point. If a cleaning step later turns out to be wrong, you can rebuild from the landing zone without going back to the source system and asking for the data again, which is often slow, rate-limited, or simply no longer possible because the source has changed.

In medallion architecture, the three-layer bronze, silver, and gold pattern common in a lakehouse, the landing zone is the bronze layer, or sits just in front of it. Bronze is the raw tier; silver is where cleaning and conforming happen; gold is the business-ready tables that feed reports. Everything downstream assumes the raw data was captured faithfully first, and that is the landing zone's job.

What lands there, and in what format

Data arrives in a landing zone in whatever shape the source produces, from many sources at once: operational databases, SaaS tools like a CRM, event streams, flat file exports, and third-party feeds. The landing zone does not force them into a common format on the way in. That standardising work belongs to the next layer.

The strong convention is that the landing zone is append-only. New data is added; existing data is never edited in place. Each arrival is usually stamped with when it landed and where it came from, and kept as its own batch rather than overwriting what was there before. That history is what lets you answer questions like what did this table look like last Tuesday, and it is what makes a clean reprocessing possible. A landing zone that gets overwritten on every load is not really a landing zone; it is just a folder.

Raw arrivals are often stored in their original format at first, then converted to an efficient columnar format such as Parquet once inside the lake, so later processing reads them quickly. The raw original is typically kept as well, so the exact bytes you received are never lost.

Landing zone versus staging area

These two get mixed up because both sit early in the flow, but they do different jobs. A landing zone holds raw data at rest, untouched, for as long as you want to keep it. A staging area is a working space where data is held temporarily while it is being cleaned and transformed, then usually cleared out once that work is done.

Put simply: the landing zone is where data is, the staging area is where data is being worked on. Some teams run them as two separate places, raw data landing first and then being copied into staging for processing. Others fold both ideas into a single bronze layer. Either is fine, as long as the untouched raw copy survives somewhere.

A note on the other landing zone

The term is overloaded, and it is worth being clear which one you mean. In cloud platform setups, Azure and AWS both use landing zone to mean something different: the baseline setup of accounts, networking, identity, and security guardrails that new workloads are deployed into. That is an infrastructure and governance concept, not a data storage one. This entry is about the data landing zone, the raw ingestion tier in a data lake. When a colleague says landing zone, a quick check of which meaning they intend saves a confusing conversation.

What to watch out for with a landing zone

Raw does not mean ungoverned. Source data often contains personal or sensitive information in its most complete, unmasked form. The landing zone is frequently the least protected layer and the most exposed one. Set access controls here at least as tightly as anywhere else, and know what is in it.

It grows forever if you let it. Append-only and keep-everything are good defaults, but without retention rules the landing zone becomes an ever-growing bill. Decide how long raw arrivals are worth keeping and archive or delete on a schedule.

A landing zone with no catalogue becomes a swamp. A pile of raw files nobody can describe is worse than useless, because people distrust it and rebuild the same extracts alongside it. Track what landed, from where, and when, so the raw layer stays a resource rather than a dumping ground.

Resist the urge to clean on the way in. The moment you start fixing values during ingestion, the landing zone stops being a faithful copy of the source, and you lose the ability to prove what you actually received. Keep transformation for the next layer.