What does AceMQ ClickHouse support include?

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.

We keep hitting "too many parts". What actually fixes it?

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.

How fast do you respond to a ClickHouse production outage?

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.

Do you support ClickHouse Cloud as well as self-managed clusters?

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.

Our query filters on an indexed column but still scans everything. Why?

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.

An ALTER TABLE UPDATE has been running for days. Can it be stopped safely?

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.

How is AceMQ ClickHouse support priced?

Support is an annual contract priced on cluster size, required SLA tier, and coverage hours — not per incident and not per ticket. That structure exists so nobody hesitates to page us during an outage. Quotes are returned within 24 hours and scoped against your actual deployment, including shard and replica layout, rather than a node count on a form.

ClickHouse Support

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

AceMQ supports ClickHouse in production — "too many parts" from unbatched inserts, memory limits hit on a single join, replication queues stalled behind Keeper, and mutations that rewrite terabytes to change one column. Self-managed or ClickHouse Cloud. Every ticket reaches a named senior engineer who knows your table engines.

Senior ClickHouse engineers on call right now — 24/7/365

15 min emergency SLA24 /7 global coverage130 + enterprise customers26 + countries served

Available Now

Book a free Consultation.

Prefer to chat first?

Prefer to E-mail?

info@acemq.com

Trusted for mission-critical ClickHouse by teams in finance, healthcare, defense, and telecom

Escalation Path

Your first hour of a ClickHouse outage

Most vendors publish an SLA number. This is what actually happens, minute by minute, when you page a senior AceMQ engineer.

T+0

You page us

Phone, email, or Slack — any channel reaches the on-call senior engineer directly. No web form, no tier-1 queue.

T+15

Named engineer live

A senior engineer who already knows your environment joins a live bridge. Zero cold-start, no re-explaining your topology.

T+30

Root cause isolated

Direct broker access, log and metric review, and a working hypothesis with a rollback plan before we touch anything.

Post

Written RCA

Documented root cause, the fix applied, and the prevention steps — delivered after every P1, not just when asked.

Response Times

SLA tiers, contractually guaranteed

Every tier reaches a senior ClickHouse engineer. There is no tier-1 triage layer to get through.

P1 — Emergency

15 min

Production down, messages not flowing, cluster or broker failure

P2 — Critical

1 hour

Severe degradation, rising error rates, approaching capacity limits

P3 — High

4 hours

Performance issues, configuration problems, non-critical failures

P4 — Standard

Next day

Questions, guidance, best practices, non-urgent improvements

Incident Triage

ClickHouse problems we fix every week

These are real symptoms from real ClickHouse production environments — and the first thing our engineers check when one comes in.

Symptom you're seeingWhat we check firstTypical resolution

Inserts failing with DB::Exception: Too many parts

What we check firstInsert batch size and frequency first — every insert statement creates at least one part per partition, and background merges cannot keep up with thousands of tiny inserts per second. We also check partition key cardinality, because partitioning by day is fine and partitioning by timestamp is not.

Typical resolutionUnder 1 hour

Query killed with "Memory limit exceeded" on a GROUP BY or JOIN

What we check firstThe join algorithm and which side is the build side. ClickHouse loads the right-hand table into memory for a hash join, so a large table on the right will exhaust the limit regardless of settings. Then max_bytes_before_external_group_by, so aggregation spills instead of failing.

Typical resolution1–2 hours

A filtered query still scans the whole table

What we check firstWhether the WHERE column is a prefix of the ORDER BY key. The primary index is a sparse index over the sorting key, so filtering on the second column without the first gives no pruning at all. Fix is a data skipping index, a projection, or a corrected sorting key.

Typical resolutionUnder 2 hours

Replicas diverging, replication queue growing and not draining

What we check firstClickHouse Keeper or ZooKeeper latency and session expiries, then system.replication_queue for a single entry that keeps failing and blocking everything behind it. Keeper problems present as ClickHouse problems, and undersized Keeper nodes are the usual root cause.

Typical resolution2–4 hours

Disk filling despite TTL rules and deletes being configured

What we check firstsystem.parts for unmerged parts, system.mutations for a long-running rewrite, and whether TTL moves to cold storage are running at all. Merges and TTL both need free space to work, so a nearly full disk stops the process that would free it.

Typical resolution1–3 hours

An ALTER TABLE UPDATE or DELETE has been running for days

What we check firstsystem.mutations parts_to_do. Mutations rewrite every affected part rather than updating rows in place, so a single column change on a large table means rewriting the whole dataset. We move these to lightweight deletes, a ReplacingMergeTree pattern, or a partition-scoped rewrite.

Typical resolution1–2 hours

Distributed queries far slower than the same query on one shard

What we check firstShard skew from the sharding key, then whether the query fans out and re-aggregates a huge intermediate result on the initiator node. Pushing the GROUP BY down and returning aggregate states instead of raw rows usually collapses the gap.

Typical resolution2–4 hours

Insert throughput dropped sharply after adding a materialized view

What we check firstHow many materialized views now fire per insert block and what each one writes. MVs run synchronously in the insert path, so the slowest target table sets your ingest rate — and each target has its own merge load competing for the same background pool.

