GCP Data Architect Series - Part V
Kimball vs Data Vault in BigQuery

Let’s compare realistically.
| Aspect | Kimball (Star) | Data Vault |
|---|---|---|
| Modeling style | Business-first | Source-first |
| Query performance | Excellent | Requires marts |
| Complexity | Moderate | High |
| Storage usage | Efficient | Higher |
| Change handling | SCD | Built-in historization |
| Best for BI | Yes | Needs transformation |
Kimball in BigQuery
Strengths:
Simple joins
BI-friendly
Lower query cost
Works well with Looker/Power BI
Best for:
Analytics-focused teams
Fast reporting
Small-medium complexity environments
Data Vault in BigQuery
Structure:
Hubs (business keys)
Links (relationships)
Satellites (attributes/history)
Example:
link_customer_order
sat_customer_details
Pros in BigQuery:
Handles schema evolution well
Great for multi-source ingestion
Strong auditability
Cons:
More joins
Requires marts layer for BI
More engineering overhead
My Practical Rule
Use:
Kimball for analytics layer
Data Vault only if:
You have 10+ source systems
Strict audit requirements
Constant schema changes
Many enterprises do:
Data Vault → Transform → Kimball Marts
Comments (0)
No comments yet.
