Why no Python or R
Python and R are excellent for people exploring data at their own pace, and much of today’s data science was written in them. OpenBI’s notebooks make a different choice: OAX, SQL and C#, with the libraries built in. This page says why.
Built for agents’ speed
Python and R were made for people at a keyboard, where a second’s wait goes unnoticed. An agent works differently: it calls tools many times a minute, often several times a second, reading what each one gave before the next. Every call’s overhead adds up, so OpenBI is built to answer in milliseconds, and in microseconds where it can.
- The engine is C, and the libraries it builds in are C and C++: LightGBM, OR-Tools, QuantLib, and Open Graph, Norway Analytics’ own graph library in C. In OAX,
PREDICT,OPTIMIZE,QUANT.*andNETWORK.*run beside the data, in the engine’s own process: no interpreter to start, no data frame copied to another process, no package environment to load. - Notebook code is C#, compiled before it runs. The kernel loads LightGBM, OR-Tools and QuantLib once, asks the engine for networks, and each OAX step brings its rows from the engine once, kept in memory by column.
Our numbers
Measured on a Mac mini (Apple M2 Pro, 10 cores, 16 GB), in November 2026:
| What | Engine time |
|---|---|
| Report pages’ queries answered from the engine’s result cache (on in OpenBI Server), with 2 to 128 simulated users | 0.02 ms at the median; about 1 ms for 95 queries in 100 |
| The same queries answered by the engine, without the cache | 4 to 12 ms at the median |
| 13 TPC-H queries at scale factor 1 (6 million order lines), each the best of five runs | 2 to 43 ms each; 245 to 264 ms for all 13, in two runs |
Python and R start-up, measured
For comparison, the time to start Python and R and load a common data stack, measured on a 16-core laptop (AMD Ryzen AI Max+ PRO 395, Windows 11): each command started as a new process 15 times after one warm-up run, the median wall time shown.
| Command | Median |
|---|---|
| Python 3.14.2, start and exit | 40 ms |
Python, import numpy, pandas (NumPy 2.4.0, pandas 3.0.0) | 930 ms |
Python, import numpy, pandas, pyarrow (pyarrow 25.0.1) | 1,090 ms |
| R 4.5.2, start and exit | 250 ms |
R, library(data.table) | 290 ms |
R, library(dplyr) | 550 ms |
R, library(tidyverse) | 1,300 ms |
To be fair: a Python or R kernel that stays running pays this once, as OpenBI’s notebook kernel pays its own start once. A tool that starts a script for each call pays it every time, and either way the rows must be copied out of the BI engine into the interpreter’s data frames and back.
The heavy lifting is not where they differ. Python’s and R’s LightGBM and OR-Tools packages run the same C and C++ code that OpenBI builds in; their igraph packages run igraph’s C library, whose interface Open Graph follows and whose answers it is checked against. What the interpreter adds is the time around it: starting, importing, converting data, and calling across languages.
A smaller attack surface
pip and CRAN install code from public registries, with whatever that code depends on, and installing a package can run its code. That is a known supply-chain risk: malicious packages, and packages named a letter away from popular ones to catch a typo. A notebook environment that can install anything can be checked by no one but its owner, one machine at a time.
- Everything OpenBI Studio runs ships with it, listed in its bill of materials. Every build of its installer looks each component up in OSV and NVD at its shipped version, the same gate as OpenBI Server’s (see The vulnerability gate). A known vulnerability stops the build unless it is accepted in writing, by its id, for that component and version alone, and the bill then says why (see Accepted findings).
- OpenBI Server runs no notebook. It shows a published notebook read only, cell by cell with the outputs its last run kept; changing one means opening it in OpenBI Studio. No Python or R runs on the server, in a refresh or while people view.
- A model made elsewhere comes in as a file that is read, never run: LightGBM’s
model.txt, or a pickle or joblib file of a booster or a scikit-learn pipeline (see Import a model).
One stack you can audit
- The same answers on Windows and on a Mac. The same engine and the same library run on both, and each release is tested to give the same results on both.
- One version to check. A notebook’s results depend on OpenBI’s version and the notebook’s code, not on what one machine happened to install.
- Results kept as approved versions. What a notebook saves is a version with its evidence and fingerprints, approved by a person before it is used, then kept or retired, never altered (see Versions and approval).
What you need, we build, or you do
If your analysis needs a method the library doesn’t have, tell us at support@norwayanalytics.no: the library grows from what people need. Or build it yourself as a plug-in with the OpenBI SDK: a .NET 10 library that gives the studio’s agent new tools and the studio new tabs, shipped as a zip of its own. The studio runs plug-ins signed by Norway Analytics or by a publisher your IT allows; an unsigned one runs only where IT allows it.
Python and R elsewhere in OpenBI
Get data’s Python script and R script sources are legacy sources, kept so that Power BI projects open. They use this computer’s own Python or R, the studio asks once per project before their scripts run (see Get data), and OpenBI Server never runs them. For analysis, use a notebook. A prediction’s version can also be called from Python and other tools, listed under Call it in its Versions tab.