For migration tips, see the Migration Notes.
For details about versioning, see the Versioning Policy
6.2.3
2026-10-29Summary
New Features
Improvements
- Query correlation across logs, traces and query history
- DirectQuery aggregate tables serve more queries
- Observable distribution in the query node
- Datastore eager chunk compression
New Features
Atoti Power BI adapter
The Atoti Power BI Adapter is now generally available. It allows you to connect Atoti directly to Power BI, enabling interactive reports powered by Atoti’s aggregation engine. Atoti generates a Power BI template file for each cube, which opens in DirectQuery mode and reproduces the cube’s hierarchies.Concealed measures in distributed data cubes
A data cube can conceal measures again: they stay computable on the data cube but are never sent to the query cubes, and only a post-processor whose execution is disabled in the query cube can use them. This is a redesign of the concealed measures of Atoti Server 6.1: the measures that use a concealed measure are checked when the data cube starts, so that every measure of the query cube can be computed correctly. See Concealed measures and the migration notes.Improvements
Query correlation across logs, traces and query history
All the parts of a query, such as an MDX query and theGET_AGGREGATES queries it spawns, now share one query id, reported in the query execution logs, on the query spans and in the query history. Logs also carry the authenticated user.
See What identifies a query in a trace? and MDC attributes.
Some log fields and span attributes are renamed: update the log queries, dashboards and alerts that use them, as listed in the changelog.
DirectQuery aggregate tables serve more queries
A query served by an aggregate table is now split on the clustering fields of the aggregate table instead of those of the base table, and a user defined aggregation that cannot be re-aggregated is served at the granularity of the table. Its native array columns are re-aggregated in the database, and a measure mapping whose origin field cannot be reached from the base table now fails at startup. See Aggregate tables.Observable distribution in the query node
The query node tracks the distribution state of each data cube and each of its branches on its own, so a data cube whose discovery cannot be applied no longer holds back the others. New REST endpoints and JMX operations report this state. See What is the distribution state of a query cube?.Datastore eager chunk compression
The neweagerChunkCompression store property compresses a chunk as soon as a transaction fills it, which lowers the memory peak of large loads. It is disabled by default.
See Eager compression during transactions.
6.2.2
2026-09-30Summary
New Features
Improvements
New Features
XMLA client request identifiers
XMLA clients can now tag their requests, so that their own logs can be matched with Atoti’s. AttachDbpropMsmdRequestID and DbpropMsmdActivityID as entries of the <PropertyList> of an Execute request: Atoti records them as query metadata and reports them on the query span and in the query execution reports, in the metadata field or under the query_metadata key in JSON logs. See the XMLA endpoint for details.
Native vector aggregation on Databricks
Aggregations onArray columns can now run natively in Databricks, with its vector_sum function: sum, average, long, short, gross, and sum-product. This requires Databricks Runtime 18.1 or above. vector_sum computes in single precision, so aggregating an Array column of another numeric type than float natively requires setting DatabricksDialectSettings#arrayAggregationPrecision to FLOAT. Applications that need double precision can keep using emulated vectors. See vectors and DirectQuery for details.
Improvements
Performance improvements
- Cube startup with deep Copper measure chains: applications that build measures on top of many layers of intermediate Copper measures, for example measures that switch on parameter hierarchies, start faster.
- Queries with large results: queries that assemble large results, such as post-processed measures over many locations, now run at a consistent speed across application runs. On some runs, the JVM could stop optimizing the code that assembles these results, which slowed down every such query until the application was restarted.
6.2.1
2026-09-03Summary
New Features
Improvements
- Query timeout override guardrail
- Force a post-processor to execute in the data cubes
- Feature-based loggers for the cube
- Distributed queries better target data nodes
- Faster query planning for large measure graphs
New Features
Atoti Tableau adapter
The experimental Atoti Tableau Adapter is now fully available. The feature is no longer experimental. It allows you to connect Atoti directly to Tableau, enabling interactive dashboards powered by Atoti’s aggregation engine.GAQ REST APIs are no longer experimental
The GAQ REST API and the Continuous GAQ REST API are now generally available. They run GetAggregatesQuery queries over REST and return their results in Apache Arrow format, as a single snapshot or as a continuous stream of updates.Continuous GAQ pagination
The streaming of query updates in the GetAggregatesQuery format can now be paginated. See the documentation page for more details.Improvements
Query timeout override guardrail
The Context ValueQueriesTimeLimit comes with new constructors allowing defining an override ceiling.
Using this new ceiling value, it is possible to define a default value after which queries timeout, but allow each query to override this timeout up until the defined ceiling.
As any context value, this is configurable on a per-user and per-role basis.
See the documentation page for more details.
Force a post-processor to execute in the data cubes
In a distributed cluster, a post-processor defined in the data cubes is normally also created in the query cube, where it is initialized before its partial results are reduced. Post-processors that need database access during initialization could not be defined this way, because the query cube has no database. Setting theIDistributedPostProcessor#DISABLE_LOGIC_EXECUTION_IN_QUERY_CUBE property ("disableInQueryCube") to "true" now makes such a post-processor run and initialize on the data cubes only. The query cube keeps only a lightweight placeholder that reduces the partial results. See Distributed Post-Processors for details.
Feature-based loggers for the cube
Most of the logging on the cube’s transactions and queries is unified under new feature-based loggers. These loggers are fully backward compatible: logging configurations do not need to be migrated. See the documentation page for more details.Distributed queries better target data nodes
Distributed Queries attempt to reduce the number of Data Nodes that are contacted when they would return an empty contribution to the query.Faster query planning for large measure graphs
Queries on measures that share many common dependencies, such as chains of post-processors or Copper measures reusing the same underlying measures, are planned faster.6.2.0
2026-07-27Summary
The main changes in 6.2 are:- Upgrade to Java 25
- Upgrade to Spring Boot 4, including Spring 7 and Jackson 3
- Switch to SLF4J for logging
Java upgrade
The new baseline is Java 25, bringing the latest JDK improvements to Atoti.Spring upgrade
The new baseline is Spring 7 and Spring Boot 4, because open source support for Spring Boot 3 ends in June 2026. This upgrade also brings Jackson to version 3.SLF4J
Atoti Server now logs through SLF4J, the de facto standard logging facade for Java, instead of JUL (java.util.logging). Routing Atoti Server logs into your logging framework of choice is now more direct. See the migration notes for the logging dependencies to review when upgrading.New Features
- Added Copper Join Optimization, an experimental optimization that speeds up Copper joins with a selective filter on the joined table.
Other changes
Supported database version changes
The baseline for the database versions supported in DirectQuery has changed.- ClickHouse 26.03
- Databricks Runtime: 17.3
- MSSQL Server 2019