When do ClickHouse upgrades and support become a separate job?
Upgrades and ongoing support for a self-hosted ClickHouse cluster are a recurring operational job, and many teams split that job between their own staff and an outside partner. The work stops being optional the moment a version leaves the supported list, a security advisory lands, or the cluster needs a change its current release cannot deliver. ClickHouse server is licensed under the Apache License 2.0, so the software is free to run, but upgrading it, patching it and keeping it inside supported versions remain the operator's responsibility. ClickHouse Inc. sells ClickHouse Cloud as a separate, vendor-run managed service. That option is outside the scope of this page.
Four triggers usually move this work from occasional to scheduled. The first is a security advisory. ClickHouse publishes its security policy on GitHub, and that policy lists the versions that currently receive security updates. Any other version is unsupported, so an advisory against an older release leaves you exposed without a fix unless you move. The second is a version leaving the supported list. The policy names the versions that receive security updates, and the list changes as new releases ship, so your running version can age out without any change on your side. The third is a new feature need, such as a function, a table engine behavior or a setting that your analysts or pipelines now depend on. The fourth is a hardware change, such as new nodes, a new storage tier or a move to a different instance family, which often requires a server version and configuration review.
Before deciding who owns this work, confirm three facts in your own environment. Record the exact server version on every replica and every Keeper node, because mixed versions across a cluster complicate upgrades. Check the current supported list in the security policy and compare it with your fleet. Identify which release line you run: stable releases ship roughly monthly, with the three latest stable releases receiving bug fix and diagnostics backports, while LTS releases ship twice a year and are supported for one year after release. An LTS line gives a longer runway between mandatory moves, but it still requires a planned upgrade within that window. Ask who on your team owns the changelog review, since minor backward-incompatible changes can appear in any release.
An internal team can run this job well if it has a named owner, a pre-production cluster with representative data and queries, a rollback path and a calendar for reviewing each new release. The cost is recurring people time that does not stop between projects. A partner is more useful when the upgrade cadence is irregular, when the team lacks replication and Keeper experience, or when a security advisory arrives during a busy period. In either case, put the boundary in writing. Specify which releases are covered, who runs the pre-production upgrade test, who signs off on production timing, what happens if a version leaves the supported list mid-contract, and how Keeper and backup restore tests are handled during each change. Ask for these terms in any quote before work starts.
What a ClickHouse upgrade and support engagement includes
The engagement turns an upgrade into written decisions and checks. Each deliverable answers a question the operations team would otherwise settle under pressure: which versions are still covered, which release line to run, what will break, and how to return to the previous state.
Version inventory and support status
We record every ClickHouse server version in use across shards, replicas and environments, then compare each one against the versions the ClickHouse security policy lists as supported. At the time of the source review, those were 26.9, 26.8, 26.7 and 26.3, and all other versions were listed as unsupported. Confirm the list again when the engagement starts, since the policy can change, and ask for the inventory as a dated table.
Release line recommendation
Stable releases ship roughly monthly, and the ClickHouse production FAQ says the three latest stable releases receive diagnostics and bug fix backports. LTS releases ship twice a year and are supported for one year after release. We recommend a release line for each cluster based on how often your team can absorb upgrades, how much change your queries tolerate, and whether a one-year support window fits your planning cycle. Ask for the recommendation in writing with the reasons behind it.
Changelog review for breaking changes
The production FAQ advises reading the changelog before upgrading, because minor backward-incompatible changes can occur. We review every changelog entry between your current version and the target, and flag changes to default settings, SQL behavior, table engines, data formats and system tables. We map each flagged item to a table, query or client in your environment. Each flagged item becomes a test case in pre-production, so it is found before cutover.
Tested upgrade runbook and rollback
The runbook is written, rehearsed in pre-production with representative data and queries, and then used for production. It sets the upgrade order across replicas and Keeper nodes, the checkpoints where work stops, and the rollback steps for returning a replica to its prior version, with the conditions that trigger each step. Rollback relies on a backup restored in a test: the backup documentation warns that a backup never test-restored will probably not restore properly, so the runbook names the restore test and the spare cluster used for it.
Post-upgrade replication and query checks
After each replica restarts, we confirm that ReplicatedMergeTree tables show healthy replication, that the Keeper nodes have quorum, and that a recovered replica has synced missing data from a healthy peer. We then run your representative queries and compare results, error rates and latency with a baseline recorded before the upgrade started. Without that baseline, the comparison has nothing to measure against, so capture it during the pre-production run.
Documented support agreement and scope
Support scope is defined in writing before work starts. The agreement states which versions and environments are covered, which issues receive a response, how requests are raised, and what is excluded. Confirm response times and hours in the agreement itself, since they are not stated here. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or certifications; independent auditors and certification bodies do.
Stable or LTS: which ClickHouse release line should production run?
For most production deployments, the ClickHouse production FAQ recommends the stable release line. Stable releases ship roughly monthly, and the three latest stable releases receive diagnostics and bug fix backports. LTS releases ship twice a year and are supported for one year after release. The choice comes down to how quickly your team can absorb change, not to which line is more capable. Start by checking the current list on the ClickHouse GitHub releases page before you decide, because the latest stable and LTS versions change with each release cycle.
At the time of the supplied release listing, the latest stable release was v26.9.20.23-stable. The LTS lines shown were v26.8.29.10-lts and v26.3.53.4-lts, both published on October 16, 2026. Note that the ClickHouse security policy currently lists versions 26.9, 26.8, 26.7 and 26.3 as supported with security updates, and treats all other versions as unsupported. Confirm this list against the security policy in your own change plan. A cluster left on an unlisted version falls outside security coverage regardless of which release line it came from.
Several factors should drive the decision. First, measure how fast your team can absorb a monthly upgrade across all nodes, including Keeper, in a normal change cycle. If that pace is hard to sustain, LTS reduces the number of upgrade events, but you then carry a longer gap before the next line arrives. Second, check your change windows. A stable line asks for a repeatable, rehearsed upgrade routine, while an LTS line asks for a planned annual move. Third, consider your tolerance for backports. Stable users receive fixes sooner through the rolling backport window, so they need to track the changelog closely.
The final factor is testing capacity. The production FAQ advises a pre-production environment with representative data and queries, and reading the changelog before every upgrade because minor backward-incompatible changes can occur. Ask whether your platform team can run that test on each stable release, or only on each LTS line. If the answer is no for monthly testing, LTS is the safer default, provided you plan the yearly move early. Whichever line you pick, record the decision, the version in use and the date you must leave that version in your runbook.
What makes a ClickHouse upgrade cost more or take longer
This table lists the factors that most change the effort of a ClickHouse upgrade, why each one matters and what to do to keep it contained. Read it before asking for a fixed-scope quote, because the same target version can take very different amounts of work depending on your topology, data and controls. The main takeaway is that the largest drivers are usually the version gap, the changelog review and the number of environments, and these are the easiest to reduce by planning early.
| Driver | Why it matters | How to keep it down |
|---|---|---|
| Number of clusters and environments | Each cluster and environment needs its own upgrade rehearsal, rollback check and validation run, so effort grows with every extra copy. | Standardize configuration with the same deployment tooling across environments and upgrade pre-production first, then reuse the same runbook. |
| Number of shards and replicas | Rolling restarts must keep quorum and replica health at every step, and each node adds time for checks and sync verification. | Upgrade one replica at a time, confirm replication has caught up before moving on, and keep the node count documented in the runbook. |
| Keeper node layout | Keeper must stay in a healthy quorum during the upgrade, and mixed or co-located hosts add ordering risk. | Confirm the topology against the replication guide, which recommends at least three dedicated Keeper nodes in production, and upgrade Keeper in a planned order. |
| Data volume and table count | Longer merges, larger validation queries and slower restore tests stretch every stage, and many tables multiply the schema checks. | Scope validation to representative tables and key queries, and automate row count and checksum comparisons rather than checking tables by hand. |
| Custom or third-party integrations and ingestion pipelines | Ingestion tools, drivers, dashboards and custom functions may depend on behavior that changes between releases, and each one needs a test. | Inventory every client, connector and pipeline with its ClickHouse version and driver, then test each one against the target release in pre-production. |
| Version gap between current and target release | A large gap means more changelog entries to read and more behavior changes to test, and older lines may be out of support. | Check the security policy for supported versions first, then upgrade in steps where the gap is large, and plan the path before the change window. |
| Changelog items affecting queries or settings | Minor backward-incompatible changes can alter query results, default settings or syntax, which may only appear under production load. | Read the changelog for every release in the path, list affected queries and settings, and run those queries against restored pre-production data. |
| Access control and external authenticator configuration | Users, roles, row policies, quotas and LDAP, Kerberos, X.509 or JWT settings may behave differently after restart, and a failed login blocks every consumer. | Export access control definitions before the upgrade, test each authenticator path in pre-production, and keep a tested break-glass administrator account. |
| Compliance evidence requirements | Assessors may ask for change records, test results, approvals and before-and-after configuration, which adds documentation work to each step. | Agree the evidence list before the work starts, capture outputs during testing, and store them with the change ticket. Confirm the exact requirements with your auditor. |
| Change-window constraints | Short or frequent windows force more rehearsal, more rollback planning and more coordination with application owners. | Ask whether the window allows a rolling upgrade without downtime, set rollback criteria in advance and schedule Keeper and replica steps inside the window. |
How a ClickHouse upgrade moves from changelog to production
This sequence turns an upgrade from an unplanned change into a documented, tested and reversible rollout, with a recorded result at each phase. Each step produces an artifact the platform owner can review before the next step starts.
Inventory versions and confirm support status
The partner records every ClickHouse server version in use, the release line each one follows (stable or LTS), the hosts and clusters they belong to, and the Keeper nodes that coordinate replication. This inventory is checked against the vendor's security policy, which lists the versions that currently receive security updates. Any version outside that list is flagged as a priority. The output is a signed-off inventory with a support status for each node. Ask the partner to commit in writing to delivering this inventory and to naming every version that falls outside the supported list.
Review changelogs and compatibility impact
The partner reads the release notes between your current version and the target version, paying attention to backward-incompatible changes, deprecated settings, changed defaults and removed functions. Each finding is matched against the queries, table definitions, ingestion pipelines and client drivers your team actually uses. The output is a compatibility register listing each affected item, its owner and the required action, such as a query rewrite, a configuration change or a driver upgrade. Ask the partner to show how each changelog item was mapped to your workloads, not only a summary of the release notes.
Build a pre-production environment with representative data
The partner builds a non-production cluster that matches the production topology, including shards, replicas and Keeper nodes, and loads it with a representative sample of data and a recorded set of production queries. Configuration files, users, roles and settings profiles are copied so the test environment behaves like production. The output is an environment record that lists versions, topology, data volumes and the query set, with a reproducible deployment method. Ask the partner what share of production data and which query types are included, and how the sample was chosen.
Rehearse the upgrade and compare results
The partner runs the full upgrade on the pre-production cluster, following the same runbook that will be used in production, and then executes the recorded query set on both the old and new versions. Result sets, row counts, error messages and query timings are compared, and any difference is investigated and resolved before the next phase. The output is a rehearsal report with each query marked as matching, explained or fixed, and a list of runbook changes. Ask the partner to commit to the comparison method in writing and to share the raw results.
Verify backup and restore on a spare cluster
Before production changes, the partner takes a backup of the production data using the native BACKUP command, then restores it to a spare cluster and runs validation queries against the restored data. Backups stored on local disk, S3-compatible storage or Azure Blob Storage are all tested in the storage tier you use. Because replication does not protect against human error or corruption, the restore test is a separate control. The output is a restore test record showing the backup identifier, restore duration, row count checks and the validation query results. Ask the partner whether the restore test is performed on the same version you are upgrading to.
Roll out to production in replica-aware order
The partner upgrades production one node at a time, starting with the Keeper nodes and then the replicas of each shard, so that at least one healthy replica serves each shard throughout. Before each node is restarted, replication health and the absence of pending merges are checked, and the rollout stops if a node does not return to a healthy state. A recovered replica syncs missing data from a healthy replica automatically, which the partner verifies rather than assumes. The output is an rollout log with the timestamp, version and health check result for every node. Ask the partner to specify the stop conditions and who has authority to halt the rollout.
Validate production and hand over
After the last node is upgraded, the partner repeats the recorded query set against production, compares results with the rehearsal baseline, checks replication consistency across replicas, and reviews error and slow query logs for the first period of operation. Access control, settings profiles and monitoring are confirmed to work on the new version. The output is a post-upgrade validation report and a handover document that records the final versions, runbook, rollback steps and open items. Ask the partner what support period follows the handover and how issues found after the rollout are reported and fixed.
Why replicas and backups do not replace an upgrade test
Replicas and backups recover a cluster from lost hardware or lost data. They do not show whether a new ClickHouse release will run your schema, queries and ingestion correctly. Replicated tables use ReplicatedMergeTree and are coordinated by ClickHouse Keeper. According to the replication guide, a recovered replica automatically syncs missing data from a healthy replica without manual intervention. That behavior keeps a node failure from becoming a data gap, but it also copies whatever state the healthy replica holds. A bad upgrade, a faulty ALTER or an unintended DROP will move to every replica in the same way.
The backup documentation draws the same line. It notes that replication alone does not protect against human error or corruption. BACKUP and RESTORE support full and incremental backups of tables, partitions or databases to local disk, S3-compatible storage or Azure Blob Storage. The target you choose affects cost, retention, region and access control, so confirm those points with your storage and security teams before you rely on a target. Incremental backups reduce how much you copy on each run, but every increment depends on the chain before it, so the chain is only as good as the last restore you proved.
The backup documentation also warns that a backup never test-restored will probably not restore properly when you need it. Treat restore testing as a standing item in the plan, not a one-time check. Run restores on a spare cluster, ideally on the same ClickHouse version you intend to run in production and with a representative copy of the data. Verify schema, row counts and the queries your users depend on. Record how long the restore takes, because that duration, not the backup duration, sets your realistic recovery window. Name the person who owns the runbook and the person who signs off the result.
The restore test belongs inside the upgrade rollback plan. A rollback usually assumes you can return to the previous binary and the previous data state. Before the upgrade, confirm which versions are supported under the ClickHouse security policy and read the changelog for backward-incompatible changes. Then confirm with the vendor or your own pre-production tests whether the previous version can operate on data written after the upgrade. Attach a recent restore test result and a fresh backup to the change record. If restore has never been proven on your data, the rollback step is untested.
Keeper needs the same discipline. The replication guide recommends at least three Keeper nodes, on dedicated hosts in production, with about 4 GB of RAM each. Treat that as a starting baseline and confirm the sizing for your own cluster against your ingestion rate, the number of replicated tables and load tests in pre-production. Include Keeper in the upgrade test and in the restore drill, and agree the order in which Keeper nodes and ClickHouse servers are upgraded and rolled back before the change window opens.
What usually goes wrong in ClickHouse upgrades and how to prevent it
Most ClickHouse upgrade incidents trace back to a few predictable gaps: the release was out of support or unread, the test was not representative, the rollback path was missing, or nobody owned the response. Each card below names one of these failures and the step that prevents it.
Unsupported or unread release
Teams often stay on a version after the security policy stops covering it, or jump to a new stable release without reading its changelog. Check the security policy's list of supported versions before every upgrade decision, and confirm the target release is in it. Read the changelog for backward-incompatible changes that touch your queries, table settings and ingestion formats, and record which items you checked.
Testing on unlike data
A staging cluster with a few gigabytes of sample rows can pass an upgrade that fails under production volume, partition counts or merge pressure. Build the pre-production environment with representative data, including the largest tables, real retention and your heaviest queries and ingestion jobs. Compare query results and timings before and after, and run the same ingestion load you see in production.
Upgrading every replica at once
Rolling a new binary to all replicas in one window leaves no working version if the release misbehaves under real traffic. Upgrade one replica or shard at a time, confirm it rejoins and syncs from a healthy peer, and hold the rest on the previous version until the first node is stable. Write down the downgrade procedure and test it in pre-production before the window opens.
Replication mistaken for backup
Replicas protect against hardware loss, but a dropped table or bad delete is copied to every replica within moments. Schedule BACKUP jobs to storage outside the cluster, then run RESTORE into a spare cluster on a regular cadence. Treat a backup as unproven until a restore has returned the expected row counts and query results.
Default user left open
The default user starts with all permissions, and upgrade runbooks often leave it active during maintenance and after the cluster returns to service. Before the window, confirm the default user's access is restricted and that operators use named accounts with roles. Check the access control configuration after the upgrade, since rebuilt nodes or restored configuration files can reintroduce broad access.
Undefined support scope
When the agreement does not say who handles upgrade failures, Keeper issues, restore problems or query regressions, incidents stall while the client and the partner each assume the other owns them. Write the scope before work starts: which versions and components are covered, who monitors the cluster, the response path for each severity, and what happens during a failed upgrade. Ask the partner to show how that scope maps to each component.
Which ClickHouse upgrade tasks teams keep in-house and which they outsource
This table compares the upgrade and support tasks teams usually keep in-house with the ones they usually hand to a partner. The split depends mostly on existing in-house ClickHouse experience and on-call capacity, so confirm the final split in the written scope before work starts. Use it to see which skills your team would need to add.
| Task | Usually kept in-house | Usually outsourced | Skills needed |
|---|---|---|---|
| Version inventory, policy and changelog review | Track running versions, choose the stable or LTS line, and decide which release notes affect your workloads | Written upgrade policy and a changelog impact summary mapped to your queries and settings | Platform ownership, SQL, knowledge of your own workloads |
| Pre-production build | Own the test environment and the data sample used for upgrade checks | Build a pre-production cluster that matches production topology and configuration | Infrastructure as code, ClickHouse configuration, data engineering |
| Query and result regression testing | Dashboard and pipeline owners confirm that results are still correct | Build a repeatable query suite and a diff harness that compares results to a baseline | SQL, data validation, analytics domain knowledge |
| Rollout runbook | Approve the sequence, maintenance windows and rollback criteria | Draft the step-by-step runbook with checks, rollback steps and sign-off points | Change management, operations, ClickHouse replication knowledge |
| Backup restore testing | Confirm that restored data meets business needs and retention rules | Run restore tests on a spare cluster and record results and timings | BACKUP and RESTORE commands, object storage access, operations |
| Keeper and replica operations | Routine health checks, quorum status and replica sync monitoring after each upgrade | Upgrade sequencing for Keeper nodes and replicas, plus recovery drills | Distributed systems, ClickHouse Keeper, Linux operations |
| Access control and authentication changes | Decide roles, row policies and which users or services may connect | Verify that LDAP, Kerberos, X.509 or JWT settings still work after upgrade and restrict the default user | Access control, identity systems, TLS configuration |
| On-call and incident response | Primary responders for production alerts and business impact decisions | Secondary support, escalation under a support agreement, or out-of-hours coverage if the agreement includes it | Production on-call, ClickHouse diagnostics, incident command |
| Documentation for audit evidence | Keep records of approvals, change tickets and access reviews | Produce test records, configuration snapshots and runbook evidence for assessors | Technical writing, compliance evidence, change management |
How ClickHouse upgrade work changes by starting point
A cluster on a version outside the supported list no longer receives security updates, so the first task is to confirm the exact version on every host and move the cluster onto a supported line. The security policy lists 26.9, 26.8, 26.7 and 26.3 as supported, and every other version is unsupported. The further behind the cluster has drifted, the more likely it is that you will need to step through intermediate releases, and each step brings its own changelog review and its own pre-production test.
Inputs to gather before planning:
- The exact server version on every replica and every Keeper node, including hosts that were updated separately from the rest
- An inventory of tables, dictionaries, functions and client queries the applications depend on
- Changelog entries between the current and target releases, filtered for backward-incompatible changes
- A recent backup that has passed a restore test, taken before the first step
- A pre-production copy with representative data and sample queries
Confirm with your ClickHouse support contact whether the path from your current version to the target is supported in place, or whether rebuilding onto new hosts is the safer option. Also confirm the order in which Keeper nodes and replicas should be upgraded.
Before scheduling any change, check that every node reports the same version and that a restore test has succeeded on the backup you plan to rely on.
Stable releases ship roughly monthly, and the three latest stable releases receive diagnostics and bug fix backports. LTS releases ship twice a year and are supported for one year after release. Moving from a stable cadence to an LTS line trades a faster flow of changes for a longer support window on a fixed line. The move is still a version change, so it needs the same changelog review and pre-production testing as any other upgrade.
What to work through:
- Identify the current LTS lines on the releases page and note each line's publication date, since the support window starts there
- Compare the features your queries use against the target LTS line, and confirm with ClickHouse support which features are included
- Review default settings and behavior changes in the changelog for every release between your current line and the target
- Set a calendar for the next LTS move, because each LTS line has a fixed support window
- Agree on who approves the change, who owns the rollback and what evidence the approver needs
The switch is easier to justify when it rests on a query inventory and test results rather than on general preference for one cadence. Document which applications depend on recent stable features, so the owners can judge the impact.
Before approving the move, check that the target LTS line passes your full query set in pre-production with representative data.
On Kubernetes, an upgrade changes pods, persistent volumes, scheduling and Keeper placement at the same time. A restart that looks routine can remove a replica or a Keeper node from quorum if the rollout order is not controlled. Before planning, confirm how your platform's workload controller orders restarts, how storage is attached, and how backup jobs reach their destination. The specific tooling you use for deployment and rollout should be confirmed with your platform team, since the details vary by setup.
What to confirm and build:
- How restarts are ordered so that replicas and Keeper nodes keep a working majority at every step
- That persistent volume claims survive pod rescheduling, node drains and image changes
- That Keeper nodes run on dedicated hosts or under placement rules that keep them apart, in line with the recommendation for at least three nodes with about 4 GB of RAM each in production
- Image tags pinned to the exact release, with the image digest recorded in each change record
- That the deployment method you use supports the target release before you schedule the change
An upgrade is not finished when the pods are ready. Check that replicas are in sync and that queries return the expected results from every node.
Before the production change, run the same upgrade in a non-production namespace that matches the production topology, including replica count, Keeper placement and storage classes.
In an air-gapped or restricted network, the release packages, container images, documentation and backup destinations must all stay inside an approved boundary. Replication between cluster nodes remains internal, so the main constraints are how software enters the enclave, how integrity is checked, and where backups are written. Upgrades in these environments depend on an approval path that outside teams often underestimate, so the first task is to map that path with your security team.
Inputs and checks:
- The approved method for bringing release packages or images across the boundary, including media, approvals and logging
- Integrity verification of each package against the publisher's checksums, using the method your security team accepts
- Backup destinations set to local disk or to an S3-compatible or Azure Blob endpoint that sits inside the boundary, with no outbound route required
- A plan for reading release notes and the security policy from inside the enclave, since public pages may not be reachable from it
- Time allowed for the approval path, which applies to every release and not only the first one; confirm the duration with your team
Backup restore tests also need to run inside the boundary, on a spare cluster that is isolated from production.
Before the first transfer, confirm the full path for packages, release notes and backup targets with your security team, since an upgrade cannot proceed without all three.
When a cluster uses LDAP, Kerberos, X.509 certificates, an HTTP authenticator or JWT, the upgrade touches the login path for every user and service account. A login failure after a change can block applications and administrators at the same moment, so authentication must be tested on the target release before the cutover window. The external system also needs its own checks, such as certificate validity, keytab currency or token signing keys.
What to verify:
- Each authenticator tested on the target release in pre-production, including the failure path when the directory or identity provider is unreachable
- Directory endpoints, certificates and keytabs confirmed as valid for the new hosts and their names
- The mapping between groups or claims in the external system and the users and roles defined in SQL
- A break-glass administrative account, and the default user restricted as the access control documentation recommends, so that access does not depend on a single path
- Service accounts confirmed to authenticate after the change, including JWT lifetimes and key rotation schedules
Keep the mapping in version control alongside the cluster configuration, so that any change can be reviewed and reversed.
Before the cutover, run a login test for each application identity and each administrator on the target release, and confirm the break-glass account works.
What recurring ClickHouse support costs after go-live
After go-live, the recurring cost of a self-hosted ClickHouse cluster is mostly people time and standing infrastructure. The server is licensed under Apache-2.0 and carries no license fee, so the ongoing budget pays for keeping a supported version running safely. Before you approve a support budget, separate four lines: the time spent on each upgrade cycle, monitoring and on-call coverage, the infrastructure that stays on after launch, and the support agreement itself. Each line has a different owner, and each can be quoted on its own.
The upgrade cycle is the largest recurring item because the release cadence sets its frequency. The ClickHouse production FAQ says stable releases ship roughly monthly, with the three latest stable releases receiving diagnostics and bug fix backports, and LTS releases ship twice a year and are supported for a year. The security policy currently lists 26.9, 26.8, 26.7 and 26.3 as supported. Each cycle means reading the changelog for backward-incompatible changes, running the upgrade in pre-production with representative data and queries, and keeping a rollback path. Ask whether a quote covers one upgrade per cycle, a fixed number of cycles, or only on request.
Some costs run continuously. A production cluster that uses ReplicatedMergeTree tables needs ClickHouse Keeper, and the replication guide recommends at least three Keeper nodes on dedicated hosts, with about 4 GB of RAM each. Backups using BACKUP and RESTORE need storage on local disk, S3-compatible storage or Azure Blob Storage, and that storage grows with retention. The backup documentation warns that a backup never test-restored will probably not restore when needed, so a spare cluster for regular restore tests must stay available. Confirm who pays for these environments and whether they sit in your accounts.
Monitoring and on-call coverage carry the cost of staying ready between incidents. A recovered replica syncs missing data from a healthy replica without manual intervention, but someone still has to watch replication lag, disk use, merges and failed queries, and decide when a node needs attention. Decide whether your team covers this in-house, whether a partner watches it, or whether you contract a support agreement. A retainer buys defined response and ongoing upgrades, while a per-incident arrangement bills only when something breaks. Compare both against the frequency of upgrades you expect to run.
The cost comparison also depends on the delivery path. A self-hosted deployment carries the infrastructure, people and support costs above. ClickHouse Cloud is a separate managed service sold by ClickHouse Inc., so a fair comparison adds its subscription and usage charges against the full internal cost of running Apache-2.0 ClickHouse. The multi-year view is covered on the cost of ownership page. DeployOpen does not publish a price list. A quote follows from the written scope, so ask for each recurring item listed separately, with the owner, the frequency and the environments included.
What do buyers ask about ClickHouse upgrades and support?
How often does a self-hosted ClickHouse cluster need an upgrade?
The release line you choose sets the cadence. ClickHouse ships stable releases roughly monthly and LTS releases twice a year. The production FAQ says the three latest stable releases receive diagnostics and bug fix backports, and LTS releases are supported for one year after release. Stable releases mean frequent, smaller moves. LTS releases mean fewer, larger moves within a yearly window. Either way, your team should review the changelog before each upgrade, because minor backward-incompatible changes can occur. Plan your cycle so the cluster stays on a version that appears in the current security policy.
Can an unsupported ClickHouse version still run in production?
It can run, but it stops receiving security updates. The ClickHouse security policy lists versions 26.9, 26.8, 26.7 and 26.3 as currently supported with security updates. All other versions are listed as unsupported. Once fixes ship for supported versions, a cluster left on an unsupported version carries vulnerabilities that the vendor no longer patches. If a business reason keeps you on an older version, the risk acceptance should be written down, approved by a named owner, and reviewed on a schedule. Check the policy before each planning cycle, because the supported list changes as new releases appear.
What drives the duration of a ClickHouse upgrade?
Duration depends on your topology and workload, so no fixed figure applies to every cluster. The main drivers are the number of shards and replicas, the data volume and merge activity, the number of changelog items that affect your schema or queries, and the number of client drivers and applications that must be verified. Keeper version alignment and the number of rolling restarts your change window allows also matter. Pre-production testing with representative data and queries often takes the most effort. Ask any partner for a fixed-scope estimate built from your cluster layout, your changelog review and your test plan, and confirm which of those items the estimate includes.
Can our own team run ClickHouse upgrades without a partner?
Many teams can, provided they have the right skills and enough time. The work requires Linux operations, configuration management, and working knowledge of ClickHouse replication, ReplicatedMergeTree tables and ClickHouse Keeper. Your engineers also need SQL skills to test queries, the ability to read changelogs for backward-incompatible changes, and experience with BACKUP and RESTORE. A pre-production environment with representative data is essential. A practical test is to run a full upgrade in pre-production, including a restore, and record every problem. If that dry run goes smoothly, your team can repeat the process in production. If it does not, a partner can help with the first upgrade or with the parts your team lacks capacity for.
What does DeployOpen need from our team to upgrade ClickHouse?
DeployOpen works inside your infrastructure, so it needs access granted through your own accounts to the pre-production and production hosts, monitoring and logs. It needs representative data, which may be sampled or masked, plus the query set that matters to your users. Change windows should be agreed in advance, along with rollback criteria. Named owners are needed for the data, the applications that query ClickHouse, and security approval. The team also needs a restore test environment, meaning a spare cluster where backups can be restored and checked before any production change. Confirm these items in the written scope, because missing access or data is one of the most common causes of delay.
What does a ClickHouse support agreement cover and exclude?
Coverage depends on the written scope, so read it closely before signing. A typical agreement covers defined support hours, incident triage, planned upgrades, security patch application, configuration changes and agreed testing work. DeployOpen offers ongoing support, upgrades and continuous testing as retainers. Response times and hours should be stated in the agreement, and you should ask for them in writing. Exclusions usually include hardware failures, changes to your application code, data recovery when no tested backup exists, and work outside the agreed scope. Support for ClickHouse Cloud or other vendor services is a separate matter. Ask for a list of included and excluded items before comparing agreements.
Does replication mean we can skip ClickHouse backups?
No. Replication and backups protect against different failures. ReplicatedMergeTree tables, coordinated by ClickHouse Keeper, keep copies of data on several replicas, and a recovered replica automatically syncs missing data from a healthy replica. However, replication also copies mistakes. A bad DELETE, a dropped table or corruption can reach every replica. The backup documentation states that replication alone does not protect against human error or corruption. ClickHouse BACKUP and RESTORE support full and incremental backups to local disk, S3-compatible storage or Azure Blob Storage. The documentation also warns that a backup never test-restored will probably fail when you need it, so schedule regular restore tests on spare clusters.
Does DeployOpen issue audit reports or certifications for ClickHouse?
No. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those assessments and issue those documents. For a ClickHouse deployment, DeployOpen can help prepare evidence such as configuration records, hardening documentation, access control settings, change records and backup and restore test results. Before the work starts, ask your auditor which evidence they expect, in what format and for which period. Then agree in the scope which evidence DeployOpen will prepare and who on your side will review it.
How DeployOpen scopes, delivers and supports ClickHouse upgrades
DeployOpen plans and delivers ClickHouse upgrades inside your own infrastructure, starting from a written, fixed-scope agreement. Each upgrade is rehearsed in pre-production with representative data and the queries your teams run, and the changelog is reviewed before anything reaches production. Ongoing support is available as a retainer for version tracking, patch reviews and scheduled upgrades.
How we scope
- Written scope names the current version, target release line and whether stable or LTS applies.
- Scope lists every cluster, replica, Keeper node and ingestion path that the upgrade touches.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we build
- Upgrade rehearsal runs in pre-production with representative data and the queries your teams actually run.
- Changelog review checks minor backward-incompatible changes against your schemas, queries and settings before cutover.
- Replica-by-replica rollout keeps replicated tables and Keeper quorum available, with checks after each step.
How we hand over
- Written runbook records the version map, upgrade steps, rollback decisions and post-upgrade checks.
- Restore test results from a spare cluster are documented, because the backup documentation advises regular restore tests.
- Your team receives the upgrade record, configuration changes and the list of supported versions to track.
How we support
- Ongoing support is available as a retainer for version tracking, patch reviews and scheduled upgrades.
- Track the supported release lines in the ClickHouse security policy and plan moves before any line goes unsupported.
- Confirm in the written scope who handles security patches, escalations and response windows before signing.
