Skip to main content
Product & Data

Data Lake

A data lake stores large volumes of raw data — structured, semi-structured and unstructured — in native form on cheap object storage, applying schema when data is read rather than when it is written. It suits exploratory analysis and machine learning, and it demands governance that a warehouse enforces by default.

Schema-on-read is the defining trade. Because structure is imposed at query time, the lake accepts anything — logs, images, JSON events, sensor streams — without deciding its future use in advance. The flexibility is real for exploration and ML training corpora, and so is the deferred cost: every consumer must interpret the data, and nobody validated it on the way in.

The failure mode has a name: the data swamp. Without a catalog, ownership and retention policy, a lake fills with files nobody can find, trust or delete, and cheap storage becomes expensive indecision. The controls are known and must exist from day one — a catalog that makes data discoverable, an owner per dataset, documented schemas where they exist, and lifecycle rules that expire what is no longer needed.

The warehouse/lake boundary has largely dissolved into the lakehouse pattern. Open table formats — Delta Lake, Apache Iceberg — bring ACID transactions, schema enforcement and time travel to data on object storage, so one platform can serve BI and ML from the same files. The practical decision is no longer lake versus warehouse but which table format and query engines fit your workloads, with governance as the layer that decides whether the whole thing is an asset or a liability.

Lakes that work are organised in zones of increasing trust: a raw landing zone kept immutable, a cleaned and validated zone where schema is enforced, and a curated zone shaped for consumption. The discipline mirrors warehouse layering, and it is what keeps schema-on-read honest — flexibility at the edge, rigour where decisions are made. A lake without zones is a swamp with a roadmap.

A lake is also the wrong choice more often than vendors suggest. A team whose data is structured, whose questions are analytical and whose scale is modest gets more from a warehouse with far less governance overhead. The lake earns its complexity with machine-learning training corpora, high-volume telemetry, media and documents — workloads whose shape is not known at write time and whose volume makes warehouse pricing sting. Choosing one because it sounds like the future is how swamps get founded.

Codazz builds this in production — AI & ML Development.

FAQ

Data Lake
FAQ.

Common questions about data lake.

Ask Us Anything

A warehouse stores structured, modelled data with schema enforced on write — governed, queryable, trusted for metrics. A lake stores raw data in native form with schema applied on read — flexible, cheap, suited to exploration and ML. Warehouses trade flexibility for trust; lakes trade trust for flexibility, and governance is what buys the trust back.

A lakehouse runs warehouse-grade semantics — ACID transactions, schema enforcement, efficient SQL — over open table formats such as Delta Lake or Apache Iceberg on object storage. It aims to serve both BI and machine learning from one copy of the data, and it is the main reason the lake-versus-warehouse debate has quietened: most modern platforms are some version of this.

For serious ML, usually yes — training needs large, varied, raw corpora, and a warehouse charges warehouse prices for storing them. For lighter use cases, such as a RAG system over a few thousand documents, object storage plus a good pipeline is effectively a small lake already, and buying the category label adds nothing. The lake is a governance and scale decision, not a prerequisite for using data in models.