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.
Example
Copy code
-- 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.
Related terms
A conformed dimension is a dimension table — like a shared date or customer dimension — that is defined identically and reused across multiple fact tables or data marts, so metrics stay comparable across the warehouse.
Dimensional modeling →Dimensional modeling is a data warehouse design methodology, developed by Ralph Kimball, that organizes data into fact tables (measures) and dimension tables (descriptive context) optimized for business-user querying.
Fact constellation schema →A fact constellation schema (also called a galaxy schema) is a dimensional model with multiple fact tables that share one or more common dimension tables.
Data warehouse →A data warehouse is a centralized system designed to store structured, cleaned data and support fast, complex analytical queries (OLAP), as opposed to the high-volume transactional workloads of an operational database.
Reverse ETL →Reverse ETL is the process of syncing curated data from a data warehouse back out into operational tools like a CRM, ad platform, or support desk, so business teams can act on it.
Star schema →A star schema is a dimensional data warehouse design where a central fact table of numeric measures connects directly to denormalized dimension tables, forming a shape like a star.
FAQS
A data warehouse is the comprehensive, integrated store of data across an organization. A data mart is a smaller, department- or subject-specific subset of it, scoped to one team's or business process's needs.
A dependent data mart is built from an existing central data warehouse, inheriting its conformed dimensions and staying consistent with other marts. An independent data mart is built straight from source systems, which is quicker but risks metrics that don't reconcile across the organization.
