Skip to main content
For a detailed list of all changes, see the Changelog.
For migration tips, see the Migration Notes.
For details about versioning, see the Versioning Policy

​
6.2.2

2026-09-30

​
Summary

​
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. Attach DbpropMsmdRequestID 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 on Array 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-03

​
Summary

​
New Features

​
Improvements

​
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 Value QueriesTimeLimit 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 the IDistributedPostProcessor#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-27

​
Summary

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
Many smaller changes are also part of this release. See the changelog for the full list. A migration note provides detailed guidance, including an automated migration process using OpenRewrite recipes.

​
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