24/7 ClickHouse Support with a 15-Minute Emergency SLA

ClickHouse support covers 24/7 emergency incident response with a 15-minute SLA, root cause analysis on every P1, schema and table engine review, query and ingest tuning, replication and Keeper health checks, CVE and patch advisory, quarterly reviews, and upgrade or migration support. Every ticket goes to a named senior engineer assigned to your account. There is no tier-1 triage layer and no per-incident charge.

That error means background merges have fallen behind the rate at which new parts are created, and it is almost always caused by insert shape rather than server capacity. Every insert statement produces at least one part per partition it touches, so an application inserting single rows thousands of times a second creates parts far faster than merges can consolidate them. The fix is batching at the producer — tens of thousands of rows per insert is normal — or enabling async_insert so the server buffers on your behalf. If the partition key has high cardinality, say partitioning by hour or by a user id, each insert hits many partitions and multiplies the problem, so that usually needs correcting too. Raising the parts limit is a stopgap that trades an error today for a slower cluster tomorrow.

P1 emergencies — ingest stopped, queries failing cluster-wide, replicas diverged, disks full — get a 15-minute first response with a senior engineer joining a live bridge. P2 critical issues are 1 hour, P3 high-priority 4 hours, and P4 standard questions next business day. These are contractual response times covering nights, weekends, and holidays.

Yes, with the same engineers. ClickHouse Cloud removes Keeper management, replication mechanics, and storage provisioning, which are genuine operational wins. What it does not remove is schema design, sorting key selection, join memory behaviour, mutation cost, and the insert batching discipline that keeps part counts sane — and those account for the large majority of tickets we see either way. We also help teams decide honestly whether the Cloud compute model is cheaper for their workload than running their own nodes, which depends heavily on query concurrency and idle time.

ClickHouse does not have per-column indexes in the way a row store does. The primary index is a sparse index over the ORDER BY key, and it can only skip granules when the filter matches a prefix of that key. If your sorting key is (tenant_id, event_time) and you filter only on event_time, no pruning happens and you read the whole table. There are three ways out: add a data skipping index on the column if its values are well correlated with the sort order, create a projection with a different sort order, or rebuild the table with a sorting key matching the dominant query shape. We measure which one wins on your data rather than guessing, since skip indexes are frequently less effective than their documentation suggests.

Yes, mutations can be killed with KILL MUTATION and the already-rewritten parts remain valid — but the more useful conversation is why the mutation was needed at all. ClickHouse mutations are not row updates; they rewrite every part that contains matching rows, so changing one column on a large table means rewriting the entire dataset with full merge and compression cost. For deletes, lightweight deletes mark rows instead and are dramatically cheaper. For corrections and upserts, a ReplacingMergeTree or a versioned table with FINAL at query time avoids rewrites entirely. Where a genuine rewrite is unavoidable, we scope it to specific partitions so it runs in bounded chunks.

ClickHouse, Inc. runs a support program for ClickHouse Cloud users and for self-managed customers with an agreement, under its support services policy: support cases are classified by severity level, initial response times depend on the tier, and only recent releases are covered, the current and two prior stable releases or the current and previous long term support release. It is good product support, and it excludes modified builds, third-party hosting and unsupported versions. AceMQ is a support service for the cluster you actually run: any version, any host, with ClickHouse experts who look at the schema, the insert pattern and the queries as well as the server. Most support incidents on ClickHouse are operational rather than product defects, which is why teams hold both.

Replication lag on ReplicatedMergeTree tables usually traces to ClickHouse Keeper or ZooKeeper being slow or overloaded, a replica that cannot fetch a part because the source is busy, or a mutation stuck ahead of everything else in the replication queue. Merge backlog comes from inserts arriving as too many small parts, background pool settings that are too small for the workload, or disks that cannot keep up with merge IO. The fixes are in that order: relieve the coordination service, batch the inserts or enable asynchronous inserts, and size the merge pools and storage for real-time analytics at your ingest rate. The system tables tell the story quickly if you know which ones to read, and we do that on the first call.

Yes. AceMQ works on ClickHouse in two ways: ad hoc engagements for a defined piece of work, such as a health check, an upgrade or an incident, or an annual partner engagement that covers 24/7 support, proactive reviews and named engineers. Many teams start ad hoc and move to an annual partnership once the first engagement is done.

Every AceMQ proposal is tailored to your requirements: your ClickHouse environment, the SLA you need, the hours of cover and the scope of work. Most contracts run $24,000–72,000 a year, depending on the SLA, the scope and how ClickHouse is deployed, with aggressive discounts when several technologies share one contract. Request a quote and AceMQ replies within 1 hour.