Building High-Performance Analytics with Altinity Stable Builds for ClickHouse®

Recorded: Tuesday, February 7, 2023
Presenters: Robert Hodges and Vasily Nemkov

In this product-focused webinar, Altinity CEO Robert Hodges and engineer Vasili Nemkov explain what Altinity Stable Builds for ClickHouse are, why they exist, how they’re produced, and how to use them alongside upstream community builds to run ClickHouse safely at scale. Robert opens with the core problem: ClickHouse is one of the fastest-evolving database projects on GitHub—around 500 merged pull requests a month—and that velocity brings regressions, behavioral changes, and compatibility breaks that complicate long-lived production systems. Since community LTS builds offer only one year of support (short of the five-to-ten-year lifespans many enterprises need), Altinity Stable Builds extend support to three years, layer extensive QA on top of community releases, document upgrade paths, and certify compatibility with client drivers, BI tools, the Altinity Kubernetes Operator, and Altinity.Cloud.

Vasili details the release process: tracking upstream ClickHouse release branches, creating customization and release branches, running CI/CD with functional and integration tests, and moving packages through an internal QA pipeline before publishing to Docker Hub and the Altinity repository. He covers the TestFlows-based suites built for features like S3, LDAP, encryption, and backup, plus semi-manual compatibility testing against Python drivers, ODBC, JDBC, Grafana, Tableau, and Superset.

Robert closes with practical guidance: use community builds for development, switch to Altinity Stable for production, read release notes carefully, and always test upgrades on a restored copy of production data first. He previews 22.8 LTS, highlighting new SQL features like lightweight deletes and named collections and flagging compatibility concerns including the Atomic database migration, the zero-copy replication default change, and the S3 multi-part upload thread increase.

Here are the slides:

Key Moments (Timestamps)

Key moments generated with AI assistance.

• 0:07 – Introduction: Robert Hodges and Vasili Nemkov
• 1:26 – About Altinity: enterprise ClickHouse provider, Altinity.Cloud, Kubernetes Operator
• 4:11 – ClickHouse overview: real-time analytics, SQL, shared-nothing, columnar, petabyte scale
• 7:25 – ClickHouse as the center of the analytic stack: customer example (Graph CDN)
• 8:22 – Why build management matters for production ClickHouse systems
• 8:46 – Key questions Altinity Stable Builds answer: production-ready version, safe upgrades, bug support, support lifetime
• 10:16 – What are Altinity Stable Builds?
• 10:29 – Properties: production-ready, extra QA, certified upgrades, 3-year support, 100% open source
• 12:53 – Installing Altinity Stable Builds on Ubuntu: apt repository setup
• 13:31 – Installing via Docker: no “latest” tag; use specific build numbers
• 14:12 – Altinity Stable Builds available in Altinity.Cloud by default
• 14:37 – Documentation: support lifecycle calendar at docs.altinity.com
• 15:27 – Why not just use community builds? Rapid evolution, regressions, behavior changes, 1-year max support
• 17:02 – ClickHouse evolution stats: ~500 merged PRs/month, ~400 contributors/year
• 18:53 – Handoff to Vasili Nemkov: how the release process works
• 19:05 – ClickHouse upstream release process: monthly branching, LTS twice yearly (March/August)
• 21:26 – Community LTS: 1-year support window
• 21:43 – Altinity Stable: 3 additional years beyond community EOL
• 22:44 – How Altinity manages backports: customizations branch, release branch
• 23:18 – CI/CD pipeline: Docker images, functional tests, stateless/stateful/integration tests, build report
• 25:52 – QA sign-off process: automated suites, manual tests, sign-off report, production trigger
• 26:47 – Extra QA checks: TestFlows-based suites for S3, LDAP, encryption, backup, and more
• 28:45 – Semi-manual compatibility testing: Python drivers, ODBC, JDBC, SQL Alchemy, clickhouse-backup, Kubernetes Operator, Altinity.Cloud, BI tools (Grafana, Tableau, Superset)
• 29:49 – Support team certifications: bug collection, release notes, incompatibility tracking
• 30:31 – Summary of QA scope: thousands of test cases across feature areas
• 30:56 – When are Altinity Stable Builds released? Major releases when all tests pass; minor releases for severe bugs or security issues
• 31:36 – Measured release cadence: avoiding regressions, reference to 22.3 regression that was avoided
• 31:57 – Best practice: using Stable and Community builds together
• 32:04 – Dev workflow: community builds on laptop, Altinity Stable for production deployment
• 32:52 – Reporting bugs in community monthly builds helps ensure they’re fixed by LTS time
• 33:18 – Best practice: upgrading ClickHouse safely
• 33:24 – Use Altinity Stable for production; read release notes carefully
• 33:55 – Upgrade methodology: restore cluster from backup, upgrade copy, connect event streams, validate, then switch
• 35:14 – Tell Altinity support about major upgrades in advance
• 35:18 – What’s coming in Altinity Stable 22.8 LTS
• 35:30 – New features: lightweight deletes, named collections extended, insert into system.zookeeper, Google Cloud Storage improvements
• 36:51 – Compatibility concerns in 22.8: Ordinary database type deprecated, Atomic database auto-migration
• 37:47 – Zero-copy replication: now off by default (was on in 22.3)
• 37:54 – S3 multi-part uploads: more threads, potential network bandwidth saturation
• 38:27 – Roadmap: work on 23.3; security features for FedRAMP and CIS requirements
• 39:30 – Community support: Apache 2.0, 100% open source, altinitydb Slack, GitHub issues
• 40:53 – Enterprise support: SLA-backed bug fixes, security fixes, feature backports, NRE available
• 42:02 – Open-source contributions: Kubernetes Operator, Grafana plugin, Tableau connector, ODBC driver, Kafka sink connector
• 42:43 – Resources: docs.altinity.com, YouTube tutorial on building ClickHouse, Slack workspace

Webinar Transcript

[0:07] — Introduction and Housekeeping

Robert: Hello everybody and welcome to our webinar today on building high-performance apps with Altinity Stable Builds for ClickHouse. My name is Robert Hodges and I’ll be one of the presenters today. I’m joined by my colleague Vasili Nemkov. We’re both from Altinity.

This webinar is being recorded. We’ll send you a link to the recording posted on YouTube within about 24 hours, along with a link to the slides. For questions, you can post them in the webinar chat or the Q&A box — we’ll answer them as we go or at the end.

[1:26] — About Altinity

Robert: At Altinity we’re database geeks. The company is heavily engineering-focused. We’ve been working on ClickHouse since 2017 and collectively the company has centuries of experience in databases and applications. I’ve been working on databases for about 40 years.

Let me introduce Vasili Nemkov. Vasili is a ClickHouse engineer who has been at Altinity since 2018 and in the database field since 2016. He has submitted many dozens of pull requests to ClickHouse and has helped drive development in critical areas like encryption, security, and codecs.

Altinity is a service provider for ClickHouse. We were first to market in the United States and also first with Altinity.Cloud, our cloud platform running in both Amazon and Google. But we are more than just a cloud platform. Our goal is to enable you to run ClickHouse anywhere: your own racked hardware, your own cloud accounts, embedded software and appliances. We also have our newest product that allows us to manage ClickHouse clusters anywhere Kubernetes can run. We do a lot of open-source work. ClickHouse is of course a big part of that. We’re also the authors of the Altinity Kubernetes Operator for ClickHouse.

[4:11] — ClickHouse Overview

Robert: Let me give a brief background on ClickHouse in case you’re not familiar with it. ClickHouse is an analytic database particularly well suited for real-time analytics: use cases where data is arriving very rapidly, often millions or tens of millions of rows per second, where you need to respond to that rapidly arriving data quickly and also have the ability to do deeper analysis, slicing and dicing not just on newly arriving data but on data going back years and spanning petabytes.

Some of the characteristics that make ClickHouse well suited for this: it understands SQL; it runs practically anywhere, from an Android phone to bare metal to Kubernetes to cloud environments; it has a shared-nothing architecture with attached storage per server connected on a network; it stores data in columns with extremely high compression; it uses parallel execution across nodes and vectorized execution within nodes using SIMD instructions; and it scales from a laptop to clusters with hundreds of nodes. Our largest customer runs about three to four hundred nodes. And it’s open source under Apache 2.0, which broke the traditional mold of proprietary analytic databases.

[7:25] — ClickHouse as the Center of the Analytic Stack

Robert: ClickHouse has become the center of analytics stacks for many applications today. Here’s a typical example from one of our customers, Graph CDN. They provide analytics on GraphQL interfaces. Telemetry is loaded from sources like Fastly through Kafka into a ClickHouse cluster, and they have a frontend based on Next.js that presents both a GraphQL API and a user interface for querying and viewing data graphically.

As you look at these systems — the ingest at one end, the visualization at the other — ClickHouse is really the core. As a result, understanding which version of ClickHouse you’re running and being very careful about how you go about changing that version becomes a really critical issue. That gets to the heart of why Altinity Stable Builds for ClickHouse are so important.

[8:46] — What Problems Altinity Stable Builds Solve

Robert: Our goal with these releases is to answer a number of practical questions. Where can I find a production-ready version of ClickHouse? I don’t want to just download any old version from the Ubuntu repo; I want something that’s ready for deployment and will be robust and as far as possible bug-free. How do I know if it’s safe to upgrade? Upgrade is probably the most dangerous point in the lifecycle of a database. How do I get support for bugs and security problems? And how long does that support last? Analytic systems tend to have long lifetimes — many last five to ten years. We see customers still running systems first deployed on ClickHouse version 19.

[10:16] — What Are Altinity Stable Builds?

Robert: As you’re probably aware, you can go to clickhouse.com and get builds for a wide variety of platforms. Altinity Stable Builds take a different approach because we’re trying to solve a very specific problem: delivering reliable, production-ready ClickHouse builds.

At this time we build only on the Intel platform. We’re interested in ARM but there’s not enough usage in the large systems we serve at the moment. What we do is run extra QA suites on top of the tests already running inside ClickHouse. We test and document upgrades very carefully. The builds are certified by Altinity support, which collects feedback from hundreds of customers and does the legwork to make sure a build is really ready for use at scale. And then that support includes three years of maintenance on the builds. Once you deploy one of these builds, you know it’s going to be supported and we can put bug fixes into it for three years. This is all open source; we’re not creating a proprietary version of ClickHouse. Virtually all of the work we do on ClickHouse gets pushed upstream.

[12:53] — Installing Altinity Stable Builds on Ubuntu

Robert: Installation instructions are in our documentation. Here’s the Ubuntu sample: add the key, set up the apt repository, and run apt-get install. This command grabs the most recent build available in the repo and starts it using systemd. Standard Ubuntu installation, all documented.

[13:31] — Installing via Docker

Robert: We also build Docker images, which is actually what we use for our own purposes at Altinity.Cloud. We run hundreds of ClickHouse clusters in our cloud. One important thing: we do not support the docker latest tag. You really want to know what version of the container you’re getting, so you’ll need to specify a specific build number. It’s easy to find in Docker Hub. Alternatively, the same Altinity Stable Builds are available inside Altinity.Cloud accounts by default — alongside the regular community builds if you prefer those.

[14:37] — Support Lifecycle Documentation

Robert: We have documentation at docs.altinity.com with a table explaining exactly which builds are available and the support lifecycle for each. We only support certain versions — specifically LTS versions. The calendar shows when community support ends and how much longer our support runs, typically three years from release with the option to go longer by contacting us.

[15:27] — Why Not Just Use Community Builds?

Robert: A lot of people do use community builds and here’s the link for that. But there are things to know. For understanding ClickHouse versions and choosing the right one, the Altinity Knowledge Base has a detailed guide.

The key issue is that ClickHouse evolves very quickly, and as a result not all releases are stable. Any release when it first comes out will have some number of bugs. There are often regressions. And there are behavioral changes: SQL features improve but that forces you to retest apps and make changes before you can upgrade. Community support is also limited: monthly releases get bug fixes for two to three months, and LTS releases get a maximum of one year. Most real installed systems for SaaS or large internal analytics need software that’s going to be around for years.

[17:02] — What “Evolves Quickly” Actually Means

Robert: Let me show what rapid evolution actually means. The blue bars on this chart show merged pull requests per month, averaging around 500. The red line shows unique GitHub contributors per month. Over the course of 2022, ClickHouse received contributions from close to 400 people. This is one of the largest database projects on GitHub and it’s moving very quickly.

That means clickhouse is improving rapidly — role-based access control was implemented in a matter of months — but at the same time, as features go in and things are added, ClickHouse can become unstable. You get regressions. You also get behavioral changes as features evolve and become better. These changes may affect the way your application accesses ClickHouse. If you’re operating a large system, you want something that’s not constantly changing on you and that doesn’t require constant upgrades. That’s where Altinity Stable Builds come in.

[18:53] — Handoff to Vasili Nemkov: The Release Process

Vasili: Thank you. Before we dive into technical details, let me give an overview of the ClickHouse upstream release process.

ClickHouse has a main branch that receives all those hundreds of merged pull requests Robert mentioned. Once in a while, upstream cuts a new release branch. ClickHouse versions consist of the year number plus the month number, so every month they cut a new branch that has the latest master and then undergoes stabilization: bug fixes, failure fixes, and so on. Once it’s ready, a tag is put on a commit and all the installation packages and Docker images are pushed to the corresponding repositories. This happens every month.

Not all versions receive the same amount of support. Regular versions get updates for a couple of months depending on severity. Twice a year, upstream creates an LTS version, typically in March and August — hence version numbers like 20.3 and 20.8. Those receive fixes and updates for about one year.

One year is a reasonable lifespan for such a quickly evolving project. But what if you want extended stability and access to new features? Altinity Stable Builds exist exactly for this reason. After the community stops updating a given LTS version, we still support it for three more years. That means backporting important bug fixes and features from newer releases back into older LTS versions for a total of about three years of support.

[22:44] — How Altinity Manages Backports and Releases

Vasili: Let me walk through how we actually manage this. Consider version 22.8.12.7 as an example.

At that point in time, we create our own branch on top of the upstream 22.8 base. We call it our release branch — in this case releases/22.8.12. We also create a customizations branch for small non-functional modifications that allow our builds to run on our CI/CD infrastructure: adjustments to build scripts, rubber scripts, and similar things that don’t change ClickHouse’s behavior.

On top of those customizations, we backport important fixes or features, either from master, from a subsequent LTS version, or from wherever they originated. We create a PR from customizations to the release branch to see how it all goes. Once all CI/CD checks pass, we consider the build ready for our QA team.

During the CI/CD process, a lot happens automatically: it builds all the Docker images required for testing, builds the ClickHouse binary itself, runs functional tests — stateless, stateful, and integration tests — and compiles everything into a build report. Once we consider the build good enough, we hand it to QA.

[25:52] — QA Sign-Off Process

Vasili: Once QA has the build, they run multiple sheets of automated tests and perform semi-manual tests. When they’re satisfied, they sign off with a comprehensive report covering all checks and performance data. Once we’re confident the build is production-ready, we manually trigger the publishing stage and all binaries appear on our Artifactory and Docker Hub.

[26:47] — Extra QA Suites

Vasili: The QA suites we run are extensive. We have TestFlows-based test suites for almost every feature that Altinity has introduced or every important feature that matters to our customers. These suites include coverage for S3, LDAP, encryption, clickhouse-backup compatibility, and many others. You can see the full list in our build reports.

Unlike the developer-oriented tests that live inside the ClickHouse repository itself, our approach is formalized: we write a specification of the functionality, which we then translate into an exhaustive test suite covering almost every aspect of that functionality from a correctness perspective. This approach tends to find a lot of interesting things. Fixes that emerge from this testing are generally backported into ClickHouse itself and then find their way back into our LTS versions as well.

[28:45] — Compatibility Testing

Vasili: In addition to automated tests, after running the automated suites our QA team does semi-manual compatibility testing. This covers:

Compatibility with various client drivers: the Python clickhouse-driver, clickhouse-connect, ODBC, SQLAlchemy, JDBC, and others. Compatibility with clickhouse-backup. Compatibility with the Altinity Kubernetes Operator. Compatibility with Altinity.Cloud. Upgrade procedures between adjacent Altinity Stable LTS versions, for example from 22.3 to 22.8. Compatibility with BI tools including Grafana, Tableau, and Superset. All of this is collected into a comprehensive report which is used to decide whether the build is production-ready.

[29:49] — Support Team Certifications

Robert: On top of all of that, Altinity support also contributes to the certification. Some of our customers run community versions, and we collect all the incompatibilities, bugs, new features, and anything of interest that support encounters. This is compiled into a document and used to provide update notes and release notes for the new Altinity Stable version.

The amount of coverage in the QA suite is extensive. We have thousands of test cases running against these builds, so they’re quite well tested particularly in the areas we’ve worked on.

[30:56] — Release Cadence

Robert: Major releases go out when all tests pass, bugs are fixed, and the support team says it’s ready. We do minor releases at intervals, mostly when a severe bug is reported by a customer or there’s a security issue. Our goal is not to respond to every fix that lands in an LTS branch. We want to be measured in our releases because that’s the way to avoid regressions. In fact there was a significant regression that affected ClickHouse 22.3 during the past year that we avoided because our release cadence is more measured and we test carefully before anything goes out.

[31:57] — Best Practice: Using Stable and Community Builds Together

Robert: A useful pattern is to use community builds and Altinity Stable Builds together. Community builds are great for development: they have the latest features and you can get them days after they emerge. For new feature development, grab community builds, run them on your laptop, do your development. But for actual production deployment, switch to Altinity Stable Builds.

Another reason to use community builds during development: if you identify problems in the monthly builds you can post issues to us or to the ClickHouse GitHub. There’s a good chance those will already be fixed by the time the next LTS build arrives, which means the stable build you eventually deploy will already have the fixes you need.

[33:18] — Best Practice: Upgrading ClickHouse Safely

Robert: Use Altinity Stable Builds for production upgrades. Read the ClickHouse upgrade best practices carefully, and read our release notes before every upgrade. A thorough approach is also covered in the ClickHouse Upgrade eBook from Altinity.

Here’s a solid upgrade methodology: restore a cluster from backup, upgrade the restored copy to the new version, connect your event streams and applications to the new cluster (Kafka makes this easy because you can set up the new cluster to read the same production feeds), and once you’ve validated it thoroughly you can either switch everyone over to the upgraded cluster or discard it and perform the upgrade on the real system. The point is that there’s a strong testing component. If you’re on support, tell us about major upgrades in advance so we can help you decide whether there are features or bugs to be concerned about, and so we can be around to help if the upgrade goes sideways.

[35:18] — What’s Coming in Altinity Stable 22.8 LTS

Robert: Let me preview the 22.8 LTS coming out in Altinity Stable in the next few days. There are improvements across several areas.

On SQL, there’s lightweight deletes: support for the SQL DELETE command as opposed to the previous ALTER TABLE DELETE. This is an experimental feature but already usable in some cases. It gives you an additional option when you need to make data appear to disappear quickly.

On security, a big advance over 22.3 is named collections extended: key-value pairs that can include login credentials for different types of systems like S3. These have been extended to cover more data sources.

On replication, you can now insert into the system.zookeeper table rather than it being read-only.

On cloud storage, there’s better support for Google Cloud Storage, which has been a sore point. Most of the bugs are now resolved and you can safely use it through the S3 interface.

See the full Altinity Stable Build release notes for the complete list.

[36:51] — Compatibility Concerns in the 22.8 Upgrade

Robert: There are important compatibility issues to read carefully before upgrading to 22.8.

Ordinary database type deprecated: If you depend on the internal structure of how databases are stored, be very careful. There’s a new Atomic database type that supports transactional table switching and certain data upgrade patterns, but it has a different structure. Your system database will automatically upgrade to Atomic on startup.

Zero-copy replication: This is often used when storing tables in S3. It is now off by default. It was on in 22.3, so check this setting is explicitly configured for your workload.

S3 multi-part uploads use more threads: This allows faster data movement but can saturate your network bandwidth. We’ve seen problems with this in production systems that weren’t prepared, especially with systems like MinIO.

There are also a number of backwards-incompatible changes that you’ll need to review for your applications. The release notes cover all of these.

[38:27] — Roadmap

Robert: Two big things on the roadmap. First, we’ll begin working on 23.3. We’re adjusting our procedures to get LTS releases out faster — the gap on 22.8 was longer than we’d like but there were good reasons for it.

Second, security features. We’re doing new development to help customers meet FedRAMP and CIS requirements. If you have those requirements, contact us. We’ll have more to say in future.

[39:30] — Community Support

Robert: Altinity Stable Builds are 100 percent open source. Nothing is held back. You can grab them and use them for any purpose compatible with Apache 2.0 licenses, including our customizations. Our goal is to be maximally compatible with upstream ClickHouse — if you can’t move back and forth between them, that’s a bug. You can get help in the altinitydb Slack channel. You can file issues against altinity/clickhouse on GitHub. Please do not log issues against the clickhouse/ClickHouse repo for things that are specific to our builds. We fix security issues regardless of where they come from.

[40:53] — Enterprise Support

Robert: If you’re on Altinity support or Altinity.Cloud, we’ll jump on problems that require bug fixes under SLA. We fix bugs, security issues, and from time to time back-port features that are essential to operate but aren’t necessarily backported upstream. Upstream generally only back-ports bug fixes. If you have special requirements, Altinity does non-recurring engineering: we add new features and everything we develop is contributed back to upstream under Apache 2.0.

[42:02] — Open-Source Contributions

Robert: We contribute to many projects beyond ClickHouse itself: the Altinity Kubernetes Operator for ClickHouse, the Grafana plugin (Vertamedia Community plug-in, ~8 million downloads), the Tableau Connector for ClickHouse, the ODBC driver, the Kafka sink connector for replicating from MySQL, and many others.

[42:43] — Resources and Close

Robert: For more information on Altinity Stable Builds, see docs.altinity.com. There’s a section dedicated to stable builds. There’s also a YouTube video on how to build ClickHouse itself and submit PRs, done by Vasili. You can talk to us directly on Slack or use Contact Us on the website to set up a time to discuss things person to person.

That’s it for today. We hope you found this useful and we look forward to hearing from you.

FAQ

What are Altinity Stable Builds for ClickHouse and why do they exist?

Altinity Stable Builds are production-ready, long-term-support builds of ClickHouse that undergo additional testing and certification beyond what the upstream community provides. They exist because ClickHouse evolves extremely rapidly (around 500 merged pull requests per month from hundreds of contributors), which means community releases can contain regressions, behavioral changes, and compatibility breaks. Community LTS builds are supported for only one year, which is too short for most enterprise analytics systems. Altinity Stable Builds extend support to three years, add extensive QA, carefully document upgrade paths, and certify compatibility with drivers, BI tools, and Kubernetes.

How do Altinity Stable Builds relate to the upstream ClickHouse releases?

Altinity Stable Builds are based on upstream LTS releases, which appear twice yearly in March and August. Altinity takes an upstream LTS tag, creates a release branch and a customizations branch, applies non-functional build-process modifications, backports critical bug fixes and features from newer releases, runs additional CI/CD and QA validation, and then publishes the resulting packages. After the upstream community stops supporting a given LTS version, Altinity continues to provide bug fixes and security patches for up to three more years.

What additional testing does Altinity perform before certifying a stable build?

Altinity runs extensive TestFlows-based automated test suites covering individual features such as S3, LDAP, encryption, backup compatibility, and others. After automated tests, the QA team performs semi-manual compatibility testing against Python drivers, ODBC, JDBC, SQLAlchemy, clickhouse-backup, the Altinity Kubernetes Operator, Altinity.Cloud, Grafana, Tableau, and Superset. Upgrade procedures between adjacent LTS versions are also validated. All results are compiled into a comprehensive report before the build is published.

How should I use Altinity Stable Builds alongside community builds?

Use community builds for development: they have the latest features and are available quickly. Run them on your laptop while developing features that depend on new ClickHouse capabilities. If you find bugs in community monthly builds, report them so they can be fixed before the next LTS arrives. Once you’re ready for production deployment, switch to Altinity Stable Builds. This gives you a tested, documented, long-supported baseline without giving up the ability to experiment with new features during development.

What are the most important compatibility issues when upgrading to ClickHouse 22.8?

Three things to check carefully: First, the Ordinary database type has been deprecated and replaced by Atomic. Your system database will automatically migrate to Atomic on startup. If your application depends on the internal storage structure of databases, review this change. Second, zero-copy replication is now off by default (it was on in 22.3), so if you rely on it for S3-backed tables you need to re-enable it explicitly. Third, S3 multi-part uploads now use more threads, which can saturate network bandwidth. Systems using MinIO or other non-AWS S3-compatible storage may need to tune this down.

How long are Altinity Stable Builds supported?

Each Altinity Stable Build is supported for approximately three years from release. This is typically composed of the upstream community’s roughly one-year support window plus two additional years of Altinity-provided maintenance. For special cases, support beyond three years is available — contact Altinity. The documentation at docs.altinity.com maintains a current support lifecycle table for all active and upcoming versions.

© 2022 Altinity, Inc. All rights reserved. Altinity®, Altinity.Cloud®, and Altinity Stable® are registered trademarks of Altinity, Inc. ClickHouse® is a registered trademark of ClickHouse, Inc. Altinity is not affiliated with or associated with ClickHouse, Inc. Kubernetes, MySQL, and PostgreSQL are trademarks and property of their respective owners.