ClickHouse Support Options: ClickHouse, Inc. or Independent

ClickHouse support comes from ClickHouse, Inc. for ClickHouse Cloud and for self-managed customers under a support agreement, and from independent providers for everything that policy excludes: older releases, modified builds, third-party hosting and the operational work around the database. The vendor's supported-version window is short, which is what most teams discover too late.

What ClickHouse, Inc. supports

Support is included with a ClickHouse Cloud subscription, and self-managed customers can buy it under a separate agreement. The ClickHouse Support Services Policy (effective 24 June 2026) gives unlimited support incidents and contacts with target initial response times. Customers without a subscription are pointed to the community Slack and other community resources. Each support case is assigned a severity level, from a production system that is down to a general question, and the initial response times depend on that severity and on the support tier. The software itself stays open source under the Apache 2.0 license whichever route you take.

The supported-version window

ClickHouse ships a new open-source release every month. For the open-source software the policy supports:

• the current regular stable release and the two before it, for a minimum of three months from the current release, and
• the current long-term supported (LTS) release and the one before it, for a minimum of one year. LTS releases carry LTS in the release number and are typically the March and August releases.

For ClickHouse Cloud and the other vendor-operated products, only the current release is supported. In practice a self-managed cluster that has not been upgraded for a year is probably outside vendor support even with a contract.

What the vendor policy excludes

The same policy lists where ClickHouse has no obligation to help: software that has been modified by anyone other than ClickHouse, problems caused by third-party software or hardware, open-source ClickHouse hosted by a third party offering it as a service, and any deployment not running a supported version. Issues in experimental or beta features are handled at the lowest severity. None of that is unreasonable for a vendor. It does describe a large share of real production estates.

Where independent ClickHouse support fits

• Self-managed clusters on older releases that cannot be upgraded on the vendor's cadence.
• Operational problems rather than product defects: too many parts from unbatched inserts, memory limits hit by a single join, replication queues stalled behind Keeper, mutations that rewrite terabytes.
• Schema design and query optimization, where the fix is a sorting key or a materialized view, not a patch. Most slow dashboards on a real-time analytics workload are this.
• A second opinion that is not selling you a cloud migration.

Several firms offer this, Altinity being the best known. For teams running ClickHouse on bare metal, virtual machines or Kubernetes, commercial enterprise support from an independent provider covers the ClickHouse cluster as it is actually deployed. AceMQ provides 24/7 ClickHouse support for self-managed clusters and ClickHouse Cloud, with a 15-minute emergency SLA and named senior engineers. Examples: a too-many-parts remediation and schema design for a high-cardinality workload.

The ClickHouse incidents that actually page people

• Too many parts. Inserts arrive as many small batches, each creating a part, and merges cannot keep up. ClickHouse first delays inserts and then rejects them. The fix is batching on the client, asynchronous inserts, or a buffer in front, and occasionally a partitioning key that was far too granular.
• Memory limit exceeded. A join with a large right-hand table, a GROUP BY on a high-cardinality key or a query without a useful filter exceeds its memory limit and fails, or takes a node down with it. External aggregation settings help. Schema and query changes solve it.
• Replication queue stalls. Replicated tables depend on ClickHouse Keeper or ZooKeeper. When the coordination service is slow or a part is missing on every replica, the queue stops moving and replicas diverge.
• Mutations that never finish. ALTER TABLE UPDATE and DELETE rewrite whole parts. A mutation on a multi-terabyte table can run for days, block merges and fill disks. Lightweight deletes and a design that avoids updates are the better answer.
• A sorting key chosen on day one. The ORDER BY key determines what ClickHouse can skip. A key that does not match the dominant query filter makes every query a near-full scan, and changing it means rebuilding the table.

Keeping pace with a monthly release cadence

ClickHouse publishes a new stable release every month and an LTS release roughly twice a year, and vendor support follows those lines closely. For a self-managed cluster the practical approach is to run LTS releases, upgrade on each new LTS, and treat that as a scheduled, rehearsed event. Upgrades are rolling and usually smooth, but settings defaults change between releases, and the compatibility setting exists so that query behaviour can be pinned while the binary moves forward. Test the real query workload on a replica running the new version before the rest of the cluster follows, and read the backward-incompatible changes for every release in between.

Choosing between vendor and independent ClickHouse support

If you are on ClickHouse Cloud, vendor support is included and is the right first call. If you self-manage and keep pace with LTS releases, a vendor agreement covers product defects well. If you self-manage and cannot upgrade every year, or your incidents are about how the cluster is used rather than what the software does, you need support that covers the version and the workload you actually have.