Architecture
BI, Rebuilt From the Ground Up
A new architecture for a new generation of BI.
That speed isn't the result of faster hardware or clever optimization. It comes from removing an entire piece of the system that other legacy BI tools can't function without.
Faster
2x–12x
faster than traditional BI
Architecture
2-Tier
no calculation engine required
Live
100%
of functions work in live mode
The problem
Why Legacy BI Tools Slow You Down
Most BI tools, including Tableau and Power BI, use a calculation engine, a separate mini-database built just for fast calculations. Tableau calls theirs Hyper, Power BI calls theirs VertiPaq. That made sense when regular databases were too slow for real-time analysis. Databases are fast now. The engine that used to solve that problem is now just extra weight.
Your data gets copied, and that copy goes outdated
To use the calculation engine, the BI tool copies your data into it first. That copy falls behind every time your real data changes. You also pay to store your data twice: once in your database, once inside the BI tool.
Import Mode = Data Copy = Outdated Data
Switching to live data breaks things
Some tools let you connect live instead of copying data. Power BI calls this DirectQuery, Tableau calls it Live Connection. Their calculation engines weren’t built for that. Turn on live connection, and a large part of what the tool can normally do stops working.
This isn’t a bug they haven’t fixed. It’s a limit built into how the tool works.
More steps between you and your data means more can go wrong
A request has to pass through several stops before it reaches your data. Each stop adds delay, and it’s possible that something could go wrong. This setup hasn’t changed much since the 1990s, even though the reason for it, slow databases, no longer applies.
Client → App Server → Calc Engine → Source
Architecture
The Central Flaw in Every Legacy BI Tool
It's not a feature gap. It's a structural one. And it's been there since the 1990s.
← Swipe to see the full diagram →
Legacy BI
Dataset size limited by RAM in the calculation engine
MPP BI
No size limit. Billions of records. Runs natively at the source.
Legacy BI
~40% of DAX functions broken or unsupported in DirectQuery
MPP BI
100% of functions work in live connection. Always. No exceptions.
Legacy BI
4 infrastructure layers to buy, license, manage, and secure
MPP BI
2 infrastructure layers. Period.
The design choice
How MPP BI Is Built Differently
Everything happens next to your data
MPP BI's application server runs inside your database. Your business logic, access permissions, and dashboard settings all live in the same place as your data. Because there's no separate server in between, there's also nothing extra between you and your data. When you open a dashboard, your browser talks directly to the MPP BI server, which transforms your query into SQL for your database.
Fewer steps = fewer places for something to slow down or go wrong.
Two layers of protection
Most BI tools pull your data out first, then filter out what a user isn't allowed to see. MPP BI does it the other way around: it checks what you're allowed to see before it ever pulls the data. Every request gets translated into a query that runs directly on your database, using your database's own processing power. Your data never has to leave its source to be analyzed.
Permissions are checked → data is filtered, then fetched → you see what you’re permitted to.
Works with what you already have
MPP BI doesn't ask you to change your environment to fit the tool. It runs on-premises, in the cloud (AWS, Azure, GCP), in containers, or in a mix of these. It works on Linux systems and with both Intel and AMD hardware.
Calculation language
Built for Live Data From Day One
Most BI tools have a formula language built assuming your data would be copied in first. Power BI's is called DAX. Live connections came later, as an add-on, so a large part of the language stops working once you switch to one. MPP BI's calculation language was built for live connections from the very first line of code.
DAX in Power BI (Live Connection Mode)
MPP BI's Language
Built for import, adjusted later for live
Built for live connection from the start
Many functions break or behave differently in live mode
Every function works the same, always
Time-based calculations are limited or disabled
Full time-based calculations, even live
Developers often maintain two versions of the same report
One version. One mode. Always live
Gets slower as calculations get more complex
Speed depends on your database, not the tool
This same language works on both sides of MPP BI, in the browser and inside the database, so your team isn't learning two different systems for the same task. Developers can also use it inside JavaScript, alongside whatever other tools or libraries they already use.
Talk to an Engineer
If you have any architecture questions, like how pushdown queries work with your database, how the metadata layer handles permissions, or what deployment looks like in your environment, book a call with our technical staff.