---
title: "Data mart"
description: "A data mart is a subject- or department-specific subset of a data warehouse, scoped to the needs of one business area like sales, marketing, or finance."
canonical: "https://motherduck.com/glossary/data-mart/"
related:
  - title: "DuckLake Architecture Deep Dive"
    url: "https://motherduck.com/blog/ducklake-architecture-deep-dive/"
  - title: "Context Management for Data Agents | MotherDuck"
    url: "https://motherduck.com/videos/context-management-data-agents/"
  - title: "Data Warehousing How-to | MotherDuck Docs"
    url: "https://motherduck.com/docs/key-tasks/data-warehousing/"
---

# Data mart

> A data mart is a subject- or department-specific subset of a data warehouse, scoped to the needs of one business area like sales, marketing, or finance.

## Overview

A data mart is a smaller, focused slice of a larger data warehouse, built around the needs of a single department or business process — a sales data mart, a marketing data mart, a finance data mart. Where a warehouse aims to be the comprehensive, integrated source of truth across the whole organization, a data mart trades that scope for simplicity and speed: fewer tables, a schema tailored to one team's questions, and often faster queries because there's less data and complexity to wade through.

Kimball's dimensional modeling approach treats data marts as the natural unit of delivery: each mart is typically one or a few fact tables (a business process) plus their dimensions, built using **conformed dimensions** shared across the whole warehouse so marts stay comparable with each other even though each one is scoped narrowly.

<glossary-callout video="preparing-data-warehouse-for-ai" />

### Example

```sql
-- A sales data mart: just the fact and dimensions sales needs
CREATE SCHEMA sales_mart;

CREATE TABLE sales_mart.fact_sales AS
SELECT * FROM warehouse.fact_sales;

CREATE TABLE sales_mart.dim_customer AS
SELECT * FROM warehouse.dim_customer;   -- conformed, shared with other marts

CREATE TABLE sales_mart.dim_product AS
SELECT * FROM warehouse.dim_product;

SELECT p.category, SUM(f.revenue) AS revenue
FROM sales_mart.fact_sales f
JOIN sales_mart.dim_product p USING (product_key)
GROUP BY ALL;
```

### Dependent vs. independent marts

A **dependent** data mart is built from an existing central warehouse (as above) — generally the safer, more consistent approach, since it inherits conformed dimensions. An **independent** data mart is built directly from source systems without a shared warehouse behind it, which is faster to stand up but risks producing metrics that don't reconcile with other marts or the rest of the organization.

### DuckDB angle

DuckDB's schema support (`CREATE SCHEMA`) makes it easy to organize a single database into department-scoped data marts side by side, and MotherDuck's ability to share individual databases or schemas with specific teams maps naturally onto giving one department read access to just its own mart without exposing the full warehouse.