Typical resolutionUnder 2 hours

Resolution times reflect typical ClickHouse engagements under an active AceMQ support contract. Every P1 closes with a written root-cause analysis.

Not on the list? Tell us what's breaking

Support In Practice

ClickHouse problems we've already solved

Representative engagements showing how these incidents get diagnosed and closed under an AceMQ support contract.

All use cases

Remediation

ClickHouse Too Many Parts Remediation

Adtech Measurement Platform

Resolving ingestion failures where frequent small inserts produced parts faster than background merges could retire them, tripping the parts limit.

ClickHouseKafkaKubernetes

Read case study

Support

ClickHouse MergeTree and Replication Support

Cybersecurity Analytics Provider

Ongoing support for ReplicatedMergeTree clusters covering replication queue stalls, memory limit failures on large queries, and mutation backlogs.

ClickHouseClickHouse KeeperKubernetes

Read case study

Assessment

ClickHouse Cluster and Storage Assessment

Financial Market Data Provider

Assessment of shard and replica topology, storage tiering, query concurrency limits, and merge behavior ahead of a significant data volume increase.

ClickHouseClickHouse KeeperS3

Read case study

What's Included

Everything in your ClickHouse support contract

No add-on pricing for incidents. No per-ticket charges. One contract covers the whole surface.

Emergency Incident Response

Ingest stopped, queries failing, replicas diverged, or a disk filling faster than merges can free it. A senior engineer joins a live bridge within 15 minutes with access to diagnose — not a ticket acknowledgement.

Root Cause Analysis

Every P1 closes with a written RCA: what failed, why, the fix applied, and the schema, ingest, or settings change that stops it recurring. Delivered as standard, not on request.

Schema & Table Engine Review

Sorting key and primary index design against your real filter patterns, partition granularity, codec and compression selection per column, and choosing between ReplacingMergeTree, AggregatingMergeTree, and plain MergeTree deliberately.

Query & Ingest Tuning

EXPLAIN and query log analysis, join reordering and algorithm selection, projections and skip indexes, plus insert batching or async_insert configuration sized against your producer's actual behaviour.

Replication & Keeper Health

ReplicatedMergeTree topology, ClickHouse Keeper sizing and latency, replication queue monitoring, and distributed table design that doesn't create hot shards or expensive fan-out.

Upgrades & Migrations

Version upgrades with a tested rollback, self-managed to ClickHouse Cloud moves in either direction, tiered S3 storage rollout, and migrations onto ClickHouse from Elasticsearch, Druid, or a row-store warehouse.

Anywhere You Run It

We support ClickHouse wherever it's deployed

Cloud, Kubernetes, bare metal, hybrid, and air-gapped — including environments where you can't give us outbound network access.

ClickHouse Cloud (AWS, GCP, Azure)Self-managed ClickHouse 23.x – 25.xClickHouse Keeper & ZooKeeper clustersAltinity Stable buildsAltinity Operator on KubernetesOpenShiftAWS (EC2, EKS) with gp3 / io2 volumesAzure & Google Cloud VMsS3 / GCS tiered storageBare metal & on-premiseAir-gapped / no outbound accessHybrid cloud

Why AceMQ

What you get that you don't get elsewhere

Named Engineers, Zero Cold Start

The same senior engineers stay on your account. They know your table engines, your sorting keys, and your ingest pattern — so a P1 call starts with a hypothesis rather than a walkthrough of your schema.

No Tier-1 Triage Layer

You reach a senior ClickHouse engineer directly by phone, email, or Slack. Nobody collects information to pass along, and no escalation approval stands between you and someone who can read system.query_log.

We Fix the Schema, Not Just the Settings

Most ClickHouse incidents trace back to a sorting key that doesn't match the query filters or a partition key with far too much cardinality. Settings changes can buy time; we tell you when the real fix is a table rebuild and plan the migration.

Ingest Pipelines, Not Just the Server

"Too many parts" is a producer problem that manifests in the database. We tune the Kafka table engine, batching in your ingest service, and async_insert together, because fixing only the server side just moves the failure later.

Genuine Follow-the-Sun Coverage

Engineers across 26+ countries and every time zone. Your 3am ingest stall is someone's mid-afternoon — no overnight skeleton crew, no waiting for a region to come online.

Full-Stack, Not Just clickhouse-server

We diagnose across Keeper, disk and object-store latency, the ingest pipeline, network policy, and Kubernetes. ClickHouse is fast enough that the bottleneck is frequently somewhere else entirely.

FAQ

ClickHouse support questions

ClickHouse Is Fast Until the Schema Stops Cooperating

Whether you need emergency response tonight or a support contract that catches part counts and mutation debt before they stop ingest, AceMQ staffs every engagement with a named senior ClickHouse engineer. Quotes returned within 24 hours.

Get in Touch

Talk to a Support Expert

Send us a message and we'll follow up within one business day — or book a free 30-min consultation directly.

305-204-2607

info@acemq.com

66 W. Flagler St. 9th Floor
Miami, FL 33130

Prefer to talk now? Call us directly or use the consultation tab to find a time that works.