Release notes v2.5.0

Release highlights

Release statusNew featuresImprovementsLimitationsUpgrade instructions

Version name: ClusterControl 2.5.0
State: Latest
First release date: July 21^st, 2026
Maintenance status: Active
Total maintenance builds: 1
Last release date: August 2^nd, 2026

ClickHouse support — automated deployment of single-node and replicated clusters (with embedded ClickHouse Keeper), monitoring and alerting, backup and restore, scaling, import of existing clusters, and s9s CLI/API support, with SSL-encrypted inter-node communication. ClusterControl's first entry into the analytics / OLAP space.
Streaming PostgreSQL backups to S3 with pg_basebackup — stream backups directly to S3-compatible object storage, eliminating local disk staging.
Incremental PostgreSQL backups with pg_basebackup on PostgreSQL 17+, including S3 upload.
PostgreSQL database user management from the ClusterControl UI — create and edit users and roles, manage database/schema/table-level privileges with explicit object selectors, lock/disable/enable users, edit and reorder pg_hba.conf rules with change tracking, and search/filter users by role and status.
Usage metering and operator billing (Pay-As-You-Go) — hourly usage snapshots across the managed estate, cryptographically-sealed and independently-verifiable billing reports, and a new operator billing page in the multi-controller UI (generate, verify, export as JSON/CSV). Feature-flagged and off by default. See Usage Metering and Billing.
Cluster-wide database configuration management — change a parameter across all nodes of a cluster in a single action, with dynamic parameters applied at runtime (no restart required).
Multithreaded installation — cluster deployments now install and configure nodes in parallel, significantly reducing deployment times for PostgreSQL and MySQL clusters.

Scalable controllers pool — UI-driven upgrade of remote pool members from the main controller, automatic version-mismatch alarms, safer pool joins, and better resilience for large fleets.
Kubernetes database support — expanded GitOps workflows (database clusters and backup schedules delivered through Git pull requests), observability (structured logging, Prometheus metrics, default dashboards), more reliable cluster health reporting, and operator compatibility and security updates.
Specify custom pg_hba.conf rules during new PostgreSQL cluster deployments.
ProxySQL management moved from a pop-up dialog to a dedicated, shareable page.
Filter the audit log in the UI and export it.
Content-Security-Policy (CSP) headers implemented in the ClusterControl UI.
Redis/Valkey Sentinel logs are now included in Error Reports for easier failover debugging.
Choose between the release and LTS repositories when installing ClusterControl.
Specify a temporary directory when adding a new replica via backup.
Improved resilience of long-running backup jobs if the CMON database becomes unavailable mid-job.

High availability for the CMON controller pool continues to be hardened; some pool-HA capabilities are delivered incrementally across releases.

ClusterControl 2.5.0 is a standard (non-LTS) release. ClusterControl 2.4.0 remains the current long-term support (LTS) line.
Follow standard upgrade procedures as outlined in the documentation.

Maintenance Release: August 2^nd, 2026

Build:
- clustercontrol-controller-2.5.0-22492
- clustercontrol-mcc-2.5.0-1042
- clustercontrol2-2.5.0-2434
Improvements:
- The deleteCluster job now accepts a force flag that performs a full cleanup — removing the cluster configuration file from disk and clearing all related database entries — so a cluster left in an inconsistent state can always be removed. Default behaviour is unchanged, and certificates are kept untouched unless explicitly removed. (CLUS-7713)
- Default monitoring exporter flags can now be set centrally in the controller configuration, letting operators cut the volume of metrics scraped per database node instead of accepting the full default collector set on every deployment. (CLUS-8032)
Bug Fixes:
- Backups
  - Creating a cluster from a PostgreSQL backup stored in cloud (S3) storage now works. The backup is retrieved from cloud storage before the restore begins, and the restore uses an absolute path so the backup file is found. (CLUS-8218)
  - Creating a cluster from an incremental pg_basebackup backup now succeeds. The restored data directory is given to the PostgreSQL user so the server can read it and start; previously the restore was reported as failed and no cluster was created. (CLUS-8227)
  - The Default backup directory setting is now honoured for ClickHouse clusters — the configured directory is created and used instead of being ignored. (CLUS-8061)
  - The ClickHouse Backup Verification Server is now polled like any other host, so it reports a real online/offline status instead of remaining Unknown in the node list indefinitely. (CLUS-8120)
