ASO — Aggregate Storage Option — is one of the two Essbase storage engines, designed for large, sparse data sets where the primary use case is high-performance aggregation and querying rather than interactive data input or complex calculation. ASO stores data in a compressed structure that does not organise data into blocks (as BSO does); instead, it stores only the cells that contain values and aggregates parent values dynamically at query time using pre-computed aggregate views — materialisations of frequently queried combinations that Essbase creates and maintains automatically.
ASO vs BSO Capability Comparison
| Capability | ASO | BSO |
|---|---|---|
| Write-back (data input) | No — read-only after load | Yes |
| Stored member formulas | No — dynamic calc only | Yes |
| Calc Script operations | Limited — aggregation-focused MDX | Full Calc Script support |
| Large member counts | Handles millions of members efficiently | Performance degrades above tens of thousands |
| Query-time aggregation | Native — pre-computed aggregate views | Requires explicit calculation first |
| Very sparse data sets | Efficient — stores only populated cells | Performance degrades for very sparse blocks |
| Typical EPM use | Reporting cubes; management dashboards | Input cubes; allocations; complex calculations |
Design Considerations
ASO cubes are populated from BSO cubes or external data sources through data pushes — and until the push is executed, the ASO cube reflects the data state at the time of the last push. The push frequency is the effective data currency for the ASO cube and must be designed to meet the reporting consumers’ needs.
Aggregate view creation is controlled through the ASO cube’s aggregate storage settings. When Oracle’s automatic aggregation is insufficient for query performance, custom aggregate views can be defined for specific dimension combinations that are queried frequently. Adding too many aggregate views increases the maintenance overhead and disk usage; the set of aggregate views should be driven by actual query patterns, not speculative optimisation.
What Goes Wrong in Practice
The specific failure unique to ASO deployments is enabling data input directly to an ASO cube for scenarios that require interactive planning input. Some EPM implementations attempt to use ASO for both storage and input — because ASO handles large member counts efficiently — and discover that data loaded into ASO cannot be written back through Smart View or Planning forms in the expected way. Users submit data through a form that appears to accept input, but the data is not persisted to the ASO structure correctly. The correct architecture for environments requiring both large member counts and interactive input is a BSO input cube with an ASO reporting cube fed by a data push, not a single ASO cube attempting to serve both functions.
How Loop Wise Solutions Handles This
In every EPM application design engagement, we produce an explicit BSO/ASO architecture decision document that specifies which cubes are BSO and which are ASO, with the rationale for each choice and the data flow between them. We do not allow the storage type decision to be deferred — it is a foundational architecture choice that determines the application’s behaviour, and reversing it after the application is built requires a full rebuild.
Answers before you ask.
Large member counts and high-performance aggregation at query time. ASO computes aggregations on the fly efficiently across very sparse, high-dimensional data, which makes it well suited to reporting cubes with many members where fast retrieval matters more than complex stored calculation.
ASO does not support write-back through standard Calc Script, does not store BSO-style member formulas, and uses MDX rather than the BSO calculation language. It is built for aggregation and query, not for the procedural, calculation-heavy, write-back workloads that BSO handles. Choosing ASO where those are required yields an application that cannot do its job.
For reporting and analysis cubes with very large dimensionality and member counts, where users query aggregated data and do not need to write back or run heavy stored calculations. A common pattern pairs an ASO reporting cube with a BSO input cube, moving data between them so each plays to its strength.
Because if the cube needs write-back, stored member-formula calculation, or full Calc Script logic, ASO simply does not provide them. The application will be unable to accept planning input or run the required calculations. Storage type must follow the cube's functional role — reporting versus input and calculation — not be chosen arbitrarily.