Managed ClickHouse: AceMQ Runs Your Parts, Merges, Replicas and Keeper

• 01

  Parts, Merges and the Pager

  We manage monitoring of what predicts a ClickHouse incident: active parts per partition against the insert limit, the merge backlog, insert batch size and rate, and free disk. Then we take the pager, so an alert reaches an engineer who knows your tables.

• 02

  Replication and Keeper

  High availability starts with the layout: replicated tables, shards and replicas arranged so that losing a host does not lose a shard, and a Keeper ensemble of at least three nodes kept healthy: quorum, snapshots, log growth, and a failover rehearsal on a schedule.

• 03

  Releases and Upgrades

  Upgrades planned against ClickHouse's own security policy and release channels, rehearsed on a copy, with rollback steps written down. Where an old coordination layer is in the way, such as ZooKeeper to Keeper, it runs as a project inside the service.

• 04

  Ingestion and Queries

  Batching and asynchronous inserts for the producers that feed ClickHouse, Kafka consumers and connectors reviewed, and the slowest queries traced to sort keys, partition choice and missing projections.

• 05

  Right-Sizing and Cost

  Estates that grew as many single-node servers reviewed for what can be consolidated, replicated or shrunk, with storage tiers and retention checked against how the data is really queried.

• 06

  Backups and Access

  Backups restored into a scratch environment on a schedule and timed against your objectives, users, roles and access control reviewed against least privilege, TLS checked. Access to your environment follows your change process and is logged.

• Data Stays Where Your Policy Says

  Tier 3 keeps every part, replica and backup in your own account, data centre or Kubernetes clusters, which is what residency rules and air-gapped sites need. Tier 4 moves the servers to AceMQ when infrastructure is the thing you want to stop owning. The people doing the work are ClickHouse specialists under an AceMQ contract, not a hosting company.

• One Contract, One Escalation Path

  AceMQ signs the contract and owns the SLA and escalation, and brings in partner ClickHouse specialists as the work calls for them. An alert at 3am reaches someone who already knows your shards, replicas and Keeper ensemble. The 15-minute figure is how fast we respond, not how fast every incident is closed.

• The Pipeline Around It Is in Scope

  Many ClickHouse incidents start upstream: a consumer inserting one row at a time, a connector that restarts and replays, a partition key that explodes. We manage the servers and also work on how data gets in and how it is read.

• Documentation You Keep

  Failover, restore and upgrade runbooks, the topology map and the alert rules are written in your repository, not ours. Taking operations back in-house, or moving a cluster between Tier 3 and Tier 4, starts from a current handover pack.

Sources: clickhouse.com/cloud, ClickHouse documentation and SECURITY.md, and the Altinity Kubernetes Operator repository, all read 4 November 2026. Vendor terms change, so check them before you commit.

• Small, frequent inserts

  ClickHouse's own advice is to batch inserts, at least 1,000 rows and ideally 10,000 to 100,000, at roughly one insert a second. Where producers cannot batch, asynchronous inserts let the server do it, with wait_for_async_insert left on so a write is only acknowledged once it lands.

• A partition key with too many values

  Merges happen only within a partition, and an insert touching many partitions makes a part for each one. A key such as a user or request id turns one insert into thousands of parts.

• Merges that cannot keep up

  Slow storage, low free disk and competing work stall merges. The vendor's article warns that raising parts_to_throw_insert only delays the error, so we fix the cause and treat the limit as an alarm.

• What we watch

  Active parts per partition and in total, the merge queue, insert rate and size, and disk. The alert fires on the trend, long before the limit.

A one-off remediation is a typical engagement; the managed service is the watching that stops it recurring. ClickHouse too many parts remediation

• Single-node estates have no failover

  ClickHouse's scaling guide shows that with one replica per shard a host failure fails distributed queries. Many servers that each run alone are many single points of failure, and often more spend than a smaller replicated cluster.

• Keeper needs a quorum

  ClickHouse Keeper coordinates replication and is compatible with ZooKeeper. The documentation says to run at least three Keeper nodes and recommends dedicated hosts in production; a three-node ensemble keeps working with one node down.

• ZooKeeper to Keeper is not a rolling switch

  The Keeper guide says a seamless migration is not possible and a mixed ZooKeeper and Keeper cluster is impossible: stop ZooKeeper, convert with clickhouse-keeper-converter, start Keeper. It is planned as a window with a rollback.

• Failover is rehearsed

  We remove a replica and a Keeper node on a schedule, in a non-production copy where you prefer, and record how long recovery takes against your objective.

Moving data into ClickHouse from another system is a separate migration project, scoped on its own.

• The security list on 4 November 2026

  ClickHouse's SECURITY.md lists 26.10, 26.9, 26.8 and 26.3 as receiving security fixes. 26.7 and earlier, and every 25.x line, are not on it.

• Stable or LTS

  ClickHouse recommends stable by default and suggests LTS for teams whose policies do not allow frequent upgrades. Many teams that start on LTS later move to stable. We pick per cluster and write the calendar down.

• One change at a time

  A version change, a Keeper change and a hardware change are three changes with three rollbacks. We never bundle them into one window.

• Other vendors' builds

  Altinity publishes Stable Builds with its own three-year support claim, and sponsors a Kubernetes operator. If you run those, AceMQ operates around them and does not replace the vendor's support.

Check ClickHouse's SECURITY.md for the list that applies on the day you read this.

• Tier 3: managed on your infrastructure

  AceMQ operates ClickHouse and Keeper in your cloud account, data centre or Kubernetes clusters, with system access granted through your change process. The servers, the disks, the data and the cloud invoice remain yours.

• Tier 4: managed on AceMQ infrastructure

  AceMQ hosts ClickHouse and Keeper on infrastructure it runs, with replication, backups and upgrades included. Your producers and dashboards get connection endpoints; there are no servers or rota on your side.

• A support contract first is a normal start

  Plenty of estates begin with Tier 1 or 2 and an assessment of parts, replicas and sizing, and move operations over later, cluster by cluster.

• Schemas and queries stay a joint job

  Sort keys, partitioning and materialized views decide how a cluster behaves. We work on them with the team that owns the workload, and design changes are consulting on the ClickHouse page.

Tiers 1 and 2, with the four-tier comparison, are on the ClickHouse support page. ClickHouse support: 24/7, 15-minute SLA

• Choose ClickHouse Cloud when

  You want the vendor to run ClickHouse, the regions and clouds it offers fit your data, and you are content with the vendor choosing when upgrades land.

• Run it yourself when

  You have engineers who know parts, merges and Keeper, and an on-call rota that can carry them. The tooling, including the Altinity operator, is open source, and the operational overhead is yours.

• Choose managed ClickHouse from AceMQ when

  You already run ClickHouse on virtual machines, on premises or on Kubernetes, need the data in your own boundary, want to leave a pager rota you cannot staff, or want one contract for ClickHouse, Kafka, PostgreSQL and the rest.

• Not sure yet

  Start with a ClickHouse assessment or support at Tier 1 or 2. The findings tell you which of the three fits.

What none of them removes: schema design, sort keys and query behaviour belong to whoever owns the workload.

• Servers, data volume and ingest rate

  How many servers and clusters, how much data, how fast it arrives, and which are production.

• Topology and recovery targets

  Single node, replicated, sharded, and the recovery point and time objectives that set the replication, Keeper and backup work.

• Cover hours

  Business hours only, or round-the-clock on-call with the 15-minute emergency response.

• Tier, and a consolidation or upgrade project

  Tier 3: your cloud provider bills the infrastructure and AceMQ bills operations. Tier 4: one AceMQ quote covers both. Consolidating single-node servers or moving to a newer release line is priced as a scoped project inside it.

• A pay-as-you-go console

  AceMQ works under a contract, with senior engineers on your estate. A ClickHouse service you sign up for and provision by clicking is the vendor's product.

• Moving to or from ClickHouse

  Migrating data in or out is a separate AceMQ project, scoped on its own. Once the data is where you want it we can operate it.

• Schema and query design

  Data modelling and sort key design are consulting work on the ClickHouse page, and often come before a managed contract.

• One small, non-critical instance

  A single analytics server with no uptime target needs a current version and a backup, not a managed service.

Kafka in front of ClickHouse? Both can sit under one managed contract. Managed Kafka services

• Tier 1

  ClickHouse 24/7 Support & Incident Management

  You run it, we back you up

  • A live bridge in 15 minutes, 24/7, for stalled ingest and failing queries
  • Diagnosis from system.parts, system.replication_queue, system.mutations and the query log
  • Keeper, disk and object store checked as part of the incident

  Best for: Teams that run ClickHouse themselves and need senior cover when ingest stops at 3am.

  ClickHouse 24/7 Support Quote
• Tier 2

  ClickHouse 24/7 Support with Proactive Monitoring

  You run it, we watch it with you

  • Part counts, merge backlog and background pool checks per table
  • Sorting key, partition and materialized view review against the query log
  • Keeper latency, session and replication queue monitoring

  Best for: Teams that want the merge backlog or the runaway mutation found in a review, not when inserts start failing.

  ClickHouse Proactive Monitoring Quote
• Tier 3

  Managed ClickHouse on Your Infrastructure

  We run it in your cloud or data centre

  • 24/7 monitoring of parts, merges, replication queues and Keeper sessions
  • Rolling upgrades with a tested rollback
  • Tiered S3 storage and TTL rules checked against the retention you need

  Best for: Regulated and air-gapped estates that must keep analytics data inside their own boundary.

  Managed ClickHouse Quote
• Tier 4

  Fully Managed ClickHouse on AceMQ Infrastructure

  We host it and run it, as a service

  • Replicated clusters sized to your ingest and query load
  • Producer batching and Kafka table engine settings tuned with your team
  • Upgrades, patching and merge health owned by AceMQ

  Best for: Teams that want ClickHouse analytics without a cluster to run, and do not need it in their own account.

  Fully Managed ClickHouse Quote

Every Tier can start as an ad hoc engagement or an annual partnership, and you can move up or down a Tier as your team changes.

• ConsultingClickHouse consulting and services
• SupportClickHouse support
• MigrationClickHouse migration
• LifecycleEnd-of-life software support
• Enterprise supportOpen source support across your whole stack
• GuideClickHouse guide