- Monitoring & Deployment
  - Newly created clusters no longer appear with Unknown host statuses for up to an hour and a half while the cluster is already running internally. The cluster-information cache refresh interval is now bounded and decays automatically, and the observed refresh interval is exposed in the cache statistics for diagnosis. (CLUS-8194)
  - A minor version upgrade of Percona/MySQL or MariaDB on a host with a custom data directory no longer breaks the server. On Debian-family systems the package upgrade could silently re-point the MySQL configuration to the distribution default — dropping the custom data directory — and then restart the service; the upgrade now protects the configuration and no longer starts the service on a failed configuration restore. (CLUS-7994)
  - ClickHouse Keeper nodes deployed without an explicit port now correctly default to the Keeper client port 9281 instead of inheriting the data-node port 9440. (CLUS-8075)
  - The controller now rejects ClickHouse import jobs that spell out more than one node. Import relies on auto-discovery from a single endpoint, and a manually enumerated topology could previously be registered without discovery. (CLUS-8084)
  - ClickHouse Keeper and replication-loss alarms are now accurate: a Keeper going offline while quorum still holds raises an alarm, the replication-health alarm names the affected replica rather than a healthy observer, and a data node that loses its Keeper session is reported as such instead of simply offline. (CLUS-8212)
- Replication & Stability
  - Adding a node to a MySQL or MariaDB replication cluster no longer stages the new replica from a shut-down former primary. After a failover the old primary could remain in the cluster with cached state that still identified it as the source, causing every add-node attempt to fail; unreachable candidates are now skipped and the current primary is selected. (CLUS-8169)
  - Scaling up a SQL Server Always On cluster no longer fails when the primary uses a non-default data directory — the new node is created with the correct data directory and log-file path. (CLUS-6875)
  - The MySQL client read and write timeouts used by the controller were cross-wired, so each was applied to the opposite operation. They are now set correctly, giving predictable timeout behaviour on controller-to-database connections. (CLUS-8214)
  - A ClickHouse cluster that has lost its Keeper quorum is now reported as failed rather than remaining operational. Keeper state is read directly from the Keeper nodes, quorum-less keepers are marked failed instead of offline, and a critical alarm names the node and the Keeper failure — even when the cluster holds no replicated tables. (CLUS-8089)
- UI
  - The Create Cluster action is now available in the actions menu for pg_basebackup backups, so a new cluster can be created from such a backup directly from the interface instead of only through the API or CLI. (CLUS-8225)

Initial Release: July 21^st, 2026

Build:
- clustercontrol-controller-2.5.0-22113
- clustercontrol-mcc-2.5.0-1010
- clustercontrol2-2.5.0-2412
- clustercontrol-proxy-2.5.0-208
- s9s-tools 1.9.2026072116

We're pleased to announce the release of ClusterControl v2.5.0, which introduces ClickHouse as a new supported database engine for analytics/OLAP workloads, delivers major PostgreSQL backup improvements, brings full PostgreSQL database user management to the UI, adds built-in usage metering with an operator billing page for consumption-based (Pay-As-You-Go) models, continues hardening the scalable controllers pool, brings back cluster-wide database configuration management, speeds up deployments with multithreaded installation, and further improves our Kubernetes database-operator support.

ClickHouse Support

ClusterControl adds ClickHouse — the high-performance, column-oriented database designed for online analytical processing (OLAP) — to its supported database engines, extending the portfolio into the analytics and data-warehouse space.

Automated deployment of ClickHouse — single-node and replicated clusters with embedded ClickHouse Keeper
Monitoring and alerting through ClusterControl's unified dashboard
Backup and restore operations
Scaling capabilities for growing analytical workloads
Import of existing ClickHouse clusters into ClusterControl management, plus s9s CLI and API support
SSL-encrypted inter-node communication with per-node certificates

PostgreSQL Backup Enhancements

A significant improvement to PostgreSQL backup workflows, focused on cloud-native, space-efficient backups.

Streaming backup to S3 with pg_basebackup — instead of writing backups to local disk first and then uploading, ClusterControl now streams pg_basebackup output directly to S3-compatible cloud storage (Amazon S3, MinIO, Google Cloud Storage in S3-compatible mode, DigitalOcean Spaces, Wasabi, and any other S3-API compatible storage). This removes the local-disk staging requirement, shortens the backup-to-cloud pipeline, and reduces the overall backup window.
Incremental backup with pg_basebackup (PostgreSQL 17+) — ClusterControl now supports PostgreSQL 17's native incremental backup in pg_basebackup, including S3 upload integration.

PostgreSQL Database User Management

ClusterControl v2.5.0 completes the PostgreSQL Database User Management initiative, giving DBAs full control over PostgreSQL users, roles, and access rules directly from the ClusterControl UI — no manual psql or config-file editing required.

Create and edit PostgreSQL users and roles, with passwords, metadata, and role assignments
View and edit database, schema, and table-level privileges, with explicit object-type selectors replacing wildcard grants
Lock, disable, and enable users across their lifecycle
Edit, override, and reorder pg_hba.conf rules from the UI, with all modifications tracked
Search and filter users by role or status

Usage Metering & Operator Billing (Pay-As-You-Go)

ClusterControl v2.5.0 introduces built-in usage metering to support consumption-based and Pay-As-You-Go commercial models.

Hourly usage snapshots collected per controller across the managed estate
Billing reports generated on demand — estate-wide or filtered by tag/cluster — with cryptographic sealing and independent report verification
An operator billing page in the multi-controller UI: view estate health, generate reports, verify seals, and export (JSON / CSV)
Feature-flagged, so it is only surfaced for operators who enable metering

Scalable Controllers Pool

Continued hardening of the scalable controllers pool, which allows a pool of CMON controllers to manage a large fleet of clusters.

UI-driven upgrade of remote pool members from the main controller, with an alarm raised automatically when a pool member's version drifts from the main controller
Safer pool joins — only stable controllers may join the pool; site information is shown on clusters deployed in pool mode
Operational resilience — retry for failed add controller jobs, and correct network grants for the cmon user on cluster deployments

Cluster-wide Database Configuration Management

ClusterControl v2.5.0 brings back cluster-wide database configuration management, familiar from ClusterControl v1.

Change the same parameter across all nodes of a cluster in a single action
Dynamic parameters are applied at runtime immediately — no per-node config edit and restart cycle required
Reduces downtime for configuration changes on production database services

Multithreaded Installation — Faster Database Deployments

Deploying a new database cluster previously installed and configured nodes one at a time, in sequence. In v2.5.0 the installation is multithreaded: independent node installations run in parallel, cutting overall deployment time — especially noticeable on larger clusters.

Applies to PostgreSQL and MySQL cluster deployments
No workflow changes required — the same deployment wizard and jobs, just faster
The degree of parallelism is tunable via the parallel_node_setup_limit setting in cmon.cnf — the maximum number of nodes set up in parallel during deployment (default: 4)

Kubernetes Database Support

Continued enhancements to production-grade deployment and management of databases on Kubernetes using database operators (CloudNativePG for PostgreSQL, MOCO for MySQL). The v2.5.0 work concentrates on GitOps-native operations, observability, and operational robustness.

Expanded GitOps workflows — database cluster deployments and backup schedules can now be delivered through the GitOps flow: manifests are proposed as Git pull requests, reviewed and merged in your repository, instead of being applied directly to the cluster. Secrets are handled safely within the Git workflow, add-on changes made in the deployment wizard propagate through Git, and the UI gains an on-demand sync from Git control.
Observability — structured logging with end-to-end request-ID correlation across the Kubernetes components, Prometheus metrics for the proxy/agent layer with a Prometheus agent on workload clusters, and default dashboards.
More reliable cluster health reporting — the agent now watches the underlying operator resources so database cluster health and phase propagate correctly to the UI, and stale cluster listings after deletions have been fixed.
Operator compatibility & supply-chain resilience — the default MySQL operator (MOCO) version is raised for compatibility with Kubernetes 1.34+, CloudNativePG operator-manifest versioning is fixed, and third-party chart dependencies and images are mirrored to the Severalnines artifact registry.
Security hardening — cluster configurations and certificates can be migrated from config files to Kubernetes secrets, and bundled components are updated to clear CVE scan findings.