Data Architecture Guide

Data Warehouse Design Guide

Star schema or wide tables? Partitioned or clustered? This guide covers data warehouse design patterns for modern cloud platforms — from modeling fundamentals to production architecture.

18 min readFor Data Engineers & Architects

See it as a diagram

Everything below, as a diagram you can edit. Describe yours and see it in seconds.

110/20003 credits left
Try:

No account needed · Editable canvas, not a picture

1. Modeling Patterns

Star Schema

Central fact table + denormalized dimension tables. The default choice for analytics. Simple joins, predictable performance, easy for BI tools.

Snowflake Schema

Normalized dimension tables (dimensions have sub-dimensions). Saves storage but adds join complexity. Rarely needed with modern warehouse pricing.

Wide / OBT (One Big Table)

Pre-joined denormalized table with all dimensions flattened. Best for simple dashboards and when query simplicity matters more than flexibility.

Data Vault

Hub + Satellite + Link tables for full auditability and historical tracking. Complex to build but excellent for regulated industries.

2. Star vs Snowflake Schema

AspectStar SchemaSnowflake Schema
Dimension StructureDenormalized (flat)Normalized (sub-tables)
Query ComplexitySimpleComplex
StorageMore (redundant data)Less (normalized)
BI Tool CompatibilityExcellentGood
Recommendation (2026)PreferredUse only when storage is expensive

Hot Take: Just Use Star Schema

In 2026, cloud storage costs pennies per GB. The join simplicity and BI compatibility of star schemas outweigh any storage savings from snowflake schemas. Default to star.

3. Architecture Layers

Raw / Bronze

Ingested data as-is from sources. No transformations. Full history. Schema-on-read.

Cleaned / Silver

Deduplicated, typed, filtered. Business keys resolved. Ready for joining across domains.

Business / Gold

Star/snowflake models, aggregations, KPI tables. Consumed by BI tools, APIs, and ML.

4. Platform Comparison

FeatureSnowflakeBigQueryRedshift
Compute ModelMulti-clusterServerlessProvisioned
Best ForMulti-cloud, sharingGCP, streamingAWS-heavy orgs
Pricing ModelCredits (compute)Per TB scannedPer node/hour

5. Design Best Practices

1

Default to star schema for analytical models

2

Separate raw, cleaned, and business layers

3

Use surrogate keys (hashed natural keys)

4

Partition large fact tables by date

5

Cluster/sort by frequently filtered columns

6

Document every table and key column

7

Test for grain (one row per entity per time period)

8

Version your models in Git (dbt or similar)

6. FAQ

What is a star schema?
A central fact table surrounded by denormalized dimension tables. Optimized for analytical queries with simple, predictable joins. The default choice for data warehouse modeling.
Star schema vs snowflake schema?
Star has flat dimensions; snowflake normalizes them. In 2026, star schema is preferred because storage is cheap and query performance matters more.
How do you choose between Snowflake, BigQuery, and Redshift?
Snowflake for multi-cloud and data sharing. BigQuery for GCP and serverless. Redshift for AWS-heavy orgs with predictable workloads.

Design your warehouse architecture

AI-generated warehouse diagrams with star schemas, fact tables, and cloud service icons.

Try Datadef Free