Kimball vs One Big Table: The 10 GB Join-Side Heuristic

The debate the canon skips

Everything you have rehearsed in this module is Kimball: a narrow fact surrounded by dimensions you join to. It is still the junior interview canon and it is still the right default. But it is not the only live answer in 2026, and the follow-up question is coming.

One Big Table (OBT) is the alternative: pre-join the dimensions into the fact once, at load time, and ship one very wide table. Every query becomes a single-table scan with no joins at all. Columnar engines make this viable in a way row stores never did, because a query that selects 4 columns out of 300 reads only those 4. BI teams love it: no join grammar to teach, no fan-out to explain, and dashboards get faster.

Adoption says it is a minority position and a real one. Practitioner surveys put mixed approaches at 36.8%, Kimball at 27.8%, ad-hoc at 17.4%, semantic models at 5.4%, One Big Table at 3.8%, and Data Vault at 3.3%. So Kimball is the default you should be able to build, and OBT is the tradeoff you should be able to argue.

Schema

• driver_key
• home_city
• vehicle_class

• trip_id
• driver_key
• fare_usd

• trip_id
• driver_key
• home_city
• vehicle_class
• fare_usd

• fact_trips (star)n-1dim_driver— joined at query time

The heuristic that makes the answer sound experienced

The working rule from the modeling community: stay with Kimball while the join side is under roughly 10 GB. Under that, the engine can broadcast the dimension to every worker and the star join costs almost nothing. Past it, the dimension has to be shuffled across the network alongside the fact, and shuffle cost can run 10x to 100x the broadcast case. That is when pre-joining into an OBT starts earning its storage bill.

You have seen this physics before. In Module 7.1, DS_BCAST_INNER versus DS_DIST_BOTH in a query plan is the same fork, read off a plan after the fact. Here you are making the same call at design time, before anyone runs anything. Choosing a distribution key that co-locates the join is the third option in the same family.

When Kimball wins anyway, regardless of size

Three conditions override the size heuristic:

1. Conformed dimensions. If dim_driver is joined by trips, payouts, and support tickets, an OBT means maintaining three copies of every driver attribute and hoping they agree. The whole point of a conformed dimension is that "home city" means one thing across the warehouse.
2. History has to version. The SCD2 machinery from the last lesson has nowhere to live in an OBT. There is no dimension row to close and reopen, so a driver's move either rewrites history everywhere or is lost.
3. Dimension attributes change often. In an OBT, changing one attribute on one driver rewrites every fact row that driver ever appeared in. On a billion-row table that is not an update, it is a rebuild.

Common mistake: treating the storage growth as the whole cost and stopping there. Storage is the cheap part. The expensive part is that an OBT converts a small dimension update into a large fact rewrite, and it converts one shared definition into several private copies that drift.

Interview nuance: "would you just make one big table?" is a real follow-up to any star-schema answer, and it is a judgment probe, not a knowledge probe. Answering "no, Kimball is correct" reads as dogma. Answering "OBT, it is faster" reads as inexperience. The strong answer names the number and one cost of each path: "I would keep the star while the dimension side stays under about 10 GB, since the engine broadcasts it and the join is nearly free. Past that I would pre-join into a wide table, and I would accept that a dimension change now rewrites the fact and that these attributes stop being conformed."

On a real platform this differs. Real OBTs usually are not flat. Snowflake, BigQuery, and Databricks all support nested ARRAY<STRUCT> columns, so a trips table can carry the driver's attributes as one nested struct and the trip's waypoints as an array, keeping the single-table scan without exploding the row count. And the decision is rarely permanent: teams often keep the Kimball star as the modeled layer and materialize an OBT on top of it for BI, which buys the fast dashboards without giving up the conformed dimensions or the version history.