The choice between OLAP and ROLAP database architectures represents a fundamental decision that impacts any finance team’s ability to own their data, adapt to change, and scale efficiently. While OLAP cubes were the standard in the 1990s and 2000s, ROLAP represents a modern technology eliminating the severe limitations of an OLAP-based FP&A platform.
OLAP cubes: Built for a different era
OLAP – or Online Analytical Processing – was compelling in 1993 when it was first codified by E.F. Codd, a former research scientist at IBM, at a time when on-premises software was in its ascendancy. OLAP was designed when technology and the bandwidth weren’t sufficient to run big data sets on relational databases.
Cube-based systems, such as Vena and Cube Software, allow a fixed number of dimensions – typically eight to 12 dimensions (for instance time, geography, products).
Finance teams running on such OLAP-based systems face at least four insurmountable challenges: rigidity, limited data, lack of scalability and curtailed capacity to work with AI engines such as Claude, ChatGPT, and Microsoft Copilot. This is in stark contrast to the multi-dimensional and infinitely flexible and scalable approach of modern FP&A platforms using ROLAP (or Relational Online Analytical Processing) architecture.
ROLAP: Modern, flexible architecture
In opposition to the rigid hierarchy of cubes, ROLAP-based FP&A solutions use a relational database creating a semantic layer that presents it as multidimensional. ROLAP is basically columns and rows, using the same architecture as modern data warehouses like Snowflake and Redshift. Major analytics platforms such as Oracle and Microsoft Power BI shifted toward relational or tabular architectures as they provide greater flexibility and scalability, easy model changes and removes dependency on heavy and costly IT maintenance and consultant fees. Since a ROLAP database is relational (rather than rigid) finance leaders don’t have to assign dimensions and fields like in a legacy cube-based system.
Key advantages of ROLAP over OLAP
1. Unlimited dimensions vs being trapped in a Cube
The favored option for strategic finance teams is unlimited dimensionality with ROLAP or relational databases. With relational databases, you can add fields, and join new tables on the fly. Datarails lets you use Excel’s natural flexibility.
By contrast, because OLAP cubes require data to be pre-aggregated into a dimensionality that will be used for ongoing analysis and reporting. When those hierarchies change, they cannot be easily updated without affecting the entire cube.
Brian Spitler, a former senior finance manager at Steinway & Sons discusses the limitations when he used a typical legacy OLAP FP&A solution, Planful, at the iconic piano maker:
“We had brand, SKUs and product level details. But another way we would have liked to classify things for the purposes of reporting were black pianos versus white pianos. Using Planful we couldn’t create that additional classification to say we want to see everything broken out between like black white and other, for instance. That was where we had to manually pull all the SKU data, organize it ourselves and then put it into a report. Whereas with a relational database, you could set up an additional field and come up with an organization of all your SKUs and classify them providing a new column of data, then analyze. There’s nothing inherently wrong with a cube structure. But if you want to do something differently than the way you initially set it up then it becomes much more difficult. You might have to restructure the data in order to get that output and restructuring the data isn’t a 20 minute exercise; it becomes another implementation.”
Consider a manufacturer that launches a limited product run in Mexico in Q2 only. To report on this, Mexico needs to be added as a distinct region in the OLAP cube. This means storage will be allocated for Mexico across every quarter — even though there will only ever be data in Q2.
Adding this extra storage impacts processing times whenever the cube is accessed or updated, so it makes sense to minimise it where possible. In this case, Mexico may be merged with the United States to form a single North America dimension, reducing the storage allocation required.
The issue is that the following year, when leadership wants to assess whether to expand the Mexico product line, there is no way to distinguish between revenue in the United States and revenue in Mexico. The data no longer exists separately — permanently missing an opportunity to invest further in the Mexico market.
A VP Finance at a property and residential services spoke to our team about their frustration using Vena’s OLAP-based software:
“We have transactions that happen at the platform level, and then get allocated down. And then we have expenses that happen at the individual brand level. And sometimes when we need to ask where is this expense? I’ve got to go through five different entities and the whole code to go find where it is. And that’s a pain in the butt. If I needed to find detail on something or if I needed something changed in a template it was a big lift to get it done. That part for me was the most unworkable”.
By and large, paid consultants have to add in the new dimension of the cube and recalculate the entire hierarchy. They do the work of updating all of the outputs with that new dimension. By contrast, with ROLAP if you want to add a dimension, you map it in. And you want to add it to a report, it is simple. If you want to add it as a filter, you can add it as a filter. There is no need to go to any type of third-party support. You can do it in two seconds.
Choosing a ROLAP-based solution such as Datarails, which has unlimited dimensionality for when circumstances change, is very different from these rigid Cube-based systems. For these tools further dimensions require separate cubes. That equals more consultant fees and a further time suck. Tripp Wright, a financial analyst at SG, a managed service provider, talking about moving from OLAP-based Vena to ROLAP-based Datarails says:
““We originally started with Vena last year, and that did not go well.”
2. OLAP: Scalability is not included
A major frustration for finance teams opting for an OLAP-based solution is lack of scalability – in the case of SG technologies they struggled under an OLAP-based platform to manage variable compensation for 75 employees across 21 different plans.
Moreover, OLAP-based systems struggle to connect with lots of different data sources. By contrast, ROLAP-based finance operating systems allow seamless integration with any data tech stacks: Datarails, for instance, integrates with more than 600 sources of data – from Hubspot, to Xero, to MRI Software, Yardi, and everything in between.
3. “The OLAP Slap”: Meet your consultant…
The hidden cost of consultant heavy-fixing with cube-based solutions has earned the term, the “OLAP Slap”. Once signed, finance teams join a pooled customer service model requiring consultant fees. The head of FP&A at a VC who replaced OLAP-solution, Planful, confirmed:
“I found that piece very hard to own, because it’s very proprietary and you essentially need a consulting package with them to maintain that.”
As one Reddit FP&A commenter noted about another OLAP-based solution:
“It’s not simple to build additional models that flow through effectively without coaching. So expect to pay for these additional hours as they will most certainly be required Any core changes you want performed on the files will again be required to have a Vena specialist do this in fear that you will break the entire system.”
Consulting isn’t a bug, but a feature of OLAP or cube-based system. Getting the cubes to talk to each other requires MDX – a coding query language for online analytical processing (OLAP) requiring maintenance or consultation.
A large construction company explained they face endless frustration from Vena’s high fees because of this in-built design. Their CFO explains:
“We are a pretty fast-moving business and as things change we need flexibility which we could not get with Vena. We had to pay Citrin Cooperman [a Vena consultant], who Vena set us up with $15,000 to make changes. We are going to do a pretty decent amount of M&A over the next year or two and we are going to be evolving. So having a system that reflects that is important to us.”
By contrast, Datarails provides a named CSM with an FP&A background and enables self-service. With Datarails, you own that process and can make changes instantly. This enables some of the fastest growing companies in the world to scale at speed with Datarails.
4. The finance challenges of stale OLAP data
OLAP data is old since cube-based implementations process on a nightly schedule, meaning finance teams are routinely making decisions on yesterday’s figures. Delays are especially felt for time-sensitive processes such as cash management, revenue forecasting or expense monitoring. At the same time processing time for large OLAP cubes conflicts with other systems bringing frustration during peak periods such as month-end close or budget season. ROLAP is a preferred choice when data freshness is valued as relational databases let you query live data however you need it, while you are able to react to changing conditions in your market.
5. Consolidation impossible (with OLAP)
One of the most common horror stories for FP&A professionals is having an OLAP vendor tell you they’re going to be able to do consolidation and intercompany eliminations. Six months down the line, they can’t connect into your ERP as OLAP consolidated reporting is stuck to the template you have been set up with. Darcie Nguyen, director of Accounting at Twin Valley, a Kansas telecommunications company, says the challenge of using OLAP-based Vena (before moving to Datarails) was this ongoing limitation. Twin Valley and ISG (its sister company) needed to consolidate their financials. The two businesses operate on different systems and Vena failed to support the structure. Nguyen says: “We tried to merge both companies into Vena, and it just wasn’t working.”
It’s a data integrity problem. When consolidation fails, intercompany eliminations don’t happen cleanly, entities don’t roll up correctly, and the numbers leadership is making decisions on may simply be wrong. With OLAP, you may not even know what you’re missing — because the system can’t tell you what it can’t see.
Since moving to Datarails Nguyen says they stabilized consolidation across the two companies, both entities rolling up cleanly inside a single reporting environment that the accounting team controls. “We are on two completely different platforms but now everything comes together in one place”.
6. OLAP not ready for an AI world
If OLAP can’t reliably tell you where an expense lives, it certainly can’t tell an AI. As OLAP cubes are pre-built data structures designed only to answer specific, predefined finance questions, they are inherently rigid and hide logic. This makes them hard for AI tools being increasingly used by finance teams, to understand. Cube-based platforms were built for a world before AI – perfectly capable of highly structured human queries, but not open-ended reasoning. Multi-cube architectures only multiply the problem. The more cubes needed to answer a question, the more places logic hides, and the more an AI has to “guess” at relationships it can’t directly observe. This degrades accuracy. When Datarails FinanceOS connects your data to your favored AI platform, it reads a single, transparent data model. It can see the logic, reason over it, and write back to it — without needing to decode a web of cube relationships it was never trained to interpret.
Didi Gurfinkel, Datarails Co-founder and CEO, put it this way in an interview with an influential CFO known as Secret CFO:
“If you look at the way we build the system, we build a relational database. You can build any number of tables. The tables can be in any format or structure you like. So, it’s not only that the consolidation is much easier, you also don’t need to force anything to anything. You just can bring it in. But for the AI, this unlimited environment – it’s a database with endless dimensions, endless columns and rows and full flexibility. So, on both sides – the analysis and database – we put the flexibility on top as part of our core concepts.”
Here ROLAP uses open tables where all data and logic are visible, so AI can explore any question, understand how things are calculated, and instantly turn outputs into usable models without rebuilding anything. It lets AI freely understand (only restrained by the governance and permissions of FinanceOS) to readily explore and update financial data in real time.
Conclusion: The clear choice for modern finance teams
Legacy OLAP cube technology creates rigidity, consultant dependency, and scalability challenges that modern finance teams cannot afford. ROLAP provides unlimited dimensions, finance ownership, faster change implementation, and seamless integration of multiple data sources – all while maintaining performance and enabling AI-powered capabilities.
If you are choosing OLAP then it is worth bearing in mind the challenges you will face:
- Rigidity: limit of 8-12 dimensions. Additional dimensions require separate cubes
- Lack of scalability: it can’t update with your business requirements or do consolidation and intercompany eliminations as you grow
- Consultant-owned rather than finance-owned: consultants and extra fees required for updating your cubes
- Lack of freshness – aside from natural limitations of cubes, data is not updated in real-time
- Adding more cubes – as well as the cost and time, the more cubes added, the less they are able to talk to each other
- Not AI-compatible – Cube-based platforms were built for a world before AI and platforms like Claude and ChatGPT struggle to play nicely with OLAP FP&A tools
If your business model, chart of accounts, and reporting structure haven’t changed in a decade and you never plan to integrate AI, a cube-based system might still serve you. But before signing with an OLAP tool be sure to cover yourself by asking key questions. What happens when I add a new cost center? Can our finance team do it, or does it require a consultant? How current is my data? What’s the refresh cycle, and what triggers it? Can I change my reporting structure without a professional services engagement? If the answers involve project timelines, implementation partners, or cube rebuilds, you’re looking at an OLAP problem.
A Different Philosophy
Datarails was built on a different premise: finance teams should own their data, their models, and their reporting structure. Because Datarails is Excel-native, existing models, hierarchies, and logic are the starting point. They are not something you have to rebuild inside a proprietary cube. When your business changes, you change your model. That’s it.
The inventor of OLAP, E.F. Codd, himself admitted the obstacles of the OLAP system he defined more than three decades ago. In his white paper (Providing OLAP to User-Analysts: An IT Mandate) the British researcher mused:
“Vendors have for the most part taken the path of least resistance and have concentrated upon the development of tools in support of static data analysis and ignored users’ requirements for robust workstation tools supporting the creation and manipulation of… dynamic data analysis.”
Legacy FP&A tools built on OLAP – with rigidity, high priced consultancy and inflexibility baked in, have never fully escaped this critique.
