Roadmap to 1.0
Although the software has come a long way, there is still a lot more that needs to be done before we can claim full compatibility with DAX.
Getting to 1.0
On top of implementing the last 113 functions (many of which are trivial and will be done continuously throughout the 0.X workstreams), there is some key functionality missing before we can claim a compliant 1.0 model. Furthermore, supporting CSV, Iceberg or Delta Lake files might make sense, these can be implemented on a needs basis.
0.3 Tool to design the TMSL model
Right now, creating a model requires deep understanding of the TMSL structure and is not very approachable. To make it easier to adopt DAX-rs, we need a small tool that can allow you to design the data model.
0.4 Basic Auth and Role-based Security
A major gap in the current server is the lack of roles and authentication. Here we will create roles and role-based filtering and support basic auth for the XMLA server.
0.5 OAuth2 for native (non-XMLA) endpoints
Unfortunately, XMLA does not support OAuth2 authentication, a fact which makes it much harder to offer external services. Only basic auth, Entra and SPNEGO seem to be supported. For our local tools, however, there is no reason not to add OAuth2 support.
0.6 Calculation Groups, Hierarchies and KPI
After roles have been properly introduced, we can dive back in and implement the remaining features missing in our DAX implementation.
0.7 Window functions
In 2024, window functions were introduced into DAX, allowing you to peek ahead in the execution of the query. How this should be implemented and whether it is difficult or not remains to be assessed.
0.8 SPNEGO for XMLA
Basic auth is not really a good authentication strategy in 2026, so we will have to consider implementing SPNEGO. This is far outside my comfort zone and therefore I have pushed it as far down the pipeline as possible.
0.9 Cleanup of XMLA server and stabilize MDX support / Excel
I might write an article about what life is like reverse engineering an MS protocol. Suffice it to say that what is written in the (somewhat sparse) documentation and what the server expects are quite different. After having gotten XMLA for DAX up and running, it was demoralizing to discover that Excel relied on a DAX -> MDX translation layer and that the XMLA response required for these is completely different.
Feeling tired of this process, I essentially vibe coded the MDX translations and the server responses. The outcome is not great and will require a lot of TLC. In fact, the whole XMLA engine is a lot more “stringy” than I would like, so when we have the implementation in place, it is time to give the XMLA server the overhaul it deserves.
0.10? Investigate implementing annotate
As we have a close-to-working server, what use cases it should fulfill needs to be uncovered. The path to 2.0 will be centered on supporting SQL backends, so whether the ability to split the Parquet tables up to support larger models is worth it, or is better left to new backends to handle, remains an open question. Feedback on this point would be appreciated.
1.0 Fully stabilized XMLA server and full function coverage
With all of that in place, we should be able to claim that DAX-rs supports the DAX standard.
What then?
Having established a fully functional Polars-based DAX server, the next step is to focus on SQL backends. This would require writing a new SQL intermediate representation that is then translated into the various SQL language variants like ClickHouse, Trino, Snowflake, etc.
With the 1.0 having fleshed out a solid test framework, implementing additional backends should hopefully be a lot simpler.