---
url: /technical/modlr-vs-sql-reporting-vs-decisions.md
description: >-
  How MODLR's Scenario dimension and live recalculation support acting on a
  decision and testing a sensitivity, compared to a SQL warehouse built to
  report on what already happened.
---

# 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](/technical/feeders-invalidations-and-rules.html). 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](/technical/dataspreading.html) 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](/technical/instance-security.html) controlling who can write to which Scenario and intersection, and every change recorded in the [Cube Log](/technical/cube-logs.html) 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](/technical/modlr-vs-sql-when-to-use-each.html).

## 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.
