Cloudera on Cloud: September 2026 Release Summary
The Release Summary of Cloudera on cloud summarizes major features introduced in Management Console, Data Hub, and data services.
Cloudera Data Catalog
Cloudera Data Catalog 3.2.2 introduces the following changes:
Warnings for Ranger FGAC-protected tables in Data Shares
When you add an Iceberg table to a Data Share that Apache Ranger Fine-Grained Access Control (FGAC) protects with column masking or row-level filtering, Cloudera Data Catalog displays a warning titled Table with fine-grained access control policies. The warning alerts you that external consumers who access the shared table through the REST Catalog might not receive the same column masking or row-level filtering protections, which could expose data more broadly than intended.
A warning icon also appears on asset rows for FGAC-protected tables already included in the Share. You can still add or keep the table after you review the access policies. For more information, see Modifying Data Shares.
For more information about the Known issues, Fixed issues and Behavioral changes, see the Cloudera Data Catalog Release Notes.
Cloudera Data Engineering
Cloudera Data Engineering 1.26.1-H1 introduces the following changes:
DEX-22794: Azure v1–v4 capacity growth restrictions
Starting July 31, 2026, Microsoft Azure enforces capacity growth restrictions on v1–v4 Virtual Machine (VM) families, blocking new deployments and scale-out activities with full retirement scheduled by July 31, 2028. This impacts the default infrastructure of Cloudera Data Engineering, specifically affecting the ability to scale Spark compute pools.
As a result, new deployments, capacity expansion requests, and quota increase requests for impacted VM series are not approved. Quotas already approved in existing subscriptions for these VM series are not affected.
Impacted VM series
The following VM series are set to retire by 31 July 2028 and are subject to growth controls:
- Compute-optimized: F, Fs, Fsv2
- General-purpose: D, Ds, Dv2, Dsv2, Av2, Amv2, B, Bs
- Memory-optimized: G, Gs
- Storage-optimized: Ls, Lsv2
The following VM series are subject to growth controls:
- General-purpose: Dv3, Dsv3, Dv4, Dsv4, Ddv4, Ddsv4, Dav4, Dasv4
- Memory-optimized: Ev3, Esv3, Ev4, Esv4, Edv4, Edsv4, Eav4, Easv4
Note
If you are currently using any of the listed VM series, you might experience restrictions when requesting additional quota or deploying new workloads on the impacted VM series.
This change affects the following processes:
- New VM deployments
- VM scale-out activities requiring additional capacity
- Quota increase requests
- Future growth plans on impacted VM series
This change does not affect existing deployments operating within capacity currently allocated. You can continue running your existing workloads without interruption.
If you are planning future growth, expansion, or new deployments, you must evaluate migration to newer-generation VM series that provide improved performance, enhanced security, broader availability, and longer-term platform support.
Recommended VM series
- General-purpose workloads: Dv5, Dv6, and Dv7 series or variants (Dl/Dd)
- Memory-intensive workloads: Ev5, Ev6, and Ev7 or variants (Ed) series
Important
To avoid service capacity issues, you must complete the following steps before the retirement date, 31 July 2028:
- Review your current usage of v1-v4 Azure VMs in your subscriptions.
- Plan and migrate your workloads to newer-generation Azure VMs. For more information, see:
- Confirm that your workloads are functioning as expected after the migration.
Azure workload and database instance type fallback
As part of Microsoft’s retirement of Azure v1–v4 Virtual Machine (VM) families, Cloudera Data Engineering migrated AKS node pool and MySQL Flexible Server instance types to v5+ VM SKU equivalents. The Azure workload and database instance type fallback feature provides the fallback mechanisms if a v5 VM SKU is not available in your specific Azure region or subscription.
This feature introduces two tenant-level entitlements:
DE_AZURE_LEGACY_WORKLOAD_INSTANCE_TYPEDE_AZURE_LEGACY_DB_INSTANCE_TYPE
Both these entitlements are disabled by default.
These entitlements allow you to maintain legacy instance types in regions where v5 SKU capacity or quotas are currently unavailable.
This feature also provides a pre-flight SKU availability check to validate v5 SKU support before initiating any irreversible upgrade operations, such as the two-phase, delete-then-create migration operations, ensuring cluster stability.
For more information, see Azure workload and database instance type fallback.
DEX-22841: Resolved Livy pod thread leak in Cloudera Data Engineering 1.26.1
Note
Cloudera Data Engineering 1.26.x users running Spark-on-Kubernetes batch workloads with long-lived Livy pods (operating for days or weeks without restarts) are affected. Risk increases with high batch session churn.
Caution
Cloudera on cloud 7.2.18 is past its End of Support (EOS) date. You must upgrade to a version higher than 7.2.18 to resolve the issue. For more information, see Cloudera Long Term Support Release Policy for Cloudera on cloud.
In Cloudera Data Engineering version 1.26.1, Livy pods could experience native thread exhaustion, leading to job failures and HTTP 500 errors. Livy pods could enter a silent complete outage, meaning that all batch and API requests returned HTTP 500, while the pod remained in Running state, preventing Kubernetes from automatically restarting it.
The cause was native thread exhaustion (“unable to create native thread”). A Livy token-refresh bug recreated the Kubernetes client every 5 minutes without closing the previous instance. In Cloudera Data Engineering 1.26, Fabric8 7.x uses Vert.x (~10 native threads per leaked client), causing threads to grow linearly until reaching the cgroup pids.max (~37K) limit. In Cloudera Data Engineering 1.25 and lower versions, the token-refresh leak was present but remained largely latent because Fabric8 used OkHttp.
This issue is resolved in this release.
Action required: Upgrade to the Cloudera Data Engineering 1.26.1-H1 release containing the Livy fix that removes the redundant Kubernetes client re-creation from the service account token-refresh loop and updates the token on the existing client only.
Workaround: Cloudera recommends upgrading to the Cloudera Data Engineering 1.26.1-H1 Hotfix release. Alternatively, you can mitigate the issue by manually restarting the affected Livy pod in the Virtual Cluster to reset the accumulated native thread count. This action clears the outage but the leak resumes until the patch fix is applied. You must monitor Vert.x thread growth by running the following command:
$> jstack 1 | grep -c "vert.x-eventloop-thread-0"
After running this command, proactively restart the long-lived pods.
ENGESC-33920: Resolved TGT generator race condition in FreeIPARecovery
In this issue, a race condition is now resolved in the TGT generator that caused CLIENT_NOT_FOUND errors in FreeIPARecovery. Logs from the tgtgen pod indicated that the FreeIPARecovery synchronization process was crashing due to an IndexOutOfBoundsException, leading to CLIENT_NOT_FOUND retries.
For more information about the Known issues and Fixed issues, see the Cloudera Data Engineering Release Notes.
Cloudera Data Flow
Cloudera Data Flow 3.2.0-b137 introduces the following changes:
Automatic PostgreSQL upgrades
PostgreSQL DB is now automatically upgraded alongside Cloudera Data Flow upgrades. An upgrade to Cloudera Data Flow 3.2.0 upgrades PostgreSQL to version 17.
Default Node SSL Context Service
This release of Cloudera Data Flow introduces a new DefaultNodeSSLContextService controller service. This controller service allows you to send data from one NiFi cluster (deployment or test session) to another within the same Cloudera Data Flow environment, without having to manually manage and rotate certificates.
For more information, see Securing communication between NiFi clusters using the Default Node SSL Context Service
New Kubernetes version support
Cloudera Data Flow now supports EKS/AKS 1.36.
Note
Because of the jump from EKS/AKS version 1.34 to version 1.36, Cloudera Data Flow service upgrades may take upwards of two hours. Keep this in mind when planning your upgrades.
ZooKeeper removed
As of release 3.2.0, Apache ZooKeeper has been removed from Cloudera Data Flow.
HashiCorp Vault replaced with OpenBao
OpenBao replaces Vault in Cloudera Data Flow.
Cleaner test session cancellation
Canceling a freshly started test session now fully cleans up its underlying resources (volumes, namespace) rather than leaving them suspended, avoiding wasted cloud resources. A confirmation dialog explains the behavior; resumed sessions still preserve data.
Clearer suspend-failure handling
A failed test-session suspend now reports a distinct, accurate failure state with a retry path, instead of a misleading “failed to terminate.”
Reliable termination of orphaned deployments
Terminating a deployed flow now succeeds even when its underlying NiFi process group was already deleted, instead of leaving the deployment stuck.
Alphabetically sorted workspace selector
The Target Workspace/environment dropdown in the deployment dialog now lists environments alphabetically, matching the create-draft dialog.
Accurate validation state in the deployment wizard
A failed NiFi configuration validation (for example, a bad custom NAR) now stays flagged as failed when navigating between steps, instead of incorrectly showing a green checkmark.
Smarter execution-node defaults
Processors that can only run on the primary node (e.g., ListS3, QueryDatabaseTable) now default to and are validated against “Primary Node” execution, preventing invalid multi-node configurations.
Faster shared parameter group handling
Drafts that import shared parameter groups now perform far fewer backend lookups, sync parameters concurrently, and use longer timeouts, thus improving performance and reliability at scale.
For more information about the Known issues, Fixed issues and Behavioral changes, see the Cloudera Data Flow Release Notes.
Cloudera Data Warehouse
Cloudera Data Warehouse 1.13.2-b120 is a hotfix release that does not include new features, but a list of fixes. For more information, see the Cloudera Data Warehouse Release Notes.
Cloudera Data Warehouse 1.13.1-b44 introduces the following new changes:
What’s new in Cloudera Data Warehouse on cloud
Upgrade support for Azure AKS 1.35
Cloudera supports Azure Kubernetes Service (AKS) version 1.35. In Cloudera Data Warehouse 1.13.1-b44 (released September 18, 2026), when you activate an environment, Cloudera Data Warehouse automatically provisions AKS 1.35. To upgrade to AKS 1.35 from a lower version of Cloudera Data Warehouse, you must backup and restore Cloudera Data Warehouse.
Note
Using the Azure CLI or Azure portal to upgrade the AKS cluster is not supported and might result in cluster instability or downtime. For more information about upgrading, see Upgrading an Azure Kubernetes Service (AKS) cluster.
Upgrade support for AWS EKS 1.35
Cloudera supports AWS Elastic Kubernetes Service (EKS) version 1.35. In Cloudera Data Warehouse 1.13.1-b44 (released September 18, 2026), when you activate an environment, Cloudera Data Warehouse automatically provisions EKS 1.35. To upgrade to EKS 1.35 from a lower version of Cloudera Data Warehouse, you must backup and restore Cloudera Data Warehouse.
Note
Using the AWS tools to upgrade the EKS cluster is not supported and might result in cluster instability or downtime. For more information about upgrading, see Upgrading an Amazon Kubernetes Service (EKS) cluster.
Configuration of Intermediate Results Cache in Impala Virtual Warehouses
Cloudera Data Warehouse supports the Intermediate Results Cache feature for Impala Virtual Warehouses to improve query performance and resource efficiency for repeated analytic workloads. You can now enable and configure the cache during Impala Virtual Warehouse creation or update an existing Impala Virtual Warehouse. When enabled, a cache size of 20 GiB is applied by default. Configured values must be greater than 0 and cannot exceed 50% of the data cache. Invalid values are rejected during validation. For more information, see Configuring Intermediate Results Cache for Impala Virtual Warehouse.
Update to default Azure VM instance types for Virtual Warehouses and shared services
The default Azure VM instance types for Cloudera Data Warehouse are updated to align with Microsoft Azure’s deprecation of v1–v4 VM series. The deprecated Standard_E16_v3 and Standard_E16ds_v4 instance types are no longer available for selection as compute instance types. Additionally, the shared services instance type is now changed from Standard_D8s_v3 to Standard_D8ds_v5. This update ensures continued scalability and prevents deployment or quota limitations ahead of Azure capacity growth restrictions effective 31 July 2026. For more information, see Compute Instance Types for Cloudera Data Warehouse.
Support for EKS API_AND_CONFIG_MAP authentication mode on AWS
Newly activated Amazon EKS clusters in Cloudera Data Warehouse on cloud now use the API_AND_CONFIG_MAP authentication mode. This update adds support for AWS EKS access entries while maintaining complete backward compatibility with the existing aws-auth ConfigMap authentication mechanism. Aligning with AWS recommended cluster access management controls, this change transitions environments toward API-based access without impacting existing cluster operations.
Update to Cloudera Data Visualization to version 8.1.4
The Cloudera Data Visualization component included in Cloudera Data Warehouse is updated to version 8.1.4.1000-4. This update brings the latest improvements, bug fixes, and enhancements from the Cloudera Data Visualization 8.1.4 release to Cloudera Data Warehouse, including a refreshed look across the product with updated colors, fonts, borders, and spacing.
What’s new in Cloudera Data Explorer (Hue) on Cloudera Data Warehouse on cloud
Enhanced session security for Cloudera Data Explorer (Hue)
Data Explorer now includes enhanced security for the session ID (sessionid) cookie. This enhancement helps prevent unauthorized access that could lead to data exposure, unauthorized query execution, and job submission across connected Data Explorer services.
For more information, see Securing sessions .
What’s new in Hive on Cloudera Data Warehouse on cloud
Selection of Common Table Expression materialization strategy
You can now select how Apache Hive materializes a Common Table Expression (CTE). The new hive.optimize.cte.suggester.type property lets you select the syntax-based strategy, the cost-based strategy, or disable CTE materialization. This option prevents the two strategies from interfering with each other and causing excessive materialization. This property defaults to AST, which preserves existing behavior.
Apache Jira: HIVE-29217
What’s new in Iceberg on Cloudera Data Warehouse on cloud
Support for Iceberg table Z-ordering in Hive
Apache Hive supports Z-ordering for Apache Iceberg tables in CREATE TABLE and INSERT statements. You can specify Z-order columns with the WRITE [LOCALLY] ORDERED BY ZORDER clause when createóing a table. Hive applies the same Z-order layout when you insert data into that table.
For more information, see Z-ordering feature.
Apache Jira: HIVE-29133
Support for CREATE TABLE LIKE with Iceberg from non-Iceberg tables in Impala
Apache Impala supports using CREATE TABLE LIKE statement with the STORED BY ICEBERG clause to create an Iceberg table from an existing non-Iceberg table in the metastore, such as Parquet, ORC, Avro, or Text. The operation copies the source schema into Iceberg table metadata only. You can now use the INSERT INTO statement to load data.
For more information, see Create an Iceberg table from a non-Iceberg table (Impala).
Apache Jira: IMPALA-13299
What’s new in Impala on Cloudera Data Warehouse on cloud
There are no new features in this release.
What’s new in Trino on Cloudera Data Warehouse on cloud
Configuration of query-level fault tolerance and coordinator high availability for Trino
Cloudera Data Warehouse supports fault tolerance with query-level retry and Active-Passive coordinator high availability (HA) for Trino Virtual Warehouses. Query-level retry automatically reruns failed queries up to four times using in-memory buffer spooling, while Active-Passive HA deploys a standby coordinator to quickly take over if the active coordinator crashes or shuts down, ensuring continuous cluster availability. You can enable and configure both settings when creating or editing a Trino Virtual Warehouse in the Cloudera Data Warehouse web UI. For more information, see Configuring query-level fault tolerance for Trino.
Upgrade of Trino runtime version
The Trino runtime is upgraded from version 479 to 481.
This upgrade introduces stability improvements and performance optimizations.
Support for Apache Kudu connector in Trino federation connectors
Trino supports the Apache Kudu connector as part of the federation connectors. You can query, insert, and delete data directly in Apache Kudu using Trino. For more information, see Apache Kudu connector support for Trino.
Support for connection pooling for Hive and Impala federation connectors
Cloudera Data Warehouse now supports JDBC connection pooling for the Hive-jdbc and Impala federation connectors, extending the pooling already available for the MySQL, PostgreSQL, MariaDB, Teradata, and Oracle connectors. When pooling is enabled, a connector reuses physical JDBC connections instead of opening and closing one for every query, which reduces connection handshake latency and load on the target data source. Connection pooling is disabled by default. You can enable it by setting the connection-pool.enabled property to true in the connector configuration.
Support for Kerberos authentication in the Trino Oracle connector
The Trino Oracle connector now supports Kerberos authentication, so you can connect Trino to Kerberos-secured Oracle databases. For more information, see Configuring Kerberos authentication for the Oracle connector.
For more information about the Known issues, Fixed issues and Behavioral changes, see the Cloudera Data Warehouse Release Notes.
Cloudera Observability
This release of the Cloudera Observability service introduces the following changes:
Telemetry export to third party for Cloudera environment
You can configure the OpenTelemetry pipeline to duplicate and route your collected metrics and logs to external, third-party platforms. To manage these export platforms without modifying your core collector configuration, you must define your settings through the CLI.
Cloudera Observability collects and exports infrastructure and application or service metrics of the Cloudera environment (Cloudera Base on premises (airgapped and non airgapped) and Cloudera on cloud).
For more information on the new metrics available, see the Telemetry export to third party for Cloudera environment documentation.
Telemetry export to third party for Cloudera Data Services
You can configure the OpenTelemetry pipeline to duplicate and route your collected metrics and logs to external, third-party destinations. To manage these export destinations without modifying your core collector configuration, you must define your settings through the ObservabilityPipeline Custom Resource and Kubernetes Secrets.
Cloudera Data Services on cloud: Third-party export is available for Cloudera AI on cloud 2.0.58 and higher.
Cloudera Data Services on premises Service Pack 4: Third-party export is available for Cloudera Data Warehouse.
For more information, see the Telemetry export to third party for Cloudera Data Services documentation.
For more information about the Known issues, Fixed issues and Behavioral changes, see the Cloudera Observability Release Notes.
Cloudera Operational Database
Cloudera Operational Database 1.61 introduces the following changes:
Autoscaling configuration now displays concrete values for always-on metric fields
In Cloudera Operational Database autoscaling configuration, the always-on metric fields previously displayed -1 as a sentinel value to indicate that a field was not configured.
These fields now show the actual concrete values, providing clearer and more accurate representation of the autoscaling configuration state.
Default to newer generation Azure instance types while maintaining support for legacy instances
Previously, Cloudera Operational Database relied on older generation instances that Azure has deprecated.
Cloudera Operational Database now defaults to newer generation Azure instance types, while still supporting the older instances. This change ensures Cloudera Operational Database deployments on Azure remain functional and compatible with current platform requirements.
For more information about the Known issues, Fixed issues and Behavioral changes, see the Cloudera Operational Database Release Notes.
