ClickHouse is a database for analyzing large collections of records, with data arranged by column so analytical queries can focus on the fields they need. An operator automates running its database servers on Kubernetes from a declared cluster configuration. That can reduce manual deployment work for a team operating ClickHouse. This entry compares the separately published ClickHouse and Altinity operators, whose configuration and lifecycle procedures should not be treated as interchangeable.
Two chart publishers
ClickHouse's own operator repository documents OCI charts for its operator and for declaring a ClickHouse cluster under ghcr.io/clickhouse. Altinity's separate operator is distributed as altinity/altinity-clickhouse-operator through helm.altinity.com; Altinity marks its older documentation-hosted chart repository deprecated.
Before adoption
Treat these as distinct lifecycle choices, with their own CRDs, configuration and upgrade procedures. Installing an operator is separate from creating a database. Compare topology, backup procedures and compatibility for the release you intend to run. Test ingestion, queries, replica failure and restoration with representative data. Review controller scope, credentials and persistent-volume retention before changes. Do not replace one operator with the other by changing a chart name against an existing database.
Sources & further reading
Spotted something that needs another look?
Help improve this page →