If you’ve ever seen how a financial dashboard takes minutes to aggregate data, or how a planning cube becomes unmanageable when you add one more dimension, the problem is almost always in the same decision: the storage type of your Essbase model. Oracle EPM—the platform that until recently many still called PBCS—offers three ways to store and compute data in a cube: BSO, ASO, and Hybrid. Choosing the wrong thing is not a minor technical detail: it conditions the closing speed, the simulation capacity and the maintenance cost of the model for years. In this article, we explain, judiciously and without unnecessary technicalities, how each option works, when to use it, and how that decision translates into real cases such as demand planning or production process simulation.
From PBCS to Oracle EPM: Why the Name Changes But Not the Engine
Many organizations are still looking for information about “PBCS” because that’s what Oracle’s cloud planning and budgeting service was called for years. It is worth clarifying this from the outset, because it affects how to interpret any ongoing documentation or project.
- PBCS (Planning and Budgeting Cloud Service) was the first generation of Oracle’s cloud planning service.
- Oracle has progressively unified its planning products under the name Planning, within Oracle Fusion Cloud Enterprise Performance Management (EPM).
- The computing engine behind it hasn’t changed in nature: it’s still Essbase, the multi-dimensional OLAP server that Oracle inherited from the Hyperion acquisition.
In other words: the commercial name evolves, but the question that any Systems, Finance or Data manager asks himself when designing a model has remained the same since 1992: BSO, ASO or, for a few years now, Hybrid?
Multidimensional databases: the logic behind the cubes
Oracle EPM does not work on relational tables, but on multidimensional databases organized in cubes. Each cube represents the business across dimensions—year, period, product, customer, geography, account, scenario—and allows you to analyze any combination of them without having to write complex queries.
When the dimensions are crossed to obtain a specific piece of data, that crossing materializes in what Essbase calls a block. The way those blocks are created, stored, and calculated is exactly what sets BSO, ASO, and Hybrid apart.
Do you want to know how to apply this strategy in your company? Talk to our Unikal EPM specialists and we will review the design of your current model together.
BSO, ASO and Hybrid: the three storage options on Essbase
1. BSO — Block Storage Option
BSO is the most common choice in financial planning applications and the default choice used by most legacy Hyperion Planning models. It allows you to load data at any level of the hierarchy and store it in physical blocks on disk.
- Supports complex calculations using Business Rules and calculation scripts.
- It is the natural choice for top-down budgets: for example, distribute an overall sales goal per customer and product based on a history.
- It offers more flexibility and better performance in one-time queries.
- Its performance degrades almost exponentially as the number of dimensions grows; It is not recommended to exceed 8-9 dense and scattered dimensions.
2. ASO — Aggregate Storage Option
ASO was designed to solve just the problem that limits BSO: the rapid aggregation of large volumes of information with high dimensionality.
- It supports many more dimensions and members than BSO without penalizing performance (it is common to see it with more than 10 dimensions or hierarchies of millions of customers or SKUs).
- Data is only loaded at level 0 and automatically aggregated using optimized dynamic views, not blocks.
- The aggregation time is much shorter than in BSO when the data volume is high.
- It does not support Business Rules or traditional complex calculations, although current versions allow certain formulas and mappings within the cube itself.
3. Hybrid — the best of both worlds, now mature
This is the part that most Spanish-language content on BSO and ASO does not tell, and that in 2026 is no longer an experimental novelty but the standard recommended by Oracle for new EPM Planning and Planning Modules applications.
Hybrid mode converts a BSO cube into a structure where the base level continues to function as BSO (with all its computational capabilities), while combinations of higher-level members in sparse dimensions are calculated dynamically, in memory, ASO-style. The result is a cube that retains BSO computing power without paying the performance cost of bulk aggregations.
- Reduce the size of the database and application.
- Significantly improves the performance of bucket refresh, loading and exporting data.
- It is enabled by default in any new application created on top of EPM Enterprise for several versions.
- It requires converting sparse dimension parent members to dynamic calculation instead of stored, which should be carefully planned if you are starting from a legacy application.
Comparison: BSO vs ASO vs Hybrid
| Feature | OST | ASO | Hybrid |
| Main objective | Complex calculations | Rapid aggregation of large volumes | Complex calculation + fast aggregation |
| Recommended dimensionality | Low (up to 8-9 dimensions) | High (10+ dimensions or million members) | High, with complex calculation logic |
| Data Load Level | Any level of the hierarchy | Level 0 only | Base level, with higher dynamic aggregation |
| Business Rules / Calculation Scripts | Yes | No (limited formulas and assignments only) | Yes, in the BSO part of the cube |
| Storage | Physical blocks on disk | Optimized dynamic views | Blocks at the base level + dispersed dynamic calculation |
| Performance with many dimensions | Degrades markedly | Very good | Very good |
| Availability | Standard since the origin of Essbase (1992) | Since 2004 | Enabled by default in EPM Enterprise since ~2020 |
How to choose the right model: decision checklist
Before setting the architecture of a new cube, it is worth answering these questions:
- Do you need to run complex business calculations (allocations, what-if simulations, currency, consolidation)? → OST or Hybrid.
- Are you going to work with more than 8-9 dimensions or millions of limb combinations? → ASO or Hybrid.
- Do you need to load data at intermediate levels of the hierarchy, not just at level 0? → OST or Hybrid.
- Is the current bottleneck the aggregation time and not the calculation itself? → ASO or Hybrid.
- Starting from a recent EPM Enterprise application with no legacy restrictions? → Get started right in Hybrid.
- Do an intensive calculation phase and another of analysis and mass reporting coexist in your process? → Combine BSO/Hybrid for calculation and ASO for analytical exploitation.
A common and effective practice in organizations with high dimensionality and simultaneous complex calculations is to use a BSO (or Hybrid) cube for the calculation of the top-down budget, with its simulation scenarios, and then dump the results at level 0 into an ASO cube to exploit the aggregated information at high speed. It’s exactly the approach we recommend when it takes hours for an app to consolidate its upper hierarchies.
From theory to operation: two cases where the choice of storage makes the difference
Storage design isn’t just a matter of IT architecture: it determines whether the business can plan demand with the agility it needs or whether it can simulate production scenarios in minutes instead of days.
Demand Planning: Why the Data Model Matters as Much as the Algorithm
A demand planning system helps anticipate purchasing patterns and avoid two symmetrical problems: stockouts and excess inventory. But that predictive ability depends on the underlying model being able to combine multiple dimensions—product, customer, channel, geography, time—without penalizing performance.
Direct benefits of a technically well-supported demand planning:
- Inventory optimization, adjusting levels to the actual forecast and not to fixed rules.
- Improved customer service, by having product available when needed.
- Reduction of storage, transport and obsolescence costs.
- Greater agility in the face of market or supply chain disruptions.
This is where the BSO/ASO/Hybrid discussion ceases to be theoretical: a demand model with many references, customers and locations needs the dimensionality of ASO or Hybrid to add fast, but it also needs calculation power to apply forecasting algorithms, seasonal adjustments and scenario simulations, BSO’s own terrain. Most mature implementations of Demand Planning in Oracle EPM combine both approaches depending on the stage of the process.
Find out how to design a technology strategy tailored to your business with the Unikal team. Let’s talk about your planning model.
Simulating Production Processes with Oracle BI and Essbase
Another scenario where correct storage is decisive is the simulation of production processes: understanding how a change in the cost of a raw material, in the manufacturing time or in the final price affects the margin, before that change occurs in reality.
The combination of Oracle Business Intelligence and Essbase enables just that:
- Connect non-relational data sources (Essbase) with the rest of the company’s operational information.
- Run predictive analytics and what-if simulations with secure write-back capability on the model.
- Build dashboards and dashboards that combine historical data with projections.
- Integrate planning, budgeting, and results tracking in a single analytical environment.
A BSO (or Hybrid) cube is essential here because simulation requires recalculating entire scenarios, not just consulting already aggregated data. A pure ASO falls short in this case; On the other hand, it is ideal for the subsequent reporting layer, where the relevant thing is to quickly consult large volumes already calculated.
Common mistakes when designing cubes in Oracle EPM
| Common mistake | Consequence | How to avoid it |
| Using OST with more than 10 dimensions “because it’s always been done that way” | Increasingly slow calculations and aggregations | Consider migrating to Hybrid or ASO in the design phase, not when it already hurts |
| Force everything to ASO for performance | Loss of complex computing power and Business Rules | Reserve ASO for aggregation and reporting, not for business calculation |
| Activate Hybrid without checking the sparse dimension parent members | Miscalculations or inconsistent results | Audit and adjust dynamic compute properties before migrating |
| Not documenting why one model or another was chosen | Decisions that are repeated without criteria in new projects | Write down the design criteria and review it with each relevant enlargement |
In summary
BSO, ASO and Hybrid are not three interchangeable alternatives: they are three responses to different needs within the same engine, Essbase, which is still the heart of Oracle EPM even though the commercial name has changed from PBCS to Planning. The practical recommendation is simple to enunciate and demanding to execute: use BSO or Hybrid where the business needs to calculate —budgets, simulations, forecasting—, and ASO where it needs to quickly consult large volumes already added. Most mature models, whether in demand planning, production process simulation or any other EPM process, do not choose one or the other: they combine them judiciously according to the process phase. That’s the difference between a model that scales with the business and one that needs to be redesigned every two years.
Before we touch on setting up your next app, it’s worth sitting down with someone who’s seen all three of these models fail and work in production, not just documentation.
BSO, ASO, and Hybrid FAQs in Oracle EPM
What is the difference between BSO and ASO in Essbase? BSO (Block Storage Option) stores data in physical blocks and allows information to be loaded at any level of the hierarchy, making it ideal for complex calculations such as budgets, allocations, or simulations. ASO (Aggregate Storage Option) only loads data at level 0 and automatically aggregates it using dynamic views, allowing it to handle many more dimensions and millions of members without losing performance, but without supporting Business Rules or traditional complex calculations. The choice depends on whether your priority is to calculate or add quickly.
What is Hybrid Mode in Oracle EPM? It is a configuration of BSO cubes that combines their computational power with ASO’s own dynamic aggregation. The base level of the cube works like a traditional BSO, while the upper levels of the sparse dimensions are calculated in memory at query time. It is enabled by default in new EPM Enterprise applications and is the option recommended by Oracle who does not start from legacy restrictions.
Are PBCS and Oracle EPM Planning the same? Yes. PBCS (Planning and Budgeting Cloud Service) was the original name of Oracle’s cloud planning service. Oracle has unified its portfolio under the Planning brand within Oracle Fusion Cloud Enterprise Performance Management. The calculation engine, Essbase, and the concepts of BSO, ASO and Hybrid have not changed; What changes is the commercial name and the way in which the product is packaged.
How many dimensions can a BSO cube withstand before losing performance? There is no hard technical limit, but common practice advises against exceeding the 8-9 dense and scattered dimensions combined in a traditional BSO cube. From there, disk space and calculation time grow almost exponentially. If your model needs more dimensionality, the recommended alternative is to evaluate ASO for the aggregation layer or activate the Hybrid mode, which supports high dimensionality without completely sacrificing computational capacity.
Can I convert an existing BSO application to Hybrid? Yes, although it is not an automatic or reversible process without restoring a previous copy. It requires reviewing and adjusting the calculation properties of parent members in sparse dimensions, checking the Essbase version of your environment, and in some cases, converting the application to an Enterprise format first. It is recommended that you back up (LCM) and validate the behavior in a test environment before activating Hybrid in production.
Which storage model is right for demand planning? It depends on the phase of the process. For forecast calculation, seasonal adjustments, and scenario simulations, BSO or Hybrid offers the necessary calculation capability. For aggregating and querying large volumes of SKUs, customers, or locations once calculated, ASO offers better performance. Most mature implantations combine both approaches rather than forcing the entire process onto a single type of bucket.
Is Essbase still relevant in 2026 or has Oracle replaced it? Essbase continues to be the multi-dimensional compute engine that underpins Oracle EPM, including Planning, Financial Consolidation and Close, and many of the specialized planning modules. What has evolved is how it is used: the Hybrid mode, consolidated in recent years, has reduced much of the historical limitations between BSO and ASO, and Oracle continues to incorporate performance improvements in each quarterly update of the cloud service.
Can I combine Essbase with external business intelligence tools? Yes. It is common practice to connect Essbase, through its various storage models, with Business Intelligence tools to build dashboards, run what-if simulations, and combine financial data with operational information from other sources. This integration is especially valuable in production process analytics, where cost, manufacturing time, and quality data needs to be cross-referenced to make informed decisions.