For most of Anaplan's history there was one calculation engine, and every model builder learned to manage its defining constraint: sparsity. Anaplan now runs two engines side by side. Hyperblock is the original. Polaris is the newer engine designed for very large, very sparse models. Picking the right one is now part of solution design, and getting it wrong is expensive in both directions.
Sparsity, briefly
A module dimensioned by 5,000 products, 500 customers, 50 regions, and 36 months has 4.5 billion cells per line item. In a Hyperblock model every one of those cells exists in memory whether or not it holds data. If only 2% of product-customer-region combinations actually trade, 98% of that memory is holding zeros, and every calculation still runs across all of it.
That is why Hyperblock best practice is so focused on structure: keep large dimensions apart, use numbered lists of real combinations instead of cross products, push calculations into the smallest module that can hold them, and turn off summaries you do not need. Done well, Hyperblock is extremely fast. Done badly, you hit workspace limits and ten-minute recalculations.
Polaris takes the other approach. It stores and calculates only populated cells. The 4.5 billion-cell module with 2% density costs roughly the 90 million populated cells. The modeling effort that Hyperblock spends avoiding sparsity is simply unnecessary.
Workload profiles that favor each engine
Hyperblock is the better choice when:
- Your model is dense. Financial planning by cost center, account, and month is usually 60% to 100% populated; there is no sparsity to exploit.
- The model is mid-sized and well structured. Most FP&A, workforce, and sales-capacity models fit comfortably.
- You depend on functions or behaviors that Polaris does not support or supports differently (see below).
- Your team's skills, templates, and Application Lifecycle Management processes are built around Hyperblock and the model is not in pain.
Polaris is the better choice when:
- You have genuinely sparse, very large intersections: SKU by store, product by customer, part by plant, assortment planning, trade promotion planning.
- You have been forced to split one business problem into several models to fit memory, and the splits are creating reconciliation work.
- Large numbered lists exist only to avoid a cross product, and maintaining those lists is a project in itself.
- You want to add a dimension (channel, scenario) that would multiply a Hyperblock model past its limits.
What is different in Polaris
This is the part that surprises teams who expected a checkbox.
- Function support. Not every Hyperblock function is available in Polaris, and the supported set has grown release by release. Before committing, export the full formula inventory of the model and check every function against the current Polaris documentation on help.anaplan.com.
- Zero is nothing. In Polaris a cell with no value is not stored. Formulas written to distinguish "zero" from "blank" by testing a number may behave differently; explicit Boolean flags are the safe pattern.
- Calculation patterns. Some operations that are cheap in Hyperblock (dense aggregations across the whole model) are relatively more expensive in Polaris, while the sparse lookups that hurt in Hyperblock become cheap. A model ported without redesign can be slower.
- Model structure simplifies. Many numbered-list combinations and the modules that maintain them can be removed, because the natural dimensions can be used directly.
- Tooling. Application Lifecycle Management, the New UX, Workflow, and the integration tools all work with Polaris models, but check specific features you rely on for engine support at the time you plan the work.
How to run a Polaris readiness assessment
We run this as a structured two-to-three-week exercise. You can run a light version yourself.
1. Profile the workload. For each large module, record the dimensions, the theoretical cell count, and the populated cell count. In Hyperblock you can approximate populated density by exporting the module and counting non-zero rows, or by adding a Boolean Is Populated line item with a SUM to a summary module. A table of modules sorted by cell count with a density column tells you most of what you need.
Module Dims Cells (M) Density
DEM01 Demand by SKU/Customer SKU x Cust x Region x Mo 4,500 2.1%
FIN02 P&L by Cost Center CC x Account x Month 12 87.0%
SAL03 Rep Capacity Rep x Month x Scenario 0.4 95.0%
A model where the biggest modules are under 10% dense is a Polaris candidate. A model where they are over 50% dense is not, whatever its size.
2. Inventory the functions. Export the model's formulas (the model map or a blueprint export) and list distinct functions used. Flag each as supported, supported with differences, or unsupported in Polaris.
3. Map the sparsity engineering. Identify every numbered list, subset, and line item subset that exists purely to avoid sparsity. These are candidates for removal in a Polaris rebuild, and their count is a rough estimate of how much simpler the target model can be.
4. Estimate the rebuild. Polaris migration is a rebuild with reconciliation, not a copy. Estimate by module count and complexity, then add a parallel-run period of at least two planning cycles.
5. Decide. Three honest outcomes: stay on Hyperblock and tune (the most common result for finance models); migrate to Polaris (the common result for supply chain, retail, and revenue models with large sparse intersections); or split, keeping the dense financial core on Hyperblock and moving the sparse operational model to Polaris with an integration between them.
A worked example
Consider a typical scenario: a consumer-goods company running demand planning for 12,000 SKUs across 800 customers in three Hyperblock models split by region, with a Data Hub feeding all three and a consolidation model on top. Density in the core demand module was under 3%. Every month-end involved reconciling the regional models to the consolidation.
On Polaris the three regional models became one, the numbered-list machinery (about 40 modules) was removed, and the consolidation model disappeared because the single model could simply summarize. The finance model stayed on Hyperblock, at 80% density, and receives a Data Orchestrator feed from the Polaris demand model. Total model-builder maintenance time fell by roughly half, and the month-end reconciliation step ceased to exist.
That outcome depends entirely on the profile. A dense FP&A model in the same company would get the opposite recommendation: stay on Hyperblock, fix the summary settings, and stop worrying about Polaris.
Next step
If you want help with the assessment, it is the first phase of our Performance Optimization and Platform Migrations and Modernization services. We will tell you if the answer is "stay."