← Back to AI and Machine Learning

Data Platform Terms

Data platform terms across warehouses, lakes, marts, pipelines, and lakehouses.

AI and Machine LearningData LakesData Warehousing

Data vocabulary gets confusing because many terms describe both a technology choice and a way of organising work. The easiest way to keep them straight is to ask two questions: what shape is the data stored in, and what kind of analysis or serving is the system built to support?

Warehouse, lake, and mart

A data warehouse is a structured analytical store designed for reporting, historical analysis, and business intelligence. Data is usually cleaned, modelled, and loaded into schemas optimised for query performance and consistency.

A data mart is a narrower slice of analytical data built for a specific team or domain, such as finance or marketing. It may be physically separate or simply a logical model on top of a warehouse.

A data lake stores large amounts of raw or lightly processed data in its native formats, often on object storage. It is flexible because you can ingest first and model later, but that same flexibility can turn into disorder if ownership and standards are weak.

Lakehouse, pipeline, ETL, and ELT

A lakehouse is an attempt to combine lake flexibility with warehouse-like reliability and table semantics. The point is to make open storage behave more like a managed analytical platform, including transactional guarantees and better schema handling.

A data pipeline is the machinery that moves and transforms data between systems. ETL means extract, transform, load: clean the data before loading into the target store. ELT means extract, load, transform: land the raw data first, then transform it inside a system built for heavy computation.

The right choice depends on where compute is cheaper, where governance is stronger, and how much raw history you want to preserve.

Data mesh and ownership terms

Data mesh is less a storage product than an organisational model. It argues that domain teams should own data products for their area instead of routing everything through one central data team. Done well, that can improve relevance and accountability. Done badly, it creates fragmented standards and duplicated work.

A practical way to remember the terms

Warehouses optimise for curated analytics. Lakes optimise for flexible ingestion and large-scale storage. Pipelines move and reshape data between systems. Lakehouses try to narrow the gap between lake and warehouse. Data mesh changes who owns and serves data.

These terms matter because they imply different guarantees, costs, and team responsibilities. If you know whether the problem is raw storage, curated analytics, data movement, or data ownership, the vocabulary becomes much easier to use correctly.

A final distinction worth keeping in mind is schema timing. Warehouses usually enforce more structure before data becomes widely consumable, while lakes often defer that structure until read time. That difference affects data quality, governance effort, and how quickly teams can onboard new sources without creating chaos.