Skip to main content

Known Issues

C2025.8.0

PostgreSQL deployment update

What you need to know

AtScale utilizes PostgreSQL for its metadata store. When PostgreSQL is configured for high availability (with more than one replica), Bitnami’s PostgreSQL has a serious bug in its management of primary nodes, resulting in poor management and recovery services that can lead to duplicate primaries, platform instability and data loss. The result is that deploying AtScale with embedded PostgreSQL and a replica larger than one will likely create platform instability as Kubernetes auto-manages the cluster.

For environments that don’t require high availability

AtScale will continue to ship Bitnami PostgreSQL with the default setting of replica=1. This configuration is effective and highly stable. It’s a solid configuration for POCs and non-production environments. Some customers may choose to run this configuration in production and utilize PostgreSQL’s backup options.

For environments that require high availability

While AtScale has offered the embedded PostgreSQL for convenience, it is common for technologies that require a metastore, such as PostgreSQL, to leverage an externally managed database. AtScale recommends considering your SLAs when configuring production. If you require high availability, it is recommended that you configure AtScale with an external PostgreSQL (i.e., Amazon RDS) instance that can guarantee this SLA and ensure stability.

DEVOPS-7216

Differences in CALCULATE behavior between AtScale and SSAS

The DAX CALCULATE function performs the calculation of a measure by applying some filter modifications over the query. As an example, consider the following DAX query for SSAS, which projects the Internet Sales Amount Local (ISA) for each of the product subcategories, filtering by the Accessories category. It also projects a measure that uses the CALCULATE function to calculate only the ISA when the category is Bikes.

DEFINE
VAR catFilter = TREATAS({"Accessories"}, 'DimProduct'[ProductCategoryName])

MEASURE 'DimProduct'[BikeSales] = CALCULATE(SUM(FactInternetSales[salesamount]), DimProduct[ProductCategoryName] = "Bikes")

EVALUATE
SUMMARIZECOLUMNS(
ROLLUPADDISSUBTOTAL('DimProduct'[ProductSubcategoryName], "total"),
catFilter,
"Sales", SUM(FactInternetSales[salesamount]),
"BikeSales", 'DimProduct'[BikeSales]
)

order by'DimProduct'[ProductSubcategoryName], [total]

All rows but the last one contain blank values for the BikeSales measure. That happens because CALCULATE only filters the sales of Bikes. However, since Bike is a Category and the query shows only Subcategories, it calculates only for the subcategories from the Bikes category. Additionally, in the last row, at the totals, all of the Bikes subcategories' total sales are shown (even though they do not appear in the table).

The results of the above query.

The following DAX query is the same example, but adapted for AtScale. You can see that AtScale produces the same total for the query, but the other rows are different. This is because AtScale currently handles CALCULATE (for some of the expressions, like the = operator) in the same way as MDX static tuples. Therefore, since the query projects Subcategory, which is part of the same hierarchy, the grouping is ignored and the measure value is all the Bikes sales.

DEFINE
VAR catFilter = TREATAS({"Accessories"}, 'Product'[Category])

MEASURE 'CubeMeasures'[BikeSales] = CALCULATE([Internet Sales Amount Local], Product[Category] = "Bikes")

EVALUATE
SUMMARIZECOLUMNS(
ROLLUPADDISSUBTOTAL('Product'[Subcategory], "total"),
catFilter,
"Sales", [Internet Sales Amount Local],
"BikeSales", 'CubeMeasures'[BikeSales]
)

order by [total], 'Product'[Subcategory]

The results of the AtScale-adapted query.

Although this example shows a small difference between AtScale and SSAS, it may have more problematic use cases. The CALCULATE function should, indeed, overwrite the query filters only when they conflict with the calculated expression, not always.

note

Using CALCULATE with context modification functions (ALL, ALLSELECTED, ALLEXCEPT, REMOVEFILTERS, etc.) works the same in AtScale as SSAS.

ATSCALE-18276

Identity Broker does not refresh Databricks tokens when impersonation is enabled

The Identity Broker does not properly refresh Databricks tokens when impersonation is enabled for the data warehouse.

DEVOPS-7171

Enabling honeybee on PostgreSQL data warehouses causes engine instability

Enabling honeybee on a PostgreSQL data warehouse after it has been connected to AtScale causes the engine to become unstable. To avoid this issue, AtScale recommends enabling honeybee on your PostgreSQL data warehouse before adding it in Design Center.

ATSCALE-28082

ADDCOLUMNS DAX function results in failure

When using Microsoft Power BI in Tabular mode with Redshift, adding a Power BI client-side expression with the ADDCOLUMNS DAX function can result in errors.

ATSCALE-25366

Is Aggregatable cannot be disabled on non-root levels in hierarchies with more than two levels

In hierarchies with more than two levels, disabling the Is Aggregatable property on levels other than the root level is not supported. In future releases, models with such a configuration will not deploy to the engine.

ATSCALE-25328

Iris JDBC does not support CTEs

The Iris JDBC driver does not support Common Table Expressions (CTEs), so the new feature that enables the query planner to use CTEs is not supported for Iris. If you are using AtScale on Iris, you need to set the following global setting:

query.planning.allowCtes: false

By default, this setting is set to true.

Identity Broker logout does not completely log out of Design Center

Users who log in to the Identity Broker from Design Center, then log out of the Identity Broker, are not automatically logged out of Design Center. This is because the Identity Broker logout event interrupts the Design Center function.

ATSCALE-22180

Tableau: Double dashes in catalog names creates empty .tds files

Double dashes (--) in the unique names of catalogs causes corruption of Tableau .tds file generation. This is because double dashes are reserved in many databases, and signal a comment in SQL. AtScale recommends avoiding this character pattern when creating and deploying catalogs.

ATSCALE-16605, ATSCALE-22167

Perspectives cannot contain multiple objects with the same display names

Perspectives cannot contain references to multiple objects with the same display names/labels, as this results in errors at deploy time.

ATSCALE-22326