A star schema puts one fact table at the center with denormalized dimensions around it and is the read-optimized model Databricks recommends for BI. A snowflake schema normalizes those dimensions into sub-dimensions, saving storage at the cost of more joins. A data vault of hubs, links and satellites is write-optimized and auditable, built for integrating many changing sources, and feeds a star schema rather than replacing it.
Last updated September 2026.
For dashboards and ad hoc SQL, build a star schema in the gold layer. Snowflake a dimension only when a deep, shared hierarchy or an explicit storage constraint demands it. Use a data vault in the silver layer when you are integrating many sources whose schemas change and every load must be traceable, then publish a star schema on top of it for the analysts. A vault is never the model a dashboard should query.
One fact table holds the measures (amount, quantity) and a foreign key per dimension; each dimension holds the descriptive context (product with its category and department in one row, the calendar, the customer). Every query is the fact plus one join per dimension it needs. Databricks' data modeling guidance is explicit about why this performs well on the platform: standard queries carry fewer joins, there are fewer keys to keep in sync, and more columns in a single table let the optimizer skip data using file-level statistics. Redundancy in the dimensions is the accepted price.
The Databricks-specific build is Delta tables, Liquid Clustering on the join keys and common filters (one to four columns), surrogate keys from BIGINT GENERATED ALWAYS AS IDENTITY, and MERGE for slowly changing dimensions. Declare the primary and foreign keys too: they are informational, never enforced, but with RELY the optimizer can eliminate unnecessary joins, and Catalog Explorer draws the entity relationship diagram from them.
Take the star and break each dimension into its hierarchy: product links to category, which links to department. Each attribute is stored once, hierarchies stay consistent, and the diagram branches like a snowflake. The Databricks glossary lists the trade plainly: more storage efficiency from tighter normalization, but more overhead to set up, a more rigid model, higher maintenance cost and query performance below the denormalized star, because every hierarchy walk is a multi-level join.
On the lakehouse, storage is cheap and joins are the cost, so the snowflake is the contrast case. It still wins when a deep hierarchy is shared by many facts and must be maintained in exactly one place.
Three structures: hubs hold core business entities and their business keys, links record relationships between hubs, and satellites hold the descriptive attributes of a hub or link with their load timestamps. The raw vault is insert-only and keeps the source metadata, so every value is traceable to the load that delivered it. New sources become new satellites or hubs added incrementally, with far less refactoring of existing loads, and the tables have few dependencies, so loads run in parallel.
That makes it the integration layer, not the presentation layer. Databricks positions the vault in silver, with the hubs and satellites loading the dimensions and the links driving the fact tables of a star schema in gold. Analysts, dashboards and Genie spaces read the star, never the vault.
| Star | Snowflake | Data vault | |
|---|---|---|---|
| Optimized for | Reads | Storage, consistency | Writes, integration |
| Joins per query | One per dimension | Multi-level chains | Many (hub, link, satellite) |
| Change tolerance | Moderate | Rigid | High: add tables |
| Medallion layer | Gold, marts | Gold, marts | Silver (raw and business vault) |
| Who queries it | Analysts, dashboards, Genie | Analysts, with more joins | Engineers and loaders |
Sourced from the Databricks glossary pages on star schema, snowflake schema and data vault, the Databricks SQL data modeling page, and the Databricks blog on data warehousing modeling techniques on the lakehouse.
Exam tip: "Simple, fast BI queries" picks the star. "Normalized hierarchies" or "storage efficiency" as an explicit requirement picks the snowflake. "Many changing sources", "auditable", "add a source without refactoring" picks the data vault, and the correct option almost always adds "feeding a star schema in gold".
The tempting wrong answers are a data vault offered for a dashboard because auditability sounds responsible, and a snowflake offered because normalization sounds rigorous. Both are real models used in the wrong layer.
A star schema keeps each dimension in one denormalized table joined directly to the fact table, so queries need one join per dimension. A snowflake schema normalizes dimensions into sub-dimension tables, which saves storage but adds multi-level joins and maintenance.
A star schema in the gold layer. Databricks documents that star and snowflake schemas perform well on the platform, with the star favored because fewer joins and wider tables let the query optimizer skip data using file-level statistics.
In the silver layer. The raw vault and business vault hold hubs, links and satellites loaded from bronze staging, and their hubs, satellites and links load the dimensions and facts of a star schema in gold, which is what dashboards query.
No. Primary key, foreign key and unique constraints are informational only. They document the model, feed the entity relationship diagram and Genie join relationships, and with the RELY option let the optimizer eliminate unnecessary joins, but they never reject rows.
Star, snowflake and data vault is a trade-off chapter in the Data Analyst Associate course, followed by a chapter on where each model sits in the medallion architecture.
Open the chapter →