Announcing Altinity Stable Builds for ClickHouse®

ByRobert Hodges
Subscribe
Altinity Stable Builds

Today we are pleased to announce Altinity Stable builds for ClickHouse. Altinity Stable builds are binary builds of ClickHouse from the Altinity GitHub repo, built using our US-based build pipeline. Stable builds: 

  • Are certified as ready for production use
  • Are 100% open source and 100% compatible with community ClickHouse builds
  • Provide up to 3 years of extended support for P0/P1 bugs and security vulnerabilities
  • Are validated against client libraries, visualization tools and utilities like clickhouse-backup
  • Are tested for cloud use including Kubernetes

Altinity Stable builds are the natural evolution of our popular Altinity Stable release label, which designates community builds that are ready for production usage. We have taken the extra step of building them so we can provide better support to users. 

Altinity Stable builds do not compete with existing ClickHouse community builds. If you are using ClickHouse community builds, you do not have to change a thing. We use them, we love them and we support them at Altinity. You can switch from community builds to Altinity Stable builds and vice-versa. However, to get quick bug fixes or to get them after the community support interval expires, you’ll need to use Altinity Stable builds.

The first Altinity Stable builds cover ClickHouse 21.8, the latest community long-term support (LTS) version. We offer RPM packages, Debian packages and Docker images. If you just want a build, you can skip the rest of this article and head directly to the build documentation. 

How Altinity Came to Create Altinity Stable Builds

Altinity has helped hundreds of companies design and operate ClickHouse since 2017. We provide recommendations on ClickHouse versions to use as well as bug fixes when problems arise. We also operate Altinity.Cloud, which runs managed ClickHouse on AWS. We have had a professional interest in builds and build versions for many years, as shown by the following history.

In May 2017, Altinity introduced RPM builds of ClickHouse.  These provided RPMs at a time when they did not exist in community builds.

In November 2018, we introduced the first Altinity Stable release certification, which designates specific ClickHouse community versions that are ready for production use. Each Stable release designation includes a list of notable changes, plus notes on operation and guidance on upgrading from previous versions. 

In September 2019, we began to issue patches of ClickHouse to Altinity customers and shortly thereafter expanded our distribution to include a repository specifically for stable releases. 

Finally, as a result of our work on the ClickHouse Kubernetes Operator as well as our Altinity.Cloud managed ClickHouse service in October 2020, we have moved into container builds. Our own ClickHouse servers are exclusively containers managed on Kubernetes. 

Altinity Stable builds complete the process by providing Altinity-built software in a unified repository. This allows us to provide long term ClickHouse support with bug fixes, operate Altinity.Cloud, and generally stay sane. We are sharing the results with the ClickHouse community. 

Altinity Stable Builds and ClickHouse Community Builds

ClickHouse community builds are geared toward rapid evolution. Each month there is a new build version, for example 21.9, which receives a month of support before development moves on. Twice a year there are Long Term Support (LTS) builds with a full year of community support. While every effort is made to ensure stability, not every community build is suitable for deployments in live application. 

In contrast, Altinity Stable builds are geared toward production stability. Each stable build is ready for production use and supported for up to 3 years. We make every effort to ensure that Altinity Stable builds are 100% compatible with community ClickHouse behavior while ensuring production readiness. 

For Linux users, this is like the difference between Fedora and Red Hat Enterprise Linux. Our goal is to keep Altinity Stable builds as close as possible to ClickHouse community builds but no closer. 

  • Altinity Stable builds are based on ClickHouse Long Term Stable (LTS) releases, which appear twice a year. 
  • Each Altinity Stable build has a corresponding tag that makes it easy to see the upstream ClickHouse tag on which it is based. 
  • Altinity Stable builds are equivalent to the upstream ClickHouse base plus unmerged bug fixes. Wherever possible we merge bug fixes upstream. 

When starting new development you can choose between community builds, which have the latest and greatest features, and Altinity Stable builds, which are ready to deploy in production and have longer maintenance. You can start with one and switch to the other as needed. It’s your choice. 

How Do We Create Altinity Stable Builds?

Altinity Stable builds leverage the base build procedure for ClickHouse. Here’s how the CI/CD pipeline works for the current Altinity Stable build for ClickHouse 21.8. 

  1. Merge from the community repo to the Altinity ClickHouse fork, and apply Altinity custom patches when needed. Patches are open for anyone to review and usually contain fixes that weren’t backported [yet] into corresponding community builds. 
  2. Build ClickHouse binaries. 
  3. Build distributions, including RPM and .deb packages. 
  4. Run regression tests. 
    1. Built-in tests included in the ClickHouse GitHub sources
    2. Altinity TestFlows tests, which provide in-depth tests for RBAC, S3, LDAP, and other features validated by Altinity. 
  5. Run tests on ecosystem software required by ClickHouse applications. 
    1. Prominent client libraries like Python clickhouse-client. 
    2. BI tools (including Grafana, Superset, and Tableau) as well ingest sources like Kafka and S3. 
    3. Operation on Kubernetes.
    4. Clickhouse-backup. 
    5. Upgrades from previous stable builds as well as published Altinity Stable releases.
  6. Sign build products using Altinity-managed GPG keys to ensure users can verify build provenance. 
  7. Distribute built products through a secure and open Altinity-hosted repository.

The ClickHouse build procedure and signing runs on machines hosted in the USA. 

SLA for Altinity Stable Builds and How to Report Problems

We produce new stable builds to pick up upstream changes, so you can expect them to arrive whenever there are important changes in ClickHouse or when we correct problems that affect customers. 

Once community maintenance expires, we update builds as needed to address high severity (P0 and P1) bugs encountered by customers as well as serious security vulnerabilities. 

If you are a customer, we can share more information about security policies in case your Infosec team needs to approve use of ClickHouse. 

If you encounter a problem with an Altinity Stable Build, please file a Zendesk support ticket (for customers) or report an issue on the Altinity/ClickHouse GitHub repo. You can report issues on the ClickHouse repository, but it is your responsibility to ensure they can be reproduced in community ClickHouse. 

Where to Find More Information

Check out our documentation page for Altinity Stable builds download instructions. 

You can also reach us by sending email to info@altinity.com or using the Contact Us form on the Altinity website. We’ll be happy to explore how Altinity Stable builds can help your applications. 

Share