Data mart

What is a data mart?

A data mart is a smaller, focused analytics layer built for one department, domain, or topic. Sales may have a sales mart. Finance may have a finance mart. HR may have a people analytics mart.

The data mart contains only the data that audience needs, in definitions and structures they understand. It is often a subset of a larger data warehouse or lakehouse, shaped into a star schema, semantic model, schema, view layer, or dedicated workspace.

Think of the enterprise warehouse as the full archive. The data mart is the shelf prepared for one team: smaller, easier to search, and governed for that team's use.

When do you use a data mart?

• Sales analysis. Orders, customers, opportunities, products, and account managers for the commercial team.

• Finance reporting. Revenue, margin, cost centres, budgets, and actuals, with stricter access rules.

• HR dashboards. Employee data, absence, hiring, turnover, and sensitive people metrics.

• Marketing funnels. Campaigns, web events, leads, CRM contacts, and conversion stages.

The pattern is the same: a specific audience, a specific set of questions, and specific access rules.

Dependent, independent, and hybrid data marts

Classic data warehouse literature usually distinguishes three types.

Dependent data mart
A dependent mart is fed from the central data warehouse or lakehouse. This is usually the safest pattern because shared definitions stay aligned. Customer, revenue, product, and date mean the same thing everywhere.

Independent data mart
An independent mart pulls directly from source systems. It can be fast to build for one team, but it often creates silos. After a few years, several departments may each have their own answer to how many active customers do we have?

Hybrid data mart
A hybrid mart combines shared warehouse data with department-specific source data. This is common in practice: the core comes from governed data, while local planning files or campaign data are added for a particular use case.

Data mart versus data warehouse versus data lake

Data warehouse
The warehouse is the broader, governed analytics store for the organisation. It holds shared, modelled data for several teams.

Data lake
The lake stores raw and varied data in files, often before it has been modelled for reporting.

Data mart
The mart is the focused delivery layer for one department or subject area.

These are not enemies. A common pattern is: raw data lands in a lake, curated tables are built in a warehouse or lakehouse, and departmental data marts expose the pieces each team needs.

Modern data marts

Older data marts were often separate physical databases. That still happens, but modern marts are often logical:

• a schema in a warehouse

• a set of views over curated tables

• a Power BI semantic model

• a Fabric workspace or lakehouse layer

• a dbt model folder for one domain

The architecture matters less than the contract: this layer is curated for a defined audience, with known grain, definitions, ownership, and access rules.

What to watch out for

Mart sprawl
If every team builds its own independent mart, the organisation gets data silos with prettier dashboards. Use shared conformed dimensions and common definitions where numbers must line up.

Building for one dashboard
A mart designed around one visual breaks when the next question arrives. Model around a business process and grain, not around today's chart.

Security shortcuts
Department-specific marts often contain sensitive data. Finance and HR marts need deliberate access rules, not copied permissions from a general workspace.

Power BI Datamart confusion
Microsoft introduced a Power BI Datamart feature as a managed self-service database and dataset experience. The feature name and the general concept are different. When someone says datamart, ask whether they mean the Power BI feature or the broader architecture pattern.