What is a data mart?
A data mart is a subset of a data warehouse curated for one team or subject area, along with the tables, models, and dashboards that team actually uses. Marketing gets its campaigns, sessions, and attribution tables; finance gets its invoices, payments, and revenue recognition tables. Same warehouse underneath, different vertical slice on top.
Data marts aren’t something you buy. They’re something your organization defines: a scope, a set of transformations that produce the tables in that scope, and the “human interface” — the BI tool collection of dashboards and saved questions — that the team works in.
Data mart vs. data warehouse vs. data lake
The three terms sit at different levels of structure and scope:
- A data lake holds raw data of any shape, structured or not, with no schema enforced when it’s written. Broad scope, minimal structure.
- A data warehouse holds structured, cleaned data from many sources, modeled for analysis. Broad scope, high structure.
- A data mart holds a curated slice of that structured data for one audience. Narrow scope, high structure, and usually more aggregation.
The distinctions are fuzzier in practice than the diagrams suggest — plenty of organizations run all three, and a “mart” is frequently just a schema in the same warehouse rather than a separate system.
Why build one
Findability. A warehouse with 800 tables is not a place a marketer wants to go looking. Twenty well-named tables scoped to their work is.
Shared definitions. When one team owns a slice, they can settle on what “qualified lead” or “recognized revenue” means for their reporting, ideally through a semantic layer rather than a folder of near-identical SQL.
Performance and cost. Mart tables are usually pre-joined and pre-aggregated, often in a star schema, so common questions scan far less data than they would against raw fact tables.
Access control. A narrower slice is easier to grant access to. HR can have the people tables without also having the payments tables.
The tradeoff
Every mart is another set of pipeline steps to maintain, and marts drift. If the finance mart and the sales mart each build their own version of “customer” from the raw tables, you’ve reproduced the silo problem one level up. The usual guard is to build marts on top of shared, conformed core tables rather than straight off raw sources — so the marts differ in scope and aggregation, not in what the underlying entities mean.
Key article
Related terms
Further reading
Put it to work
- Marketing analytics — Overview
- Finance analytics — Overview
- Marketing funnel dashboard — Dashboard
