What Is a Data Lake? Modern Lakehouse Guide

A data lake is a centralized repository that stores raw data in its native format — structured, semi-structured, or unstructured — usually on cheap object storage like S3, ADLS, or GCS. Unlike a warehouse, a lake applies schema on read, letting you store data first and decide how to interpret it later.

Data lakes emerged from the big data era as a cheaper alternative to warehouses for storing raw logs, sensor streams, and semi-structured payloads. This guide walks through what a lake is, the lakehouse evolution, and when a lake makes sense in a modern stack.

The original Hadoop-era data lakes were notoriously messy — dumping grounds where raw files accumulated faster than anyone could catalog or govern them. The term "data swamp" was coined for exactly that failure mode. Modern lakehouse formats and active catalog tooling have addressed most of the old problems, but the lesson remains: a data lake without discipline becomes unusable within a year. Start with a catalog and a table format before the first TB of raw data lands.

Data Lake Defined

People throw around "data lake" to mean wildly different things. Some use it for an S3 bucket with no catalog. Others use it for a fully-managed Databricks workspace with Unity Catalog, Delta Lake, and Photon query acceleration. Both are technically data lakes. The precise definition matters when planning — without a catalog, table format, and query engine, an object storage bucket is just file storage, not a lake.

A data lake is object storage (S3, ADLS, GCS) plus a metadata catalog plus a query engine. The storage is cheap and effectively unlimited. The catalog tracks what files exist and their schemas. The query engine (Trino, Spark, Athena, DuckDB) reads files on demand. Together they give you warehouse-like access to raw data.

Lake vs Warehouse

Warehouses enforce schema on write: every row must match the table definition. Lakes apply schema on read: you dump raw files and interpret them later. Warehouses are faster for SQL analytics; lakes are cheaper for storage and more flexible for unstructured data. The tradeoff used to be stark. Lakehouse formats have erased most of it.

The Lakehouse Evolution

Iceberg, Delta Lake, and Hudi turn object storage into a warehouse-like environment: ACID transactions, time travel, schema evolution, and efficient upserts. A lakehouse combines lake economics with warehouse correctness. Databricks, Snowflake, and BigQuery all support lakehouse tables now, converging on open formats.

• •Iceberg — open table format, vendor-neutral
• •Delta Lake — Databricks-originated, open source
• •Hudi — upsert-optimized, streaming-friendly
• •Unity Catalog — Databricks lakehouse governance
• •Polaris — Snowflake's Iceberg-native catalog

When a Data Lake Makes Sense

Lakes win when storage cost dominates, workloads are heterogeneous, or you need to preserve raw data whose schema evolves. ML training sets, event logs, archival history, and semi-structured payloads all land more cheaply in a lake than in a warehouse. Analysts doing pure SQL should probably still query a warehouse.

Economic calculations favor lakes above roughly 100 TB of raw retention. Below that threshold, a cloud warehouse is often simpler and barely more expensive. Above it, the storage cost delta dominates operational complexity and the lake almost always wins. Heterogeneous workloads — the same data being queried by SQL, Spark, Python, and ML frameworks — also favor lakes because a single storage tier can serve all four engines without replication.

For related reading see what is a data warehouse, data warehouse vs data lake, and data mesh vs data lake.

Common Pitfalls

The biggest lake failure is the data swamp: raw data dumped with no catalog, no governance, and no owners. Without discipline, lakes become unqueryable archives. Good lakes have catalog coverage, lineage, ownership, and active quality monitoring — the same discipline as warehouses, just adapted.

Operating a Modern Lake

Modern lake ops require a table format (Iceberg or Delta), a catalog (Unity, Polaris, Glue), and active metadata management. Data Workers catalog agents work across both warehouse and lake, unifying metadata so analysts find the right table regardless of storage tier.

Book a demo to see unified warehouse + lake governance.

Real-World Examples

A large gaming company dumps 10 billion daily client events into S3 as Parquet, catalogs them with AWS Glue, and queries with Athena for ad-hoc and Spark for batch. Storage costs roughly $8k per month; the same volume in a cloud warehouse would cost many times that. A fintech keeps raw transaction logs in ADLS under Iceberg format, uses Trino for interactive queries, and replicates curated tables to Snowflake for BI tools. A research team stores unstructured images and video on GCS, indexes them with a vector database, and uses Spark to extract ML features into Delta Lake tables.

When You Need a Data Lake

You need a lake if you have any of three problems. First, you store massive volumes of raw data and warehouse economics do not work at that scale. Second, you store unstructured or semi-structured data (logs, images, JSON payloads) that does not fit well in a relational warehouse. Third, you need multiple query engines (Spark for ML, Trino for SQL, Python for data science) reading the same underlying data. Modern lakehouse formats let a single bronze tier serve all three.

Common Misconceptions

A data lake is not just "S3 with some files." Without a catalog, table format, and query engine, an S3 bucket is a file dump, not a lake. Lakes also are not inherently slower than warehouses anymore — with Iceberg or Delta Lake and a modern query engine like Trino, lakes match warehouse performance on most workloads. And lakes are not replacing warehouses; most serious stacks run both, using each for its strengths.

A data lake is raw files on cheap object storage plus a catalog and query engine. Lakehouses close the gap with warehouses by adding ACID transactions and schema evolution. Pick a lake for cheap raw storage and heterogeneous workloads; pair it with a warehouse for SQL analytics. The line keeps blurring.