When to Use Each

None of the comparisons in this series - Aggregation & Hierarchies, Governance & Write-back, Reporting vs Decisions - are a case that SQL is the wrong tool. They're a case that SQL solves a different problem to the one MODLR solves, and it's worth being explicit about which problem is actually in front of a team before reaching for either.

When SQL is the right call

For pure historical reporting and analytics at scale - large historical datasets, ad hoc slicing, dashboards nobody needs to write back into - a SQL warehouse and a BI layer on top is the cheaper, more standard choice, with a bigger ecosystem and a more common skillset to hire for. That's what warehouses and BI tools are optimised for, and building that in MODLR instead would be reinventing infrastructure that already exists and is well understood.

Pressure-test "genuinely read-only"

The assumption worth checking before defaulting to "we'll sort security out in the BI layer" is whether a report is going to stay read-only. A report that starts as pure reporting often grows a "can we just adjust this forecast from here" request within a quarter or two - and at that point the read-only design the security model was built on no longer holds, because a BI tool's row-level security was never built to also govern who can write. If write-back is even a plausible future requirement, it's worth building the governance once, rather than layering a second security model on top of SQL later, under time pressure, once someone's already asking to edit the "report".

If the data's already in MODLR

If the underlying data already lives in MODLR because it's used for planning, there's no separate SQL/BI security model to stand up just to report on it read-only - the same Instance Security and Access Tags that govern the plan already govern anyone who only ever reads it, and the same Card can be reused across the web portal, Excel, PowerPoint, email and embeds it needs to reach. The read-only-vs-write-back question really only tips the decision toward a standalone SQL + BI stack when the data isn't already governed inside MODLR for some other reason.

When MODLR is the right call

The shift towards MODLR happens at the point a model needs to do more than describe the past:

• Hierarchies that have to stay correct everywhere at once - an EBITDA or Net Profit rollup, a reorg, a chart-of-accounts change - maintained once as a Dimension Hierarchy rather than as mapping tables and views duplicated per report. See Aggregation & Hierarchies.
• Concurrent planning input governed by the same model that reports on it - many people entering assumptions into a Cube at once, with security, write-back and the audit trail all part of one system rather than a read-only warehouse with a form bolted on. See Governance & Write-back.
• Driver-based sensitivities that need to be seen immediately - changing an assumption and having every dependent number recalculate live, rather than re-running a query or a pipeline to see the effect. See Reporting vs Decisions.

A relational table and a BI tool can approximate any one of these individually with enough custom engineering - a mapping table here, a bolted-on write-back form there, a recalculation service on the side - but each is a separate thing to build and maintain. In MODLR they're native properties of the same governed model.

Illustrating the improvement

• SQL + BI is the right, cheaper choice for reporting that is genuinely read-only and isn't sourced from data MODLR already governs for planning.
• The risk in defaulting to SQL + BI is a read-only assumption that doesn't hold - a "just let me edit this" request arriving after the security model was already built around read-only access.
• MODLR earns its place once a model needs governed hierarchies, concurrent write-back, or live recalculation - three things a relational stack has to bolt together custom, one piece at a time.