Reporting vs Decisions

A SQL warehouse and the BI layer on top of it are built to answer "what happened" - they're query engines over data that's already landed. MODLR is built to also answer "what happens if" - a Scenario Dimension and live recalculation mean an assumption can be changed and its consequences seen immediately, without re-running a pipeline. That's the point at which a project stops being about reporting and starts being about acting on a decision.

Reporting on what happened, in SQL

A SQL query returns the state of the data at the moment it's run. Testing a different assumption - what if volume were 5% higher, what if a cost allocation changed - means writing a new version of that assumption into the data (or a copy of it), then re-running the query or the ETL that feeds the dashboard. There's no native place to hold "what if this were different" alongside "what actually happened" - that has to be built, usually as a separate table, a separate pipeline, or a spreadsheet bolted on the side.

Modelling what happens next, in MODLR

Scenario is typically its own Dimension - Actual alongside as many Draft and Final Budgets and Forecasts as the planning process needs. Every scenario shares the same Cubes, the same Hierarchies and the same formulas; a scenario is just another element on a Dimension, not a parallel copy of the tables and pipeline that produce it. A Draft scenario can carry live calculation logic - allocations, growth rates, driver-based assumptions - while Actual and Final scenarios hold point-in-time values, so comparing a plan against Actuals is a normal MODLR Workview, not a manual reconciliation between two different systems.

Live recalculation

Changing an input in MODLR doesn't require a query to be re-run - it recalculates automatically, because every formula is backed by Feeders and Invalidations. A formula like ["Revenue"] = ["Units Sold"] * ["Price"] registers a feeder and an invalidation against both of its inputs, so a change to Units Sold or Price invalidates and recalculates Revenue - and everything built on top of Revenue - immediately, across every Time period, Entity or Product it applies to. That's what makes it possible to ask "what happens if volume is 5% higher this quarter" and see the answer land across the whole model, rather than having to identify and re-run every downstream query that depends on it.

Concurrent, governed write

A SQL table is built to be the output of a pipeline, not a surface a few hundred people type numbers into at once. MODLR's write path - Dataspreading from a Workview, Card or the Excel Add-in - is built for exactly that: many people entering assumptions into the same governed Cube concurrently, with Instance Security controlling who can write to which Scenario and intersection, and every change recorded in the Cube Log as it happens.

For when a SQL + BI stack is still the better fit, and when the need for driver-based sensitivities tips the balance towards MODLR, see When to Use Each.

Illustrating the improvement

• Scenario is a Dimension element, not a parallel set of tables and pipelines - Draft, Final and Actual share the same Cubes, Hierarchies and formulas.
• A changed assumption recalculates immediately, across every dependent formula and every Dimension it touches, because of Feeders and Invalidations - not by re-running a query or a pipeline.
• The same governed Cube supports many people planning into it concurrently, with the write path, the security and the audit trail all part of the one model - not a separate mechanism bolted onto a read-only warehouse.