Star Schema vs One Big Table: How to Model the Data Under Your Dashboards
Last updated: August 2026
Most arguments about analytics stacks happen one layer too high. Teams debate the warehouse, the transformation tool, the BI vendor, and the semantic layer, wire it all together, then wonder why the dashboards still feel fragile. The choice that quietly decides whether the whole thing holds up gets skipped: the shape of the tables sitting between your raw data and your reports.
There are two dominant shapes, and nearly every analytics table you will ever build is a version of one of them. The first is the star schema, the design Ralph Kimball introduced to data warehousing in the 1990s. The second is the one big table, usually shortened to OBT, which flattens everything into a single wide table so a query needs no joins. Picking between them is not a matter of taste. It changes how fast queries run, how much rework a new question costs, and whether anyone can trust the number on the dashboard six months from now.
What a star schema actually is
A star schema splits data into two kinds of tables. Fact tables record events that happened: an order, a payment, a shipment, a login. Each row is one occurrence of that event. The columns are mostly the numbers you want to measure (amount, quantity, duration) plus a handful of keys that point to context. Dimension tables hold that context: the customer who placed the order, the product that sold, the store it sold in, the calendar date it happened on.
Draw it out and you get a fact table in the middle with dimension tables radiating off it, which is where the “star” comes from. An orders fact table might carry an order line total and quantity, with keys to dim_customer, dim_product, dim_store, and dim_date. When someone asks for revenue by product category last quarter, the query joins the fact table to the product and date dimensions and aggregates. The structure keeps measurements in one place and descriptive attributes in another, so the same customer dimension can feed orders, returns, and support tickets without being copied three times.
The reason this design has survived thirty years of hardware changes is that it maps cleanly onto how businesses ask questions. Facts are the things you count and sum. Dimensions are the ways you slice them. Most BI tools are built with this split in mind and can detect the relationships automatically, which is part of why star schemas remain a comfortable fit for tools like Tableau, Power BI, and Looker.
What one big table means
OBT takes the opposite approach. Instead of keeping facts and dimensions separate, you pre-join everything into one wide, denormalized table. Every order row carries not just the amount and quantity but also the customer name, the customer region, the product category, the store city, and any other attribute you might filter or group by. The joins are done once, up front, when the table is built. Queries against it are simple because there is nothing left to join.
On a columnar warehouse this is less wasteful than it sounds. Wide tables compress well, because a column that repeats “Electronics” a million times costs almost nothing once compressed, and columnar engines only scan the columns a query touches. The old penalty for very wide tables has largely gone away. That is why OBT became popular in the modern stack rather than despite it: the design leans into how columnar storage actually works.
The performance question, and its honest answer
The usual argument for OBT is speed, and there is a real benchmark behind it. Fivetran tested both patterns across Redshift, Snowflake, and BigQuery and found that a single denormalized table produced substantially faster query times than an equivalent star schema, on the order of 25 to 50 percent in their tests. Skipping joins at query time is genuinely cheaper than paying for them on every run.
The honest answer is that this gap has narrowed and matters less than the number suggests. Modern columnar engines handle star-schema joins efficiently, so for most dashboards the difference is milliseconds a user will never notice. Where the pre-join still earns its keep is at the edges: very high-concurrency dashboards, or BI tools that struggle to generate good join logic. A 40 percent speedup on a query that already returns in half a second is not a reason to rebuild your modeling approach. A 40 percent speedup on a dashboard that a thousand people hit at 9 a.m. every Monday might be.
So performance is a real input, but it is rarely the deciding one. The deciding one is what happens when the questions change.
Where each design breaks
OBT is fast to query and easy to hand to someone who does not write joins. Its cost is flexibility, and the cost shows up later rather than on day one. A wide table is built for the questions you anticipated when you built it. The moment someone needs an attribute you did not flatten in, you are back in the pipeline rebuilding the table, not just writing a different query. The star’s separation of facts and dimensions is exactly what lets a new question reuse the existing model instead of triggering new engineering work.
History is the other place OBT gets awkward, and it is worth slowing down on. Suppose a customer moves from Ohio to Texas. In a star schema you can keep both facts straight: orders placed while they lived in Ohio stay attributed to Ohio, and later orders point to Texas. This is handled with what Kimball calls slowly changing dimensions. The common approach, Type 2, adds a new dimension row each time an attribute changes and stamps it with effective dates, so every fact links to the version of the customer that was true at the time. Type 1 simply overwrites the old value and loses the history. In a flat table, deciding which region to stamp on which order, and updating that logic every time an attribute changes, turns into a maintenance problem the star schema was designed to avoid.
Reuse is the third difference. Star schemas share what Kimball calls conformed dimensions: one dim_customer and one dim_date used by every fact table across the business, with the same keys and the same attributes. That shared vocabulary is what lets finance, marketing, and product all count “customers” the same way. When every consumer gets its own wide table, those definitions drift, and you end up with the classic problem of three teams walking into a review with three different numbers for the same metric.
The decision that outranks both: declare the grain
Before you choose a shape, choose a grain. The grain of a table is the business definition of what one row represents, and it is the single most important decision in the whole design. Kimball’s own rule is to state it explicitly and never mix levels: one row per order line item, or one row per customer per day, or one row per support ticket. Get this wrong and no amount of tooling saves you.
The most common mistake is modeling at too high a level. If you build your orders table at the order level and someone later asks which individual products sold best on weekday afternoons, you cannot answer it, because the line-item detail was thrown away. The safe default is the most atomic grain the source data allows. Atomic data can always be rolled up later. Data you already aggregated cannot be pulled back apart. Declaring the grain first, and holding every row to it, is what keeps a model coherent whether you land on a star schema or a wide table.
What most mature teams actually do
The practical answer is not one shape for everything. Most teams that have lived with both settle on a star schema as the core, with wide tables built on top for specific consumers. The star is the flexible foundation that can answer questions nobody has asked yet. The OBT is a serving layer, an optimization for a known dashboard or a tool that wants everything pre-joined. You build the wide table from the star, not instead of it, which means you keep the flexibility and history in one place and pay for the pre-join only where it buys something.
There is also a pragmatic case for not modeling too early. As the team behind the Analytics Setup Guidebook puts it, you should model when you have to. If a report is easy to write straight off the raw tables, write it. The point of dimensional modeling is to make hard, repeated questions cheap and consistent, not to add ceremony to simple ones. Reach for a proper star schema when the same metrics start showing up in multiple places, when history matters, and when different teams need to agree on what a number means.
How this connects to the rest of your stack
The modeling layer is not an isolated decision. It shapes everything built on top of it. A semantic layer that centralizes metric definitions works far better when it sits on clean dimensional models, because the metrics it defines map directly onto facts and dimensions instead of onto columns buried in an ad hoc wide table. The transformation tool you use to build these models matters too, and the choice between dbt and SQLMesh is partly a question of how you want to manage the incremental logic and tests that keep facts and dimensions in sync.
Modeling even decides how well the newer AI features perform. Anyone shipping a text-to-SQL feature learns quickly that a language model writes far more reliable queries against a clean star schema with well-named tables than against a sprawl of raw source tables or an undocumented wide table with two hundred columns. Good modeling is not a legacy concern that the AI stack made obsolete. It is the thing that makes the AI stack work.
How to decide, briefly
Start with the grain and write it down. Default to the most atomic level your source data supports. If your questions change often, if history matters, or if multiple teams need to agree on definitions, build a star schema and treat it as the source of truth. If you have a specific, stable dashboard that gets heavy traffic and a tool that dislikes joins, build a one big table on top of the star for that consumer. Reach for OBT as an optimization for known questions, not as the shape you reach for by default. And revisit the decision when the data or the questions outgrow it, because the wrong grain is far more expensive to fix than the wrong shape.
The tools will keep changing. Warehouses get faster, transformation frameworks come and go, and the AI layer rearranges what the interface looks like. The shape of your tables outlasts all of it, which is exactly why it deserves more attention than it usually gets.
