Understanding Differences Between First-Generation and Premium Process Query Engine Behavior

The behavior of the NOT operator in filters differs due to how each engine handles NULL values in logical expressions.

*Except for operators IN and MULTI_IN.

If your data may include NULLs and you want to preserve first-generation engine behavior, adjust the filter to explicitly handle them:

FILTER ( "mytable"."id" IS NULL OR "mytable"."id" != 1 );

This explicitly includes rows where id is NULL or not equal to 1, maintaining compatibility with the previous logic.

In the first-generation engine, all aggregations - including MEDIAN and QUANTILE - were always computed using exact methods.

In contrast, the Premium Engine performs exact aggregations by default for all operators except MEDIAN and QUANTILE, which use approximate algorithms to improve scalability and performance. While this enhances speed, it may lead to minor deviations from exact results, particularly on small or edge-case datasets.

To maintain full control, the new engine provides the ability to explicitly choose between exact and approximate modes, allowing users to balance accuracy and performance based on their specific use case.

MEDIAN (approximate) -> uses QUANTILE 0.5, which uses APPROX

Dataset: [1, 1, 2, 3, 4, 5]

Quantile: 0.5 ( = MEDIAN)

By default, the APPROX operator is used for both functions. If you require the EXACT logic for cases where precision is critical - particularly for KPIs that depend on statistical accuracy - please contact our support team. We will be happy to assist you.

To ensure high performance with large datasets, the Premium Engine does not apply a default sorting to queries unless explicitly specified by the user with an ORDER BY clause. This aligns with standard industry practices. The first-generation engine may have provided a seemingly consistent default order, but this behavior was never guaranteed and should not be relied upon. This can lead to different results between the two engines, particularly with functions that rely on order to determine the result, such as FIRST or LAST.

To ensure consistent and predictable results, you should always apply an explicit ORDER BY clause in your queries, especially when using functions where the order of data is critical. This includes operators like FIRST, LAST, STRING_AGG, PU_FIRST, PU_LAST, PU_STRING_AGG, and all window functions.

Similar to the previous difference, when querying unaggregated columns from an eventlog, such as in an OLAP table component, the Premium Engine does not apply any default sorting. The order of activities is not guaranteed, which can lead to mixed-up cases or an illogical sequence of events.

Consider an OLAP table showing case id and activity names. Without an explicit sorting applied, there is no guarantee that the activities will be displayed in their chronological order based on timestamps. Furthermore, it might also happen that different cases are mixed up.

To view activity sequences correctly within cases, you should:

The First-generation engine was more permissive towards duplicate values in primary key columns. To support advanced functionalities like Augmented Attributes & Tasks and ensure delta readiness for data models, the Premium Engine strictly enforces the uniqueness of primary keys directly during the load.

If you encounter a primary key duplication error when loading a data model, you must go back to your data transformations and modify the necessary SQL queries to remove the duplicates. Once the transformations are corrected, reload the data model.