For decades, Oracle Essbase and Oracle Cloud EPM have been used to solve complex multidimensional analytical problems. They contain some of an organization’s most valuable financial, planning, operational, and management data, along with the hierarchies and business logic that give that data meaning.
But what happens when you want to use that information somewhere else?
Maybe you want Essbase data in Snowflake. Maybe your Power BI or Tableau users need access to it. Maybe you want to combine financial data with operational data, analyze it with Python or Alteryx, or make it available to AI.
At first, the solution sounds simple:
Just get the data out of Essbase.
In practice, that’s where things get complicated.
Getting the Data Out Is Only the Beginning
An Essbase cube contains two things that are closely related but fundamentally different:
Stored data at the detailed, level-0 intersections of the cube.
And multidimensional logic that turns those detailed values into the aggregated and calculated information users actually consume.
If all you need is the stored data, you might assume a native level-0 export solves the problem.
For ASO Essbase and Oracle Cloud EPM applications, however, even the level-0 data isn’t delivered as a clean relational dataset ready to load into a database and query with SQL. Native exports use an Essbase-specific format that must first be interpreted and converted into something useful to a relational data platform.
So before a BI tool, data engineer, or SQL user can do anything with the data, another process has to turn that export into a usable relational structure.
And that’s just the level-0 data.
Level-0 Data Isn’t the Cube
Suppose your Essbase application contains detailed sales data by Scenario, Period, Product, Customer, and Entity.
A level-0 export might ultimately give you detailed intersections representing values such as:
Actual | Jan | Product A | Customer 100 | New York | $125,000
Once converted into relational form, that’s useful data.
But now someone asks:
What were Q1 sales for the Northeast?
The answer may not exist anywhere as a stored level-0 record.
Essbase derives that answer using the dimensional structure of the application. January, February, and March roll into Q1. Individual entities roll into Northeast. Other dimensions may have their own hierarchies and aggregation behavior.
And the problem becomes more pronounced when users ask for information involving:
- Parent-level aggregations
- Alternate hierarchies and rollups
- Shared members
- Dynamic member formulas
- Calculated members
- Ratios and percentages
- Time-based calculations
- Other business logic defined within the multidimensional model
An Essbase application is much more than a collection of stored data points.
The model is what gives the data meaning.
Exporting level-0 data gives you the ingredients. It doesn’t necessarily give you the answers.
“Just Query Essbase” Sounds Simple. At Scale, It Isn’t.
Of course, Essbase and Cloud EPM can return aggregated and calculated results. That’s one of the primary reasons organizations use them.
The challenge is what happens when those results need to become data for something else.
Retrieving a report-sized slice of a cube is very different from retrieving hundreds of thousands or millions of calculated and aggregated intersections for use by another analytical platform.
Large Essbase and Cloud EPM queries can become extremely slow. Depending on the environment and query, organizations can also encounter row-count constraints, query timeouts, or other practical limitations when attempting to retrieve very large result sets.
Making those extractions practical can require specialized knowledge of Essbase query behavior, extraction techniques, and performance tuning.
And after the query completes, you’re still not finished.
The results have to be extracted, transferred, transformed into an appropriate structure, loaded into the destination platform, and kept synchronized as the source application changes.
The problem isn’t that Essbase can’t calculate the answer.
The problem is efficiently turning those answers into data that the rest of your organization can use.
The Traditional Choices Aren’t Great
Organizations trying to make Essbase or Cloud EPM data broadly available typically face some variation of the same architectural choices.
You can export level-0 data and rebuild the required hierarchies, aggregations, and calculations downstream.
You can attempt to extract large volumes of aggregated and calculated results from Essbase and load those results into another system.
Or you can leave the multidimensional logic in Essbase and require downstream applications to continue querying it whenever they need an answer that can’t be derived easily from the extracted data.
Each approach introduces additional complexity.
And all three exist because the multidimensional engine and the relational data platform are separate systems.
What If the Cube Were Already in Snowflake?
This is where Casabase Cube changes the architecture.
Casabase Cube is a multidimensional OLAP engine built natively on Snowflake. Instead of maintaining the multidimensional model in one platform and continually figuring out how to move its data and results into another, Casabase Cube brings the multidimensional model directly to the data.
For organizations with existing Essbase or Oracle Cloud EPM applications, Casabase Cube migration utilities can use the existing outline and native level-0 export to recreate the multidimensional model and load its detailed data into Snowflake.
The result is fundamentally different from simply exporting an Essbase cube.
Your Level-0 Data Is Now Relational Data
Before considering a single aggregation or calculation, Casabase Cube provides immediate value: the detailed data from the cube is available directly in Snowflake in relational form.
There is no proprietary export format for downstream consumers to interpret.
There is no separate conversion process every time someone needs current data.
There is no requirement for a reporting application to understand Essbase simply to access the underlying facts.
The level-0 data can be queried with standard SQL and used alongside the rest of the organization’s Snowflake data.
Power BI can access it. Tableau can access it. Alteryx can access it. Python can access it. Other Snowflake workloads can join it to data that never existed in Essbase at all.
That alone solves a significant problem for organizations trying to make Essbase and Cloud EPM data part of a modern enterprise data platform.
But it still doesn’t solve the entire problem.
The Multidimensional Model Comes With It
Casabase Cube doesn’t stop at making the level-0 data relational.
It preserves the multidimensional model required to interpret that data, including hierarchies, alternate hierarchies, shared members, aggregations, member formulas, calculated members, and other multidimensional business logic.
When a user needs detailed data, it’s already available relationally.
When a user needs an aggregated or calculated result, Casabase Cube dynamically evaluates the multidimensional model against the data in Snowflake.
There is no need to pre-extract every possible parent-level value or calculated intersection simply to make it available outside Essbase.
And there is no separate OLAP server sitting between the data platform and the calculation engine.
The data and the engine used to interpret it are in the same platform.
The Same Answers, Without the Extraction Bottleneck
This architectural difference becomes particularly important when large volumes of aggregated or calculated information are required.
Casabase Cube is designed to calculate multidimensional results directly against Snowflake data at query time. In customer workloads, queries that previously required hours in Essbase or Oracle Cloud EPM have been returned in seconds through Casabase Cube.
The exact performance improvement will naturally depend on the application, dimensionality, calculations, query, and underlying data. But the architectural advantage is straightforward.
Instead of:
Essbase → Calculate → Extract → Transfer → Transform → Load → Consume
the calculation happens where the data is already being consumed:
Snowflake Data → Casabase Cube → Consume
There is no need to become an expert in specialized Essbase extraction techniques just to retrieve a large dataset.
There is no need to design a downstream architecture around the practical limitations of extracting large multidimensional result sets from another platform.
And there is no need to maintain another copy of every calculated result simply because another application needs to use it.
Stop Moving the Answers
For years, organizations have built increasingly sophisticated processes for moving Essbase data into relational platforms.
But perhaps the better question isn’t:
How can we get Essbase to export this faster?
It’s:
Why are we extracting these answers from a separate OLAP platform in the first place?
If the detailed data is already relational, and the multidimensional engine can dynamically reproduce the aggregations and calculations where that data lives, the extraction problem largely disappears.
That’s the architectural shift behind Casabase Cube.
You Don’t Have to Replace Essbase to Benefit
None of this requires an organization to immediately replace its existing Essbase or Cloud EPM applications.
Casabase Cube can initially solve a much more focused problem:
Make the information in those applications useful throughout the rest of the enterprise.
Existing Essbase and Cloud EPM applications can continue serving their current users while Casabase Cube makes their detailed data and multidimensional models available in Snowflake.
That creates an immediate path to better reporting, easier integration, broader data access, and new analytical use cases without requiring every downstream system to become an Essbase client.
And once the data, dimensional model, hierarchies, calculations, and aggregations are operating natively in Snowflake, another question naturally emerges:
What is the separate OLAP infrastructure still providing?
That’s a question organizations can answer on their own timeline.
Your Essbase Application Is More Than Its Data
The challenge of integrating Essbase with a modern data platform isn’t simply getting numbers from one system into another.
Even the detailed level-0 data may require conversion before it becomes useful relational data. And the aggregated and calculated information users depend on requires the multidimensional model that sits on top of those details.
Trying to solve those problems through increasingly sophisticated extraction processes treats the symptom rather than the architecture underneath it.
Casabase Cube takes a different approach.
Put the level-0 data in relational form. Put the multidimensional model alongside it. Perform the calculations where the data already lives.
The result isn’t simply an easier way to extract Essbase data.
It eliminates the need to extract multidimensional answers from Essbase in the first place.
Ready to See What Modern OLAP Looks Like?
Casabase Cube brings enterprise multidimensional analytics directly to Snowflake, without the infrastructure and complexity of a traditional OLAP platform.
Explore Casabase Cube to learn how you can modernize existing Oracle Essbase, Oracle Cloud EPM, or Microsoft Analysis Services applications or build new multidimensional analytical applications directly on Snowflake.