ClickHouse consulting · 24×7 support · Managed services · Delivered by ChistaDATA, MinervaDB's dedicated ClickHouse practice
ClickHouse Consulting Measured in Granules Read, Parts per Partition and Merge Backlog, Not Opinions
ClickHouse consulting for MinervaDB customers is scoped, staffed and delivered by ChistaDATA Inc., the ClickHouse-only practice that works on 100% open-source ClickHouse with zero vendor lock-in. The engineers have designed MergeTree sort keys that held p99 as tables grew past tens of billions of rows, sized Keeper ensembles for multi-region rings, and run rolling LTS upgrades without a read-only minute. Every recommendation names the system.* table or EXPLAIN output behind it; every change on a running cluster ships with a blast radius and a rollback; and the same team carries the 24×7 watch afterwards. Vendor-neutral by principle: neither company resells ClickHouse Cloud, so the answer can be self-managed, Kubernetes, a managed service, or a different engine.
01 · Why ClickHouse consulting through ChistaDATA
ClickHouse is fast by default and expensive by accident
ClickHouse delivers sub-second analytics when the sort key matches the queries, inserts arrive in batches, and merges keep up. When any of those slip, the symptoms are too many parts, memory-limit exceptions and a cluster that is three times larger than the workload needs.
ClickHouse only
ChistaDATA engineers work exclusively on ClickHouse: MergeTree internals, Keeper, ingestion and the operating model around them. ClickHouse consulting is not a side skill of a generalist team; it is the whole practice, backed by MinervaDB for the rest of the estate.
Vendor-neutral, open source
No ClickHouse Cloud resale, no distribution to protect. Recommendations come from system.query_log, system.parts and your invoice, including when the answer is a smaller cluster, a managed service, or that this workload belongs in PostgreSQL.
Real 24×7 operations
Senior ClickHouse engineers on watch across time zones, S1 acknowledged within 15 minutes, S2 in 12 hours, S3 in 24 hours, S4 in 48 hours, and every action timestamped in a shared incident system. ChistaDATA 24×7 ClickHouse support →
Measurement first
Nothing is claimed until the number has moved: rows and bytes read per query, granules pruned, parts per partition, merge and mutation backlog, replication delay, Keeper latency, cost per query. Estimates are labelled as estimates.
02 · ClickHouse consulting services
Six disciplines around the ClickHouse estate, one accountable team
Most ClickHouse consulting engagements start with the health check and grow into the discipline the evidence points at. All six are delivered by ChistaDATA, on self-managed clusters, Kubernetes and managed services alike.
Figure 1. The ClickHouse consulting service map: MergeTree schema engineering, performance, ingestion and CDC, sharding and replication with Keeper, upgrades, security and cloud, entered through the health check and sustained by ChistaDATA's 24×7 support and managed services.
MergeTree schema engineering
ClickHouse consulting starts at the sort key: ORDER BY and PARTITION BY chosen from the query log rather than from the source schema, index granularity and skip indexes (minmax, set, bloom filters) where they prune, projections for the second sort order, materialized-view topologies for rollups, and TTL to S3 or slower disks for cold partitions. Engine declarations are always explicit, with full parameter lists.
Performance engineering
Query engineering from system.query_log ProfileEvents, EXPLAIN indexes = 1 and EXPLAIN PIPELINE, memory and thread limits per user and query, system.trace_log flame graphs for CPU-bound statements, join strategy and dictionary design, and the settings profiles that keep one analyst from taking down ingestion.
Ingestion and CDC
Kafka engine tables or Kafka Connect and Debezium pipelines from PostgreSQL, MySQL, MongoDB and SQL Server, batch sizing and async inserts, deduplication tokens and ReplacingMergeTree upserts, and retention sized so a materialized view can be rebuilt by replay. Kafka consulting →
Sharding, replication and Keeper
ReplicatedMergeTree with Distributed tables, sharding keys from write distribution and query locality, replica routing and load balancing, ClickHouse Keeper ensembles sized and placed for the failure domain, multi-region topologies, and DC-DR drills that produce measured RPO and RTO.
Upgrades and lifecycle
ClickHouse consulting runs rolling upgrades between LTS lines with the changelog's backward-incompatible settings reviewed and the compatibility setting pinned, Keeper upgraded first, replica by replica, one shard at a time, verified against a system.query_log baseline before the compatibility setting is raised.
Security, compliance and cloud
RBAC, row policies, quotas and settings constraints, TLS on native and HTTP ports, audit logging, and the evidence pack for GDPR, HIPAA, SOX, PCI DSS and SOC 2; the divergence map for ClickHouse Cloud's SharedMergeTree and Altinity.Cloud, with the exit path written before any migration. ChistaDATA managed services →
03 · ClickHouse consulting method
MergeTree internals, and the system table that exposes each stage
Every ClickHouse performance problem lives at a specific stage: insert, parts, merges, primary index, skip indexes, or TTL. ClickHouse consulting names the stage from the engine's own system tables before changing anything.
Figure 2. ClickHouse consulting view of MergeTree internals from insert to TTL, and the system table or EXPLAIN output that exposes each stage: parts and part_log, merges and mutations, query_log and trace_log, replicas and Keeper.
A ClickHouse consulting baseline is captured over a window that includes peak dashboards, batch loads and a merge cycle: system.query_log aggregated by normalized query hash for read rows, read bytes, memory and duration percentiles; system.parts for active parts per partition and compression ratios; system.merges and system.part_log for merge throughput against insert rate; system.replicas for delay and queue size; and Keeper's mntr output for latency and outstanding requests. Attribution names the stage: a sort key that does not prune, a partition key too fine for the insert pattern, a projection missing for the dashboard's group-by, a materialized view chain that doubles merge load, or a Keeper ensemble on shared hosts.
Changes are made one at a time and are reversible: a projection added and materialized in the background, a skip index tested with EXPLAIN indexes = 1 before and after, a settings profile change on one user, a TTL rule with the move rehearsed on a copy. Blast radius and rollback are written before execution, and destructive operations (DROP, DETACH, TRUNCATE) carry a confirmation gate.
-- Heaviest query shapes in the last 24 hours
SELECT
normalized_query_hash AS shape,
count() AS runs,
quantile(0.95)(query_duration_ms) AS p95_ms,
formatReadableQuantity(sum(read_rows)) AS rows_read,
formatReadableSize(sum(read_bytes)) AS bytes_read,
formatReadableSize(max(memory_usage)) AS max_mem,
any(query) AS sample
FROM system.query_log
WHERE event_time >= now() - INTERVAL 1 DAY
AND type = 'QueryFinish'
AND is_initial_query
GROUP BY shape
ORDER BY sum(read_bytes) DESC
LIMIT 20;
-- Part pressure per table
SELECT database, table,
count() AS active_parts,
uniq(partition) AS partitions,
formatReadableSize(sum(bytes_on_disk)) AS on_disk,
round(sum(data_uncompressed_bytes)
/ sum(data_compressed_bytes), 2) AS compression
FROM system.parts
WHERE active
GROUP BY database, table
ORDER BY active_parts DESC
LIMIT 20;
04 · ClickHouse consulting for cluster architecture
Sharded, replicated, and built around a Keeper ensemble that can lose a member
ClickHouse consulting designs the cluster around the failure you will actually have: a replica, a Keeper node, a zone. Each of those is then removed on purpose and the numbers written down.
Figure 3. ClickHouse cluster reference architecture: two shards with two replicas across zones on ReplicatedMergeTree, a three-node ClickHouse Keeper ensemble, a Distributed table with an explicit sharding key, load balancing with replica routing, ingestion into local shard tables, and the drills that prove it.
Keeper sized for the failure domain
ClickHouse consulting places three Keeper nodes across zones on dedicated hosts or pods, never co-located with heavy ClickHouse replicas; quorum of two holds through one loss, and the second loss (tables read-only) is rehearsed and alerted rather than discovered. Keeper is upgraded before the servers.
Sharding key from the workload
cityHash64 of a tenant or entity key when queries filter by it and locality matters; rand() when they do not; never a key with hot values. Writes go to local shard tables at ingestion scale, and Distributed reads use prefer_localhost_replica and load_balancing chosen from measured latency.
Storage tiering and restore
ClickHouse consulting for storage sets policies with a local hot volume and an S3 cold volume moved by TTL, BACKUP TO S3 or clickhouse-backup on a schedule, and a quarterly restore to a scratch cluster timed on production-size data. That observed time is the RTO the runbook quotes.
05 · ClickHouse consulting for ingestion and CDC
Ingestion engineered so parts, merges and lag stay under control
Most ClickHouse incidents are ingestion incidents in disguise: too many parts, merges that cannot keep up, or a consumer that fell behind. ClickHouse consulting treats the pipeline as part of the database.
Figure 4. ClickHouse consulting ingestion and CDC architecture: OLTP change capture through Debezium and Kafka, event producers, Kafka engine tables or a Kafka Connect sink, materialized views into MergeTree targets, and the batch, deduplication, part-pressure and lag engineering that keeps the cluster healthy.
Batch sizing
ClickHouse consulting for ingestion starts with batch size: ten thousand to a million rows per insert; async_insert with wait_for_async_insert = 1 for small producers; max_insert_block_size and the minimum block settings tuned so each insert lands as one part per partition.
Deduplication
insert_deduplication_token or block-level dedup on replicated tables for at-least-once producers; ReplacingMergeTree with a version column for CDC upserts, with FINAL used only where the read can afford it and the merge settings tuned so it rarely has to.
Part pressure
parts_to_delay_insert and parts_to_throw_insert left as guards, not raised as workarounds; merge throughput measured against insert rate in system.part_log; background pool sizes and max_bytes_to_merge_at_max_space_in_pool set from the disks that exist.
Lag and replay
Kafka consumer lag as the ingestion SLI with an alert at a fraction of the budget; topic retention sized so a materialized view can be rebuilt or a schema correction replayed from the window; exactly-once patterns documented per pipeline.
06 · ClickHouse consulting for versions and upgrades
ClickHouse releases we plan against, and how a rolling upgrade is run
ClickHouse ships a stable release every month and designates two LTS releases a year, supported for a year. ClickHouse consulting keeps production on an LTS line and upgrades replica by replica with the changelog read first.
Figure 5. ClickHouse release lifecycle as verified on 28 September 2026: stable 26.9, LTS 26.8 and 26.3, the older LTS lines, ClickHouse Cloud's managed cadence, and the rolling upgrade method.
| Release | Type | Status on 28 September 2026 | What ClickHouse consulting does about it |
|---|---|---|---|
| ClickHouse 26.9 | Stable, September 2026 | Current stable; newest features, bug fixes until superseded | Evaluated on staging; production only where a feature is required |
| ClickHouse 26.8 | LTS, August 2026 | Current LTS with a year of fixes | The production target for new builds and upgrades |
| ClickHouse 26.3 | LTS, March 2026 | Supported until March 2027 | Stay current on patch releases; plan the move to 26.8 |
| ClickHouse 25.x and 24.x LTS | Earlier LTS lines | Leaving or out of support | Rolling upgrade to 26.3 or 26.8 with backward-incompatible settings reviewed and the compatibility setting pinned until verified |
| ClickHouse Cloud | Managed, SharedMergeTree | Upgraded on ClickHouse Inc.'s schedule; feature drift from open source | Divergence map maintained; exit path through BACKUP TO S3 rehearsed before migration in |
Release facts from the ClickHouse changelog and the project's release cadence; confirm the exact patch release at engagement start, because a new stable ships every month.
07 · How a ClickHouse consulting engagement works
MinervaDB routes ClickHouse consulting to ChistaDATA, and one agreement can still cover the whole estate
ChistaDATA is MinervaDB's dedicated ClickHouse practice. The contracting path depends on whether ClickHouse is the whole estate or one engine in it; the delivery standard is the same either way.
Figure 6. The engagement model: MinervaDB routes ClickHouse work to ChistaDATA, which delivers it; customers contract directly with ChistaDATA for ClickHouse-only work or through one MinervaDB agreement when ClickHouse sits alongside other engines.
ClickHouse-only estates
For ClickHouse consulting on a ClickHouse-only estate you contract directly with ChistaDATA Inc. and receive its ClickHouse-specific SLAs, support tiers and rate card. ChistaDATA scopes, staffs and delivers the engagement, from a health check to 24×7 managed services, and MinervaDB steps aside. ChistaDATA ClickHouse consulting →
ClickHouse beside other engines
When ClickHouse is one part of an estate MinervaDB already supports, PostgreSQL, MySQL, MariaDB, SQL Server, Oracle, Db2, MongoDB, Cassandra, Redis or Valkey, MinervaDB holds a single agreement covering every engine, with the ClickHouse workstream delivered by ChistaDATA and one severity matrix across all of them. MinervaDB 24×7 consultative support →
Standing caveat: every recommendation on this page is tested on a non-production cluster against production-representative data before it is applied to production, with a verified backup taken first and a disaster-recovery posture exercised by a timed restore. Engine declarations in customer-facing work are always explicit; nothing relies on defaults.
08 · ClickHouse health check and performance audit
The fixed-scope entry point to ClickHouse consulting
Read-only, evidence-based and delivered as findings your own engineers can verify. No change is made to production during the audit.
What is reviewed
ClickHouse consulting audits cover version and LTS currency; table engines, sort and partition keys against the query log; parts per partition and merge and mutation backlog; materialized-view topology and projection use; skip-index effectiveness; memory, thread and settings profiles; replication delay and Keeper health; ingestion batch sizes, deduplication and consumer lag; storage policies and TTL; backup and restore evidence; security posture; and, on managed services, tier fit and cost per query.
What you receive
Findings ranked P0 to P2, each with the observation, the system.* or EXPLAIN evidence, the recommended change with its rollback and the metric it is expected to move; a prioritised remediation plan; and a versioned, branded report your team keeps whether or not ChistaDATA does the remediation. Findings typically arrive within days of read-only access.
09 · FAQ
ClickHouse consulting questions we are asked most
Short answers to what engineering leaders ask before the first call.
Who actually delivers ClickHouse consulting and support for MinervaDB customers?
ChistaDATA Inc., MinervaDB's dedicated ClickHouse practice. Every ClickHouse consulting, 24x7 support and managed-services engagement is scoped, staffed and delivered by ChistaDATA engineers who work exclusively on open-source ClickHouse. MinervaDB routes ClickHouse enquiries to ChistaDATA so you reach the right specialists on the first call.
Do I contract with MinervaDB or with ChistaDATA?
For ClickHouse-only work you contract directly with ChistaDATA Inc. and get its ClickHouse-specific SLAs, support tiers and rate card. If ClickHouse is one part of a wider estate that MinervaDB already supports, MinervaDB can hold a single agreement covering every engine, with the ClickHouse portion delivered by ChistaDATA under one severity matrix.
What does ClickHouse consulting include?
MergeTree schema engineering (sort keys, partitioning, skip indexes, projections, materialized views, TTL), performance engineering from system.query_log, system.parts, system.merges and EXPLAIN PIPELINE, ingestion and CDC pipelines on Kafka and Debezium, sharding and replication with ClickHouse Keeper, rolling upgrades between LTS lines, security and compliance, and 24x7 support or fully managed operations.
Why does our cluster keep throwing 'too many parts'?
Inserts are arriving as small batches, the partition key is too fine for the insert pattern, or merges cannot keep up with the insert rate. ClickHouse consulting reads system.part_log and system.merges to tell which, then fixes the cause: batch sizing or async inserts, a coarser partition key, materialized-view chains that double merge load, or background pool sizing. The parts_to_throw_insert guard is left in place, not raised.
Should we use ClickHouse Cloud, Altinity.Cloud or self-managed ClickHouse?
It depends on workload shape, compliance, team depth and cost per query over twelve months. ClickHouse Cloud runs SharedMergeTree with feature drift from open source and upgrades on its own schedule; self-managed gives full control and full ownership of the pager; Kubernetes with the Altinity operator sits between. Neither MinervaDB nor ChistaDATA resells any of them, so the assessment includes the exit path either way.
How do you upgrade ClickHouse without downtime?
Keeper first, then replica by replica, one shard at a time, so every shard keeps a serving replica and Distributed reads continue. The changelog's backward-incompatible settings are reviewed and the compatibility setting pinned before the first node moves; p95 and p99 are verified against a system.query_log baseline before the setting is raised.
Which ClickHouse versions do you support?
The supported LTS lines, 26.3 and 26.8 as of September 2026, plus the current stable 26.9 where a feature requires it, and the older LTS lines for the purpose of upgrading off them. Production estates are kept on an LTS line with patch releases applied on a calendar.
Can one team look after ClickHouse alongside PostgreSQL or MySQL?
Yes. MinervaDB supports PostgreSQL, MySQL, MariaDB, SQL Server, Oracle, Db2, MongoDB, Cassandra, Redis and Valkey, and ChistaDATA supports ClickHouse; under one MinervaDB agreement the estate is operated with one severity matrix, one monthly report and one escalation path, with the ClickHouse workstream delivered by ChistaDATA.
Talk to a senior ClickHouse consulting engineer at ChistaDATA
Bring the heaviest shapes from system.query_log, active parts per table from system.parts, Keeper's mntr output and the current infrastructure or managed-service invoice to the first call. We will tell you which stage is the constraint, what moving it is worth, and what we would change first.