At the recent Kscope26 conference, Oracle showed the next generation of Essbase in several different sessions. I came away from the conference more excited about the future of Essbase than I have been in a long time.
For several years, I have heard people suggest that Essbase is dead or that Oracle is no longer investing in it. Based on what Oracle showed at Kscope26, that does not appear to be the case.
Essbase remains very important under the covers of a number of Oracle applications. Oracle Cloud EPM is the most obvious example, but Essbase technology is also used throughout Oracle’s application portfolio. Many of the improvements Oracle has made to Essbase over the past several years have probably been driven by the requirements of those applications, even though standalone Essbase customers may not have seen much promotion or discussion of that work.
Now, Oracle appears to be preparing to make Essbase much more visible.
The most significant development is the increasingly close relationship between Essbase and Oracle Autonomous AI Lakehouse. When that relationship is combined with federated cubes, AI-assisted cube creation, natural-language queries, the Essbase MCP server, and Oracle’s growing multicloud strategy, I think it could represent a major new chapter for Essbase.
Let’s look at what Oracle is doing and why it matters.
Oracle Autonomous AI Lakehouse
Over the past year, Oracle has been positioning Autonomous AI Lakehouse as a foundation for enterprise data, analytics, and artificial intelligence.
This is not simply another place to store data. It serves:
- Relational data
- Data lake storage based on Apache Iceberg
- Vector data for retrieval-augmented generation
- AI inference
- SQL analytics
- Machine learning
- Governance and security
- Integration across OCI, Microsoft Azure, AWS, and Google Cloud
The key idea is that AI and analytics should operate where the enterprise data already lives.
Instead of continually moving information into separate AI platforms, Oracle wants organizations to apply AI, analytics, machine learning, vector search, and natural-language access directly to governed enterprise data.
That can include relational information stored in Oracle, data stored in Apache Iceberg tables, and information managed across other cloud and lakehouse platforms, including Snowflake and Databricks.
This is important because companies do not want to create another uncontrolled copy of their most sensitive financial and operational data simply so an AI assistant can use it. They want AI to work with current information while continuing to respect enterprise security, access controls, governance, and data-management policies.
Essbase is clearly becoming part of this broader vision.
Essbase can provide a dimensional business model over information managed in Autonomous AI Lakehouse. Essbase provides the dimensions, hierarchies, calculations, and familiar analytical interfaces, while the detailed data can remain in the lakehouse.
That represents a significant architectural shift.
To be clear, Oracle has not formally announced that Essbase itself will become a native database engine inside Autonomous AI Lakehouse. However, the direction is becoming much clearer, and Oracle has been talking about this concept for over a year. Further, they showed some very impressive demos at Kscope26. My expectation is that this innovation will be announced very soon.
Making Essbase More Available
For quite some time, Oracle has made Essbase available through the Oracle Cloud Infrastructure Marketplace, or OCI Marketplace. Although the Marketplace deployment works well, Oracle has not promoted standalone Essbase very heavily.
Unless you were already an Essbase customer or specifically looking for the product, you might not even know it was available.
Oracle’s work to connect Essbase more closely with Autonomous AI Lakehouse could change that.
Traditionally, customers have thought of Essbase as a separate analytical server. An Essbase environment includes applications, outlines, calculation scripts, rule files, data files, security definitions, and other supporting components. The server must be provisioned, configured, patched, monitored, and maintained separately from the source database.
The architecture Oracle demonstrated appears to bring Essbase much closer to the Oracle Database and lakehouse platform.
As we understand it, the Essbase application components will all be stored in the database, while Essbase uses Autonomous AI Lakehouse as its storage and processing platform. This could simplify the architecture considerably and make Essbase easier for Oracle Database customers and developers to discover.
Oracle has followed an interesting accessibility strategy for years with Oracle Application Express, or APEX. APEX is a web-based application development environment that runs on top of Oracle Database. It allows developers to build browser-based applications directly against information stored in the database without requiring an entirely separate application-development stack.
APEX has become extremely popular. In fact, a significant portion of the Kscope community and conference content is now dedicated to APEX.
Could making Essbase more readily accessible with Oracle Database create a similar opportunity?
Oracle Database has an enormous installed base. An estimated 400,000 companies may use Oracle Database worldwide. If even a small percentage of those companies are introduced to Essbase through Autonomous AI Lakehouse, it could bring multidimensional analysis to a very large group of database developers, data engineers, and business analysts who may never have considered deploying a traditional Essbase server.
I think that could be a very significant development.
Federated Cubes Change the Architecture
The clearest example of the relationship between Essbase and Autonomous AI Lakehouse is the federated cube.
Most traditional Essbase applications require a data-loading process.
Typically, data is extracted from a relational database or another source system, transformed into the format needed by Essbase, and then loaded into the cube. Depending on the application, that process may run monthly, nightly, hourly, or perhaps every few minutes.
No matter how frequently it runs, there is usually some delay between the time a transaction is recorded in the source system and the time it becomes available in Essbase.
There is also a substantial amount of infrastructure associated with the process. Someone must create and maintain the extracts, transformation rules, load rules, scheduling, error handling, reconciliation, and operational monitoring.
Federated cubes provide a different approach.
With a federated cube, Essbase can query detailed data stored in Autonomous AI Lakehouse directly. The data does not have to be copied into the traditional Essbase storage engine before users can query or aggregate it.
The Essbase outline continues to contain the dimensional metadata, including dimensions, member names, hierarchies, and formulas. The corresponding detailed information remains in a fact table within Autonomous AI Lakehouse.
In other words, Essbase provides the business-oriented multidimensional model while Autonomous AI Lakehouse stores and processes the underlying data.
This is a significant architectural shift because, historically, data generally had to be loaded into an Essbase cube.
With a federated cube, the detailed data can remain in the lakehouse.
Essbase Calculations Still Matter
One of the important points about federated cubes is that customers do not have to give up the analytical features that make Essbase valuable.
Organizations can still define dimensions, hierarchies, member formulas, calculations, and business logic in Essbase.
When calculations and queries are executed, Essbase can analyze the request and, whenever possible, translate the required work into SQL. That processing can then be pushed into Autonomous AI Lakehouse so the computation occurs close to the data.
Not every Essbase operation will necessarily be pushed into the database. Some calculations may still be processed by Essbase.
However, the general principle is important: perform the work where it makes the most sense.
Essbase continues to manage the multidimensional model and business logic. Autonomous AI Lakehouse manages the detailed data and performs SQL-based processing whenever possible.
This can improve scalability and reduce data latency because detailed information does not have to be copied into Essbase before it can be analyzed.
Live Data Without Traditional ETL
Think about what this means operationally.
If someone adds or updates information in the underlying lakehouse fact table, the updated information can become available to the Essbase application without waiting for the next traditional export-and-load cycle.
Organizations could potentially build real-time or near-real-time analytical applications without developing and maintaining the same type of data pipeline required by a conventional Essbase cube.
There is no need to create another complete copy of the detailed data merely so Essbase can query it.
This can reduce the cost and complexity surrounding ETL. It may also eliminate some of the reconciliation problems that occur when the source system and the analytical cube contain different versions of the data.
Writeback can also be supported. Information submitted through an Essbase interface can be written to stored intersections in the lakehouse fact table, while Essbase calculations and data-loading operations can generate updates to the underlying table.
That makes the relationship bidirectional rather than limiting it to read-only reporting.
Of course, real-time access does not eliminate the need for good design. Organizations still need appropriate dimensional models, governance, security, calculation logic, performance planning, and controls over writeback.
However, reducing or eliminating the traditional data-loading process could remove a substantial amount of technical complexity.
Essbase Gets a Broader Reach
The broader Autonomous AI Lakehouse strategy makes this even more interesting.
Autonomous AI Lakehouse supports Apache Iceberg and is designed to work with information stored across other data platforms and cloud environments. Oracle can connect to data and metadata associated with platforms such as Databricks, Snowflake, AWS, and other lakehouse environments.
Oracle can then apply capabilities such as SQL analytics, machine learning, AI Vector Search, graph analytics, spatial analytics, and natural-language querying to that information.
Now combine those capabilities with Essbase.
It may become possible to provide an Essbase dimensional model over a much broader collection of enterprise information.
For example, financial information may be stored in Oracle while operational data resides in Databricks, Snowflake, or an Iceberg-based data lake. Essbase could provide a common analytical model over that information.
Users would continue to think in terms of accounts, entities, products, customers, scenarios, periods, and organizational hierarchies. They would not need to think about physical files, database tables, object-storage locations, joins, or cloud-provider boundaries.
That is one of the things Essbase has always done extremely well. Essbase organizes information in the way business users think.
Autonomous AI Lakehouse can provide access to distributed enterprise data. Essbase can provide the dimensional business model, calculations, and interactive analytical experience over that information.
I think that combination could be extremely powerful.
AI Where the Data Lives
There is also an important AI implication.
A central part of Oracle’s positioning is that AI should operate where governed enterprise data already resides.
Autonomous AI Lakehouse includes capabilities for vector search, retrieval-augmented generation, in-database machine learning, natural-language SQL, and agentic workflows. These capabilities can operate against enterprise data while remaining subject to security, access controls, and governance.
This helps address one of the biggest challenges companies face with enterprise AI.
Companies do not want to move all of their sensitive financial and operational information into a separate environment simply so an AI system can use it. They also do not want an AI assistant to bypass the organization’s existing security and governance policies.
Running AI close to the data can reduce unnecessary data movement, preserve existing controls, and give the AI access to current enterprise information.
Essbase adds another important layer to that architecture.
The detailed data may reside in relational tables or Iceberg storage, but the business meaning of that data is often expressed through the Essbase model.
The Essbase outline tells us which members belong to which dimensions, how entities roll up into regions, how accounts are categorized, which calculations define important business metrics, and how users are permitted to access the information.
In that sense, Essbase does more than provide another query engine.
It provides a business-oriented semantic model.
That may become one of the most important roles Essbase plays in Oracle’s enterprise AI strategy.
Using AI to Build Essbase Cubes
Oracle demonstrated AI-assisted Essbase cube creation at Kscope26.
Building a good Essbase application has always required a combination of technical skill and business knowledge. The developer must understand the source data, identify the fact tables and measures, determine the dimensions, build the hierarchies, and decide how the application should aggregate and calculate information.
Oracle showed AI technology that can analyze database tables and recommend a potential Essbase cube structure.
For example, the AI can identify a table that appears to contain measures such as revenue, units, cost, or margin. It can then identify the keys that relate those measures to customers, products, entities, periods, or other potential dimensions.
Based on those relationships, the AI can recommend dimensions and hierarchies and then help create the Essbase application.
The AI is essentially looking at a relational star schema and recommending how it could be represented as a multidimensional Essbase model.
I do not think this eliminates the need for an experienced Essbase developer. The technology may be able to identify relationships in the data, but it does not necessarily understand every business rule or know how management wants to analyze the company.
There are often several technically valid ways to organize the same information. Determining the best design still requires someone who understands the business.
However, AI-assisted cube creation could give developers a very good starting point. Instead of creating every dimension and hierarchy manually, a developer could begin with the AI-generated model and refine it.
It could also make Essbase more approachable to Oracle Database developers who have never built a multidimensional application.
From Relational Tables to a Working Cube
The AI cube builder becomes even more interesting when paired with federated cubes.
In a traditional project, AI might identify the fact table and dimensions, but someone would still need to build a process to export the data and load it into Essbase.
With a federated architecture, the source data is already available to the Essbase application.
The AI can identify the tables, recommend a cube, create the dimensional structure, and connect that structure to data that remains in Autonomous AI Lakehouse.
The entire process could become dramatically faster.
A developer could potentially move from a collection of relational tables to a working Essbase analytical application without building a traditional ETL process and without maintaining a second copy of all the detailed data.
That could change the economics of creating Essbase applications.
Applications that once required a major implementation project may become practical for smaller departments, shorter-term projects, or specialized analytical requirements.
Natural-Language Queries
Another interesting capability is the ability to ask Essbase questions using natural language.
Instead of requiring the user to know MDX or manually construct a report, the user can describe the information they want in ordinary language.
For example, a user might ask:
“Show revenue and gross margin by region for the current quarter compared with last year.”
Essbase can interpret the request, determine the relevant dimensions and members, generate the appropriate query, and return an Essbase grid.
The user can then work with the result just as they would any other Essbase report. The grid can be pivoted, drilled into, recalculated, or opened in another interface for additional analysis.
Depending on the interface, the question could be typed or spoken.
The fact that Essbase returns a grid is important.
Many AI tools return a paragraph describing what they believe the answer to be. That can be useful, but financial and operational users often need to see the actual numbers arranged in a structured report. An Essbase grid gives the user something that can be reviewed, drilled into, recalculated, and validated.
It is not simply an AI-generated narrative. It is an interactive analytical result.
The Essbase MCP Server
The Essbase MCP server may be one of the most interesting new capabilities of all.
MCP stands for Model Context Protocol. You can think of MCP as a standardized middle tier between an AI assistant and an enterprise system.
The AI assistant does not need unrestricted access to the underlying database. Instead, the MCP server exposes specific tools and operations that the assistant is permitted to use.
In the case of Essbase, those tools might include listing applications, examining an outline, finding members, running queries, retrieving data, executing calculations, or performing other approved operations.
The MCP server also respects security and limits what a particular user or AI assistant is allowed to do. What makes this especially interesting is that an MCP server enables companies use their chosen AI platform. A company standardized on Microsoft Copilot might connect Copilot to the Essbase MCP server. Another company might use ChatGPT or a different MCP-compatible AI platform.
The intelligence does not necessarily have to come from an Oracle-specific AI interface. The company can use the AI technology it has already selected while using Essbase as the governed analytical source.
Consider an example.
Suppose a regional cost-of-goods-sold number is significantly over budget. A financial executive might ask:
“Which entities contributed the most to the unfavorable cost-of-goods-sold variance in the Southeast region?”
The AI assistant could use the Essbase MCP server to examine the outline, identify the appropriate region, find the entities beneath it, retrieve actual and budget data, calculate the variances, and return the entities that contributed most to the result.
The user does not need to know the exact member names or how to write the query.
The AI assistant can formulate the query, but the numbers still come from Essbase. The existing dimensions, hierarchies, calculations, and security rules continue to apply.
That is a much better model than simply asking a general-purpose AI tool to guess at the answer.
Why This Is Important for Dodeca
These developments also strengthen the position of Dodeca.
Oracle is making it easier for AI systems to discover, query, and analyze enterprise data. That is important, but discovering data is only part of the problem.
Organizations also need a trusted way to present the information, apply business context, enforce workflow, validate results, and deliver reports that people can confidently use to make decisions.
That is where Dodeca is different.
Dodeca provides curated and governed reports, business context, enterprise security, and trusted spreadsheet-based analysis. It gives organizations a controlled environment for delivering the reports and applications that finance and operational users depend on every day.
As AI becomes better at asking questions and finding information, companies will increasingly ask a different question:
“How do I know this result is correct?”
Dodeca is well positioned to answer that question.
The opportunity is not for Dodeca to compete with Oracle’s AI capabilities. It is to complement them. Check out: Don’t Just add AI, Add Confidence
An AI assistant may be able to identify an interesting variance or discover a pattern in the data. Dodeca can provide the governed report that places the result in context, shows the supporting detail, applies the organization’s calculations and presentation standards, and gives the user a trusted analytical experience.
Further, the upcoming Dodeca MCP server will an AI assistant to identify the appropriate Dodeca report, open it, retrieve the governed result, and use that report as evidence supporting the AI-generated answer.
Instead of the AI saying:
“I believe this is the answer.”
It could say:
“Here is the answer, and here is the governed Dodeca report that supports it.”
That is an important distinction.
Many organizations have invested heavily in enterprise systems intended to eliminate uncontrolled spreadsheets. Yet business users continue returning to spreadsheets because they are familiar, flexible, and effective for financial analysis.
The problem is not the spreadsheet interface itself. The problem is uncontrolled spreadsheets, inconsistent formulas, disconnected data, and a lack of governance. Dodeca preserves the familiar spreadsheet experience while placing it inside a controlled enterprise platform.
In that sense, the Dodeca opportunity becomes even more interesting when we return to the APEX comparison. APEX provides a web-based application development interface on top of Oracle Database. It helps developers turn database information into governed browser-based applications.
Over the years, numerous people inside Oracle have referred to Dodeca as “APEX for Essbase.” I think that comparison is increasingly appropriate.
Dodeca provides an application-building and delivery platform on top of Essbase and other enterprise data sources. It allows organizations to create sophisticated spreadsheet applications, guided analytical workflows, reports, planning solutions, and operational processes without handing users an uncontrolled collection of Excel files.
Just as APEX helps developers build applications on top of Oracle Database, Dodeca helps organizations build governed business applications on top of Essbase.
However, Dodeca goes beyond simply displaying data.
It brings together Essbase, relational data, calculations, security, commentary, auditability, and familiar spreadsheet presentation in a single application environment.
As Oracle expands Essbase through Autonomous AI Lakehouse and introduces it to a broader population of database and AI developers, Dodeca can provide the application layer that turns those multidimensional models into trusted, business-ready solutions.
Oracle can make the data and analytical engine more accessible.
Dodeca can make the resulting information usable, governed, and actionable.
That is a highly complementary message, and I believe it creates a significant opportunity for both Essbase and Dodeca.
Oracle’s Multicloud Strategy
There is one more important piece to this story.
Oracle Autonomous AI Lakehouse is part of a broader multicloud strategy.
Oracle is making its database services and related technologies available in conjunction with OCI, Microsoft Azure, AWS, and Google Cloud.
This is important because most large companies already operate in more than one cloud.
A company may use Azure for application services, AWS for a data lake, Google Cloud for AI, and Oracle for financial and operational databases. Requiring the company to move everything to a single cloud is usually not realistic.
Oracle’s multicloud strategy recognizes that reality.
Autonomous AI Lakehouse is intended to bring analytics and AI to the data, regardless of whether the information is associated with OCI, Azure, AWS, Google Cloud, an on-premises environment, or another lakehouse platform.
This makes the opportunity for Essbase even larger.
Essbase would not be limited to customers building exclusively on OCI. It could participate in modern analytical architectures that span multiple clouds, catalogs, storage systems, and data platforms.
Is Essbase Back?
I am not sure Essbase ever really went away.
It continued to serve as an important analytical engine inside Oracle applications, and thousands of companies continued to rely on standalone Essbase for mission-critical reporting, analysis, and planning.
What changed was its visibility.
For several years, Oracle did not talk very much about standalone Essbase. There was not a large marketing campaign, and it was sometimes difficult to tell where the product fit into Oracle’s broader database, cloud, and AI strategy.
Based on what Oracle showed at Kscope26, that picture is becoming much clearer.
Oracle is positioning Autonomous AI Lakehouse as an open and governed foundation for enterprise analytics and artificial intelligence.
Essbase can provide a multidimensional business and semantic model over the information in that platform.
Federated cubes allow detailed data to remain in Autonomous AI Lakehouse rather than requiring traditional Essbase data loads. Calculations and queries can be translated into SQL and pushed into the lakehouse whenever possible. AI can help design the cube. Natural-language interfaces can make the information easier to query. MCP can make governed Essbase capabilities available to enterprise AI assistants.
Dodeca can then provide the governed application and reporting layer that turns those capabilities into trusted business solutions.
Taken together, these developments place Essbase in a much broader data and AI architecture than it has occupied in the past.
I think Oracle is positioning Essbase to become an important multidimensional analytical and semantic layer for its modern data and AI platform.
That is a very exciting direction.
Of course, some of the functionality demonstrated at conferences may still be under development. Product names, features, licensing, architecture, and release dates may change before everything becomes generally available.
Oracle has not announced that Essbase itself is becoming a native engine inside Autonomous AI Lakehouse.
However, the current federated-cube architecture and the capabilities Oracle demonstrated at Kscope26 show that Essbase is becoming increasingly connected to Oracle’s lakehouse and enterprise AI strategy.
The direction seems clear.
Essbase is not dead.
In fact, I think we may be seeing the beginning of an Essbase renaissance.
As someone who has worked with Essbase for many years, I am absolutely thrilled to see it.
Related Article: Don’t Just add AI, Add Confidence
Related Video: Dodeca: Adding Value to AI
