---
title: "Conformed dimension"
description: "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."
canonical: "https://motherduck.com/glossary/conformed-dimension/"
related:
  - title: "Database Concepts | MotherDuck Docs"
    url: "https://motherduck.com/docs/concepts/database-concepts/"
  - title: "Context Management for Data Agents | MotherDuck"
    url: "https://motherduck.com/videos/context-management-data-agents/"
  - title: "Internal vs. External Storage: What's the Limit of External Tables?"
    url: "https://motherduck.com/blog/internal-vs-external-storage-whats-the-limit-of-external-tables/"
---

# Conformed dimension

> 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.

## Overview

A conformed dimension has the same structure, keys, and meaning no matter which fact table it's joined to. `dim_date`, `dim_customer`, and `dim_product` are the classic examples: rather than each department or data mart building its own version of "customer" with its own key scheme, the whole warehouse shares one `dim_customer` table. That's what lets you compare "revenue by region" from a sales fact table against "support tickets by region" from a support fact table — both join to the exact same `region` values from the same dimension.

Conformed dimensions are the backbone of Kimball's **bus architecture**: a matrix of business processes (rows) against shared dimensions (columns) that's used to plan a warehouse so that every new fact table reuses existing dimensions instead of creating incompatible, one-off copies.

### Example

```sql
-- One shared dim_date, referenced by every fact table in the warehouse
CREATE TABLE dim_date (
    date_key   INTEGER PRIMARY KEY,
    full_date  DATE,
    quarter    VARCHAR,
    fiscal_year INTEGER
);

CREATE TABLE fact_sales   (date_key INTEGER REFERENCES dim_date(date_key), revenue DECIMAL(12,2));
CREATE TABLE fact_support (date_key INTEGER REFERENCES dim_date(date_key), tickets_opened INTEGER);

-- Comparable across business processes because both use dim_date
SELECT d.quarter, SUM(s.revenue) AS revenue, SUM(t.tickets_opened) AS tickets
FROM dim_date d
LEFT JOIN fact_sales s USING (date_key)
LEFT JOIN fact_support t USING (date_key)
GROUP BY ALL;
```

A dimension can also be **conformed at a subset of its attributes** — two fact tables might share only the `region` and `country` columns of an otherwise different customer dimension, which is still enough to compare metrics at that shared grain.

### DuckDB angle

There's nothing DuckDB-specific about conforming dimensions — it's a modeling discipline — but building all fact tables in a DuckDB or MotherDuck warehouse against one physical `dim_date`/`dim_customer` table (rather than copies per mart) is what makes cross-fact-table joins and comparisons actually correct.