Introduction to Altinity.Cloud: A platform for building real-time analytics on ClickHouse®

Recorded: Thursday, December 08, 2022
Presenters: Robert Hodges & Alexander Zaitsev

In this product introduction webinar, Altinity CEO Robert Hodges and CTO Alexander Zaitsev walk through Altinity.Cloud—the managed ClickHouse service—from first principles to day-two operations, combining a live demo by Alexander with a structured feature walkthrough by Robert. Alexander opens by creating a running cluster in under five minutes, showing how to choose a ClickHouse version, node type, and storage, and configure shards and replicas. He then demonstrates the rescale operation—adding a replica with zero downtime—and the uptime schedule feature, which automatically stops compute when a cluster is idle and can run on a recurring weekly schedule to cut development costs.

Robert then explains the architecture: Altinity.Cloud runs inside a VPC backed by a Kubernetes cluster using the Altinity Kubernetes Operator, with every service—ClickHouse, Grafana, Prometheus, the edge proxy—being 100% open-source and Apache-licensed. He covers Altinity.Cloud Anywhere for customers who want managed ClickHouse in their own VPC or Kubernetes cluster, the rationale for choosing between community and Altinity Stable Builds, and the mechanics of horizontal and vertical scaling.

He also tours day-to-day operations: the explore tab for ad hoc queries, creating users with SQL RBAC, backups, rolling upgrades, monitoring panels, and security controls, including TLS, IP whitelisting, VPC endpoints, and the Altinity access control dial that can restrict support access to read-only or none. The session closes with the enterprise support model—Slack for everyday questions and Zendesk for production incidents—spanning schema design, performance tuning, upgrades and capacity planning, and Kafka/BI integrations.

Here are the slides:

Key Moments (Timestamps)

Key moments generated with AI assistance.

• 0:15 – Introduction: Robert Hodges and Alexander Zaitsev
• 1:47 – Altinity.Cloud overview: zero-maintenance SaaS for ClickHouse with enterprise DBA support
• 3:51 – Altinity overview: Enterprise ClickHouse provider, Altinity.Cloud, Kubernetes Operator
• 4:39 – ClickHouse overview: SQL data warehouse, columnar, parallel, petabyte scale, Apache 2.0
• 7:31 – Handoff to Alexander Zaitsev for live cluster creation demo
• 8:06 – Demo: cluster dashboard, launching a new cluster
• 8:20 – Choosing ClickHouse versions: Altinity Stable Builds vs community builds
• 8:43 – Node type, storage size, volume type, shard count, replication options
• 9:40 – Endpoint configuration: public vs private access, protocols (binary, HTTP, MySQL)
• 10:41 – Monitoring integrations: Datadog
• 11:09 – Uptime schedule: auto-pause on idle, workday/hours schedule
• 12:10 – Starting a four-node cluster: billing model (pay-as-you-go, no charge when stopped)
• 12:33 – Rescale demo: adding a replica to a running cluster with zero downtime
• 13:22 – Other rescale options: node type, storage size
• 14:07 – Cluster management UI overview: stop/resume, configuration, database explorer
• 15:31 – Alerts, logs, monitoring data
• 16:12 – Handoff back to Robert Hodges
• 17:02 – What is an environment? VPC + Kubernetes cluster on Amazon EKS or GCP
• 17:40 – Altinity.Cloud Anywhere: managing ClickHouse on your own Kubernetes cluster
• 19:46 – What runs inside an environment: Altinity Operator, Grafana, Prometheus, Edge Proxy, block storage
• 21:16 – All services are 100% open source and Apache-licensed
• 22:25 – TLS requirement: SNI support required for all client connections
• 23:17 – Cluster dashboard: node types, storage, connection details, DNS provisioning
• 29:15 – Explore tab: ad hoc query editor, node selection
• 30:10 – Creating users: file-based user dialog, enabling SQL RBAC
• 31:36 – Creating additional users via SQL RBAC commands
• 33:28 – Explore tab features: schema browser, workload analyzer, DBA tools
• 35:18 – What a ClickHouse server node looks like: VM + network-attached block storage
• 35:32 – Restarting a cluster: rolling restart, query draining
• 36:40 – Stop and resume: scaling to zero compute, keeping block storage
• 37:20 – Resuming with a different node type: cost-efficient dev/test scaling
• 37:40 – Uptime schedule: two-hour inactivity timeout for development
• 38:22 – Rescaling in detail: horizontal (shards/replicas) and vertical (node type, storage)
• 39:25 – Storage expansion: EBS volume stacking on Amazon, GCE volume extension on GCP
• 40:31 – Schema propagation when adding replicas or shards
• 41:35 – Backups: automatic every 24 hours, 7 days retention, manual backup option, restore
• 42:33 – Upgrade and downgrade: rolling upgrade, version selection, compatibility warnings
• 43:33 – Best practices for upgrades: Altinity Stable Builds, upgrade notes, testing on restored backup
• 46:10 – Monitoring panels: cluster metrics, top queries, logs; Grafana integration
• 47:06 – System status page
• 47:47 – Security: TLS encryption, IP whitelisting, VPC endpoints
• 49:37 – Altinity access control: no-access / read-only / full access dial
• 50:36 – Inviting users to the organization
• 51:21 – Enterprise support model: Slack, Zendesk, scope of support
• 54:38 – How to get the most out of support: advance notice for upgrades, quota raises, proactive contact
• 55:40 – Getting started: free two-week trial for Altinity.Cloud and Altinity.Cloud Anywhere

Webinar Transcript

[0:15] — Introduction and Housekeeping

Robert: Hi everybody. Welcome to our webinar on Altinity.Cloud. My name is Robert Hodges. I’m joined by Alexander Zaitsev. We’re going to give people a couple of minutes to come in and then dive in.

This is a Zoom webinar. Please post questions into the Q&A box or the chat — either way we’ll take them as we go or at the end. Everything is being recorded and slides will be posted, so you’ll get a video link and a link to the slides after the talk.

[1:47] — What Is Altinity.Cloud?

Robert: Altinity.Cloud is a SaaS — software as a service — for ClickHouse. The idea is that it runs in the cloud, completely automates operations, and has baked-in enterprise DBA support. It’s not just a panel where you click a few buttons and you’re on your own when something goes wrong. We have a highly expert support team who have run large clusters and worked with ClickHouse for many years. Their role is to help you come up to speed quickly on ClickHouse and to cover you when unexpected things happen.

Altinity.Cloud is optimized for real-time analytics — particularly SaaS analytics systems designed to operate at scale across many tenants constantly. This calls for a special architecture focused on high-performance storage and compute, and a cost model suited for those businesses.

Altinity.Cloud supports practically any version and feature of ClickHouse, including experimental ones. It really runs ClickHouse the same way you do on your laptop. If you run in our SaaS, you can run in any Amazon or GCP region. Or you can provide your own Kubernetes cluster and we will manage the ClickHouse clusters there.

[3:51] — About Altinity

Robert: Quick introduction: we are an enterprise provider for ClickHouse. We have enterprise support and cloud services that run ClickHouse, which is of course the topic of this talk. We are authors of a number of open-source packages, the most significant for this talk being the Kubernetes Operator for ClickHouse — the first operator ever written for a data warehouse in Kubernetes and still one of the most popular database operators on GitHub.

[4:39] — ClickHouse Overview

Robert: Just in case anyone on this call doesn’t know what ClickHouse is: it’s a SQL data warehouse. It runs on everything from bare metal to the cloud. It’s like MySQL but able to do very scalable analytics — shared-nothing architecture, columnar storage, very efficient parallel and vectorized execution, scaling from a laptop with a few megabytes of data all the way up to clusters with 500 nodes dealing with tens of petabytes. It’s open source under Apache 2.0, and there’s a whole ecosystem of similarly licensed software around it. It’s a great piece of software for building real-time analytics stacks that are completely open source.

[7:31] — Live Demo: Starting a Cluster

Robert: Let’s switch to a demo so you can see it in action. Alexander, over to you.

Alexander: Thank you, Robert. Can you see my screen?

Robert: Yes, perfectly.

Alexander: Great. This is the cluster page — your dashboard when you manage your ClickHouse clusters. I’ll start a cluster in real time. We’ll call it “webinar 2.”

[8:20] — Choosing ClickHouse Versions

Alexander: Here is where you pick different versions — Altinity Stable Builds or community builds. We’ll discuss why and when you need each one a bit later. Once you configure the version, you select what kind of resources you want to throw at this ClickHouse instance.

There are quotas configured for your account — a safety net that protects users from doing expensive things by accident. Those quotas depend partly on what the cloud provider allows, and they’re definitely not fixed. You can raise them if needed.

Storage size, number of volumes — we support multi-volume configurations, which makes sense in certain setups. Volume type: I’ll go with gp3. Number of shards: unlike some other hosted services, we support sharding. I’ll start with one shard for now, and we can go with replication. You can start without replication or with replication, and we manage ZooKeeper automatically under the covers.

For this exercise, let’s start with replicas. This is your endpoint — created inside the Altinity.Cloud domain. But if you’re an Altinity.Cloud customer, you’ll get a dedicated third-level domain, and all your clusters will use the fourth-level domain under that.

We can turn the endpoint from public to private. Most of our customers actually run private access. We support the binary and HTTP protocols. Some clients also use the MySQL protocol, though that requires some additional configuration due to MySQL protocol limitations.

We also have Datadog integration available for customers who want monitoring integrated with external systems.

[11:09] — Uptime Schedule

Alexander: One interesting feature is the uptime schedule. In a nutshell it allows you to stop a cluster automatically when it’s idle. For development, you might forget to stop it — we can stop or pause it automatically for you. You can start it again at any time. Or you can define a schedule: for example, on workdays you want the cluster available when you come to the office, and shut down automatically when you go home. For now we’ll leave it as always-on.

[12:10] — Starting the Cluster

Alexander: So this is a fairly large cluster with four nodes — that does drive cost. But let’s start it. The billing model for Altinity.Cloud is very simple: you pay as you go. You get the bill from AWS and we proxy it to you with some extra. If the cluster is not running, you don’t get billed.

[12:33] — Rescale Demo: Adding a Replica

Alexander: While webinar-2 is starting, let me show another cool feature: rescale. I can use this cluster which I started earlier. I started it with only one shard and one replica, but later decided I do want replication. I can just go here and add another replica. I can also change the node size or node type — I’m not going to do it right now, but you can do it anytime, scaling down or scaling up to bigger node types.

Storage size: this is probably the most frequent operation our customers do — increasing storage, because data grows. On-prem you’re limited by your hardware. In the cloud there are no limits. You can go from 30 gigabytes to 30 terabytes, usually in several steps.

So I’m adding a replica, and the cluster will be online the whole time. Adding a replica does not require downtime. It happens under the covers. The resources are provisioned, and in a few minutes the replica will be up and running.

[14:07] — Overview of Cluster Management Features

Alexander: Generally your experience when starting a cluster has lots of different features. Very quickly: stop and resume lets you pause the cluster and resume it anytime. Configuration supports any server settings, any profile and user settings — no limits on that. We have a built-in database explorer for running queries, checking schema, analyzing workloads, and analyzing data consistency. Alerts, logs, and monitoring data help you operate the system and detect problems. At this point I’ll hand it back to Robert.

[16:12] — Handoff to Robert Hodges

Robert: Thank you, Alexander. Let me now dig more deeply into some of the things Alexander described.

[17:02] — What Is an Environment?

Robert: The cluster panel that Alexander showed you represents what we call an environment. If you dig in, an environment is actually a VPC — in this case running on Amazon using EKS, which is the Amazon managed Kubernetes service. Inside that VPC is a Kubernetes cluster. When we provision a tenant, for example when you start a free two-week trial, the first thing we do is set up a VPC with all associated networking, provision a Kubernetes cluster inside, and as soon as that’s running you can log in and begin provisioning ClickHouse clusters.

This same pattern works on GCP. You simply pick which region you want to run in and we provision there. We support practically any cloud environment and any region.

[17:40] — Altinity.Cloud Anywhere

Robert: Not only can you run in Amazon and GCP regions in our account — you can also do it in your own account. We call this Altinity.Cloud Anywhere: running in your own VPC. What you do is tell us where your Kubernetes cluster is, set it up in your own VPC (running EKS is a common way), register it with Altinity.Cloud, and at that point we build a secure tunnel to your environment. That tunnel can only see inside specific namespaces in the Kubernetes cluster. We then manage your clusters there. You own the data, you have the code, you can meet your compliance requirements, and it’s tied to your own networking.

[19:46] — What Runs Inside an Environment

Robert: When we set up one of these environments it’s a Kubernetes cluster. We connect to it over a secure networking link — private networking for our own VPCs, or the Altinity Connector for anywhere deployments. Inside the environment you have ClickHouse, the Altinity Operator that allows us to provision and manage ClickHouse clusters on Kubernetes, Grafana and Prometheus for metrics collection and monitoring, and something called the Edge Proxy that takes care of routing traffic from the cloud provider load balancer. Services that need storage will allocate block storage, and object storage buckets are used for backups.

If you run Altinity.Cloud Anywhere, you can actually log into your Kubernetes cluster and see most of these services running yourself.

[21:16] — Everything Is Open Source

Robert: One of the things that’s really important about Altinity.Cloud and where we differ from just about every other cloud provider: we operate Altinity.Cloud exactly the way you do it at home. The software running in the stack — ClickHouse, the monitoring services, backup, the Altinity Operator — these are all Apache-licensed or under similar permissive licenses. You could actually run this yourself, and if you ever decided to move on-prem and manage it directly you could do that. We even have a blog article that describes exactly how to do that. And you can run any version of ClickHouse and use virtually any feature including experimental ones.

One technical requirement: applications connecting to Altinity.Cloud clusters must support TLS and a feature of TLS called Server Name Indication (SNI). That is the protocol that allows us to route through a single endpoint to whichever server you’d like to be talking to. Other than that, basically everything that works on your laptop will work in Altinity.Cloud.

[23:17] — Cluster Dashboard Details

Robert: Let me walk through some of the commonly used features. On the cluster dashboard there’s a lot of interesting information. The node type is backed by a VM. We are not sharing these VMs with other ClickHouse servers and certainly not with other tenants — it’s completely isolated. You can see the instance family, storage, and number of nodes.

[28:47] — Getting Connection Details

Robert: The connection details link pops up everything you need to connect to the cluster, including the DNS name. We provision DNS for the cluster endpoint and for each individual node so your application can connect to a specific node. That information allows you to connect any development tool — for example DBeaver works perfectly to connect to Altinity.Cloud.

[29:15] — Explore Tab for Ad Hoc Queries

Robert: For quick queries you can use the explore tab on the dashboard. It gives you a query editor. When it says “node: any” it means it’s going to the cluster endpoint and will pick one node. You can also select specific nodes. This is handy for quick ad hoc queries without setting up an external client.

[30:10] — Creating Users with SQL RBAC

Robert: To create users, go to the configure tab and click users. A modal dialog appears where you fill in the user details — if you’re a ClickHouse user you’ll recognize this as exactly what appears in file-based user definitions in ClickHouse. We don’t recommend doing a huge number of file-based users. What we strongly recommend is creating one login — let’s call it root — and enabling the switch called “access management.” This allows that user to issue SQL RBAC commands:

CREATE USER myuser IDENTIFIED WITH sha256_password BY ‘mysecretpassword’;

GRANT SELECT ON mydatabase.* TO myuser;

This propagates instantly and is totally under the control of your application. File-based users typically take a minute or two to propagate because Altinity.Cloud is updating the filesystem on each ClickHouse node where the XML user file is stored. SQL RBAC propagates immediately.

[32:28] — Explore Tab: Schema, Workload, DBA Tools

Robert: The explore tab has a bunch of useful stuff for getting started. The schema browser lets you look at data sizes, numbers of partitions, bytes per row, and compression ratios instantly. The workload tab shows what queries you’re running and how long they take. And there are DBA tools for more advanced use cases like detecting detached parts and other cluster health checks.

[33:24] — Open Source Analytics Ecosystem

Robert: ClickHouse has an enormous ecosystem of open-source analytics software. This includes event streaming tools, ETL/ELT including Apache Spark (also widely used for ML/AI), visualization tools (Superset, Grafana, Redash, and many more), and client libraries for practically every language. You can build the entire analytics stack using open source, which means you can see what’s going on, you have control, you’re able to move it to different environments, and you future-proof your applications in fundamental ways.

[35:18] — What a ClickHouse Node Looks Like

Robert: Every ClickHouse server pod is backed by a VM with network-attached block storage — and optionally object storage. To restart the cluster go to Actions and hit Restart. By default Altinity.Cloud does a rolling restart and will let queries finish before restarting each node. This means if you have long-running queries the restart will take longer — which is actually a good thing, as it avoids disrupting in-flight work.

[36:40] — Stop, Resume, and Uptime Schedule

Robert: Turning off compute is a great feature of Kubernetes: we simply make the pods go away but keep the network-attached storage. You can scale to zero manually at any time. We do this very commonly for development.

A particularly useful feature is that when you resume your cluster you can change the node type. You could be developing with a very small node type, pause the cluster, and when you resume maybe you want to do a performance test, so you select a much larger node type — say 32 vCPUs. This is very handy for jumping back and forth between different node sizes depending on what you’re doing.

For development systems not used 24×7, set an uptime schedule with a two-hour inactivity timeout. If you go to lunch or forget about a cluster, the compute turns off automatically. You can also set a recurring schedule — define which days and hours during the week the cluster should operate. This is one of the most important ways to control costs on the ClickHouse pricing calculator.

[38:22] — Rescaling in Detail

Robert: Rescaling works well partly because of how Kubernetes works and the fact that block storage can be reattached to different VM sizes. On the rescale page you have two options: scale horizontally (add or remove shards and replicas, as Alexander showed) or scale vertically (change the node type, make it larger or smaller).

You can also add to storage. You cannot reduce storage once it’s allocated, but you can always increase it. This is probably the most common scaling operation because data tends to grow over time. What’s going on under the covers: when you change the VM size, the old VM terminates and a new one is provisioned with the block storage reattached. When you extend storage on GCP we extend the individual volume. On Amazon, because you get better performance with multiple EBS volumes attached to a VM, we tend to stack volumes — letting a volume grow to a certain size and then adding a new one alongside it.

When adding replicas: the Altinity Operator updates the cluster metadata to announce the new replica names, then automatically provisions the schema on the new replica. Any replicated tables will be defined on the new replica automatically. Once connected, ClickHouse replication populates the table data. When adding a new shard, the schema is also automatically provisioned — but note that ClickHouse does not automatically rebalance data across shards. You’ll need to move data manually. We can help you with that.

[41:35] — Backups, Upgrades, and Downgrades

Robert: Backups run automatically every 24 hours with seven days of retention by default. You can restore any backup at any time by going to Actions and clicking Restore Backup. You can also kick off a manual backup anytime if you’re about to do something that makes you nervous. Depending on data size, backups can take a while to run.

For upgrades and downgrades, there’s a rolling upgrade operation that completely automates the process. Go to the cluster, pick Upgrade, choose between Altinity builds and community builds, select the target version, and it’s a rolling upgrade — as long as you have replicas it will not take your system offline. Downgrade is also available; we’ll show a warning if the downgrade might cause data compatibility problems.

[43:33] — Best Practices for Upgrades

Robert: Upgrade best practices on Altinity.Cloud, explained further on the Altinity.Cloud FAQ page:

First, use Altinity Stable Builds for production. Not because it’s Altinity — because these builds have been tested, are more stable, and have fewer random bugs and behavioral changes.

Second, Altinity Stable Builds have extensive upgrade notes. If you’re moving from 21.8 to 22.3, we document exactly what to watch out for.

Third, test your upgrades. With Altinity.Cloud this is easy: before upgrading, open the backup wizard, restore a backup into a new cluster, connect your event streams (Kafka makes this easy since you can just set up the new cluster to read the same production feeds), run your upgrade, validate everything, and then throw the test cluster away. This process will flush out obvious issues, particularly behavioral changes in aggregate functions or API differences.

Fourth, check with us. Contact support before major upgrades. We can advise on what to watch for, and if you let us know in advance we can make sure someone is available to help quickly if something goes wrong.

[46:10] — Monitoring Panels and System Status

Robert: There are three types of monitoring panels in Altinity.Cloud: cluster metrics (insert counts, merge activity, query load, system load average), query panels (top-N queries, query history), and logs. Access them by clicking the “View in Grafana” button on the cluster dashboard. Pick from the dropdown and they open in another window.

For overall system health, go to your account name in the top right, click it, and you’ll see a system status page for your environment. This gives you an overview of whether your environment is healthy, though transient failures (like a GCP VM that auto-replaces quickly) may not always appear there.

[47:47] — Security

Robert: Security features in Altinity.Cloud:

All traffic is TLS encrypted. The rare exceptions are MySQL protocol connections, which require a special request.

IP whitelisting: you can whitelist specific IP addresses during cluster creation or add them later. This limits which clients can connect.

VPC endpoints: set up private networking so all traffic between your VPC and the Altinity.Cloud environment travels over a private network not visible to anyone else. This is a very common feature. Just request it and we will set it up quickly.

The Altinity access control dial: on the cluster dashboard there’s an “Altinity access” button. This pops up a modal where you can select: no access whatsoever (our support team cannot touch your data), read-only (we can see system tables only, useful for diagnosing bugs without seeing your data), full access (we can do anything), or intermediate configurations like disabling cluster configuration management. This gives you control over who can access your data.

[50:36] — Inviting Users

Robert: To invite users to your organization, go to the cluster dashboard, hit the Share link, type in email addresses, and they’ll automatically receive a generated invite that allows them to connect to the account.

[51:21] — Enterprise Support

Robert: Enterprise support is one of the unique features of Altinity.Cloud. We have been doing support for ClickHouse since 2017, longer than anybody else. We’ve helped hundreds of customers, ranging from tiny crypto startups to Fortune 100 companies. ClickHouse is incredibly powerful but that power requires knowledge about how it works inside.

You can file cases via Slack (great for back-and-forth communication) or Zendesk (better for production outages and incident tracking). The types of things we can help with:

Schema design — how do I structure my tables for this use case? Performance optimization — how do I get better compression, faster queries? Troubleshooting in live systems. Upgrade guidance and execution. Capacity planning. Integrations with Kafka, BI tools, client libraries. Random complex queries: we get some really interesting analytical queries and love helping with those.

Some customers get a shared Slack channel with us for easy back-and-forth, plus Zendesk for production incidents.

[54:38] — Getting the Most Out of Support

Robert: A few practices that help you get the most out of the Altinity.Cloud plans and features:

Log production issues in Zendesk so they get proper tracking and closure.

Contact us in advance for major operations. If you’re doing a mission-critical upgrade on Saturday night, contact us beforehand. We have people across every time zone, but you don’t want to call at 11pm having already hit a problem.

Notify us before scale-out operations that may require quota increases. We can ensure you don’t hit a problem as long as we know in advance.

Don’t wait for problems. Ask questions up front. Our support team are not just DBAs — they’re people with extensive experience operating very large ClickHouse clusters and building analytics applications. We often set up a regular check-in call for large projects.

[55:40] — Getting Started

Robert: To get started it’s pretty easy. Go to the website and choose the model that fits: Altinity.Cloud in our VPCs, Altinity.Cloud Anywhere in your own VPCs on Kubernetes, or ClickHouse support if you’re entirely self-managed. For Altinity.Cloud and Altinity.Cloud Anywhere, fill out the form and you’ll kick off a free two-week trial with full support — evaluate whether this is the right thing for you, no charge.

Thank you so much for attending today. We really appreciate you joining and hope this has been helpful. We look forward to seeing you on Altinity.Cloud.

Alexander: Thank you, Robert.

FAQ

What is Altinity.Cloud and how does it differ from self-managed ClickHouse?

Altinity.Cloud is a fully managed ClickHouse service where Altinity handles all operational work: provisioning, configuration, monitoring, backup, upgrades, scaling, and incident response. Unlike self-managed ClickHouse, it comes with enterprise DBA support included in every plan, so you have expert help from day one. All the software running underneath — ClickHouse, the Altinity Kubernetes Operator, Grafana, Prometheus — is 100% open source and Apache-licensed, meaning you can inspect everything and move to self-managed at any time.

What is Altinity.Cloud Anywhere and when should I use it?

Altinity.Cloud Anywhere lets you run managed ClickHouse in your own Kubernetes cluster (e.g., Amazon EKS in your own VPC) rather than in Altinity’s VPC. You register your Kubernetes cluster with Altinity.Cloud, Altinity builds a secure management tunnel to specific namespaces, and then manages your ClickHouse clusters from there. Use it when you have compliance requirements, want data to stay in your own network, want to keep costs tied to your existing cloud commitments, or need to maintain full ownership of the infrastructure. Your data never leaves your VPC.

What is the uptime schedule feature and how does it save money?

The uptime schedule automatically stops the compute backing a ClickHouse cluster after a configurable period of inactivity (for example, two hours of no queries). You can also define a recurring schedule — for example, run the cluster on workdays from 8am to 8pm and auto-pause otherwise. When compute is stopped you still pay for block storage (which retains all your data) but not for the VMs. For development clusters, this can reduce costs dramatically since compute is the largest cost component.

Should I use community builds or Altinity Stable Builds for production?

For production, Altinity recommends Altinity Stable Builds. Community builds come out monthly and evolve rapidly, which means even a fresh LTS community build may contain unstable features, regressions, or behavioral changes that affect production applications. Altinity Stable Builds are based only on community LTS releases, go through a multi-month certification period including QA testing and upgrade documentation, and have been shown to avoid regressions that appear in community builds. They also come with very detailed upgrade notes. For development and new feature exploration, community builds are appropriate.

How does Altinity.Cloud handle scaling?

Scaling is done through the rescale operation on the cluster dashboard. Vertical scaling changes the VM size: the existing VM is terminated and a new one is provisioned with the block storage reattached. Horizontal scaling adds or removes shards and replicas: the Altinity Kubernetes Operator provisions new nodes, automatically copies the schema to new replicas, and lets ClickHouse replication populate data for replicated tables. Storage can be expanded at any time but cannot be shrunk. On Amazon, Altinity stacks EBS volumes for better I/O performance. Adding replicas is a zero-downtime operation.

How does the enterprise support model work?

Enterprise support is included with every Altinity.Cloud plan. You get a shared Slack channel for ongoing questions and collaboration, and Zendesk for production incidents and formal tracking. Support covers schema design, query optimization, compression tuning, upgrade planning, Kafka integration, BI tool integration, troubleshooting, and capacity planning. Altinity recommends proactive engagement: contact support before major upgrades, before large scale-out operations that might hit quota limits, and regularly for health checks on critical systems.

© 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.