What’s the best choice: star schema or denormalized flat table for reporting?

[Mia.S]

I’m trying to decide between using a star schema or a denormalized flat table for our new reporting layer, and I keep going in circles. My team’s main concern is that the flat table will be simpler for our analysts to query directly, but I’m worried about bloating the data and losing the flexibility to easily add new dimensions later.

[DonaldM]

Using a star schema can feel like giving analysts a clean canvas, but we learned to treat it as a long game. We started with a flat table for quick wins, then hit performance and governance limits as the data grew. The moment we introduced a clear fact table with dimension links, BI tools stopped rejoining the same attributes endlessly and dashboards stayed responsive.

[LukeG]

Flat table route sounded great at first, we chased simple queries and fewer joins. Then the data grew and definitions drifted, and folks kept pulling in new attributes from nowhere. Did you consider a hybrid approach?

[Nathan.P]

Action taken: we ran a pilot with a smaller subset and measured query latency. The flat version gave 2x faster ad hoc runs, but join-heavy dashboards crawled when we added product and customer attributes. We ended up pruning columns to meet SLA and still missing some drill-downs.

[Brian58]

Sometimes I think the real issue is how we name things and how often we update it; the tech choice feels like smoothing over a process problem. We paused a migration once because the data lineage turned muddy and analysts couldn't trust the numbers. Not sure if the problem is structure or folks needing clearer governance.