ClickHouse vs Apache Druid vs Apache Pinot: which fits your team
A team shortlisting open-source OLAP engines for event and user-facing analytics usually narrows the field by workload shape, not by license, because all three server projects are Apache-2.0. Operating effort is the factor that most often decides the choice. ClickHouse fits a team that wants SQL-first analytics on one columnar server binary, scaled out with ReplicatedMergeTree tables coordinated by ClickHouse Keeper. It suits teams whose engineers already think in SQL and want the fewest moving parts to replicate, back up and upgrade.
Apache Druid fits ingest-heavy workloads where Kafka or Kinesis streams are the main source and the team can operate a split service model. Its Master (Coordinator and Overlord), Query (Broker and Router) and Data (Historical and Middle Manager or Indexer) servers depend on deep storage such as S3 or HDFS, a metadata store, and ZooKeeper. Apache Pinot fits user-facing query paths that need upserts during real-time ingestion and concurrent low-latency reads, with a controller, broker, server and minion model built on Helix and ZooKeeper. Pinot also requires JDK 25 or later for its services, which is a build and runtime constraint to check against your standard images.
Before choosing, confirm each platform against your own workload: event volume, query concurrency, whether you need upserts or joins at query time, and which coordination service your platform team already runs. Run a pilot with representative data and queries, and ask each vendor or community for its current upgrade and support guidance, since release cadence and support windows differ. DeployOpen can plan and implement the cluster you choose, but the decision rests on what your team can run for years, not on a feature table.
Which of the three fits your event analytics workload
This table matches six common team situations to the platform that usually fits best, and names the condition under which one of the other two would be the better choice. Read each row against your own query shapes, staffing and coordination stack, then confirm the points in the final column with a proof of concept on representative data.
| Scenario | Best fit and why | When another platform is the better choice |
|---|---|---|
| One SQL engine for many analysts | ClickHouse. It is a column-oriented SQL database with standard SQL for analysts, and it can serve as a general analytical store beside other workloads. | Apache Pinot if the main consumers are product features with strict latency targets and a known, narrow set of query patterns that fit its indexes and multitenancy model. |
| Kafka-fed dashboard that needs upserts | Apache Pinot. Its README lists upserts during real-time ingestion, so the latest state of a record can be queried as events arrive. | ClickHouse if the dashboard can work from append-only events or periodic recomputation, and your team prefers SQL-first modeling over Pinot's table configuration. |
| High concurrency for user-facing queries | Apache Pinot or Apache Druid. Both are built for high-concurrency, low-latency queries served to end users, and Pinot's README cites 100k+ queries per second at LinkedIn. | ClickHouse if concurrency is moderate and you need richer ad hoc SQL and joins. Confirm sustained concurrency with your own query mix, since published figures reflect other workloads. |
| Team already running ZooKeeper | Apache Druid or Apache Pinot. Both depend on ZooKeeper, so an existing ensemble and its operating practices carry over. | ClickHouse if you prefer not to add ZooKeeper operations, because replicated tables use ClickHouse Keeper. Keeper is also an option to plan for, not a reason to avoid running coordination. |
| Team with little Java operations experience | ClickHouse. It ships as a native server with no JVM cluster to tune, so the operating model is closer to a database than a distributed Java stack. | Apache Pinot or Apache Druid only if your team already runs JVM services well. Pinot's README states JDK 25 or later is required to build and run its services, so confirm JVM support with your platform team. |
| Team that wants a managed service | ClickHouse. ClickHouse Inc. sells ClickHouse Cloud as a managed service, and the open-source server keeps the same SQL model if you later self-host. | Apache Druid or Apache Pinot if you need a managed offering from a vendor you already use. Ask each provider which versions and deployment modes it supports, since no managed option for Druid or Pinot is covered in the supplied facts. |
How each cluster splits work across nodes
ClickHouse runs as a set of identical clickhouse-server processes. A replicated cluster uses ReplicatedMergeTree tables, where each shard has one or more replicas that hold the same data. Replicas coordinate their writes, merges and replication log through ClickHouse Keeper, which replaces Apache ZooKeeper as the coordination service. Keeper is a separate quorum, so the cluster has two kinds of nodes to plan for: data-bearing ClickHouse servers and coordination nodes.
- Keeper quorum size: The replication guide recommends at least three Keeper nodes in production, running on dedicated hosts with about 4 GB of RAM each. Confirm the sizing against your own write rate and table count before you commit to hardware.
- Replica recovery: A recovered replica automatically syncs missing data from a healthy replica without manual intervention. This is a replication behavior, so it does not replace backups.
- Backups are separate: ClickHouse's backup documentation notes that replication alone does not protect against human error or corruption, so BACKUP and RESTORE jobs still need a schedule and a destination.
- Restore tests: The backup documentation warns that a backup never test-restored will probably not restore properly, and recommends regular restore tests on spare clusters.
- Sharding is optional: Adding shards spreads data across servers. Many teams start with one shard and extra replicas, so confirm which layout fits your query concurrency and data volume.
Before you deploy, check how many Keeper hosts your network and change process can support, and who owns patching them alongside the data nodes.
Druid splits its work across three service groups. Master servers hold the Coordinator, which manages segment placement on the data tier, and the Overlord, which manages ingestion tasks. Query servers hold the Broker, which routes queries and merges results, and the Router, which sends requests to the right service. Data servers hold Historical processes, which serve segments from local disk, and Middle Managers or Indexers, which run ingestion tasks. Each group scales on its own, so a cluster is a set of processes with different jobs rather than one binary.
- Master tier (Coordinator and Overlord): Handles segment assignment and ingestion task management. Plan for these as separate processes on the master side.
- Query tier (Broker and Router): Brokers merge results from data servers, and Routers direct incoming requests.
- Data tier (Historical and Middle Manager or Indexer): Historicals serve segments, and Middle Managers or Indexers run ingestion work.
- Deep storage: Segments are kept in S3, HDFS or local disk, so data survives loss of a data server.
- Metadata store and ZooKeeper: A metadata store, typically PostgreSQL, MySQL or Derby, sits alongside ZooKeeper, which handles service discovery, coordination and leader election.
Before you commit, count the external systems you will operate: deep storage, the metadata database and a ZooKeeper ensemble, in addition to the Druid processes themselves.
Pinot splits work across four component types. Controllers manage cluster state and handle node failures. Brokers receive queries, route them to servers and merge the results. Servers host segments and process queries against them. Minions run background tasks, such as segment maintenance. Pinot uses Apache Helix on top of Apache ZooKeeper as its fault-tolerant, strongly consistent state store, so the cluster state lives in ZooKeeper rather than inside any Pinot component.
- Controllers: Manage cluster state and node failure handling, and coordinate with Helix.
- Brokers: Route queries to the right servers and merge partial results before returning them to the client.
- Servers: Host segments, download them from the deep store and run query work.
- Minions: Run background tasks that run alongside the serving path.
- Deep store: Batch-built segments are pushed to a deep store, and servers download them from there, so the deep store is part of recovery planning.
Before you deploy, confirm the JDK version your build and runtime pipeline supports, since the Pinot README states that Pinot services require JDK 25 or later, and confirm how your team will operate ZooKeeper alongside Helix.
Capabilities of ClickHouse, Apache Druid and Apache Pinot side by side
This table sets the three Apache-2.0 real-time analytics databases against each other on the capabilities that shape a shortlist. Where the supplied facts do not settle a cell, the entry tells you what to confirm in the current ClickHouse documentation or the project's own materials before you decide.
| Capability | ClickHouse | Apache Druid | Apache Pinot |
|---|---|---|---|
| License | Apache-2.0 for the server; ClickHouse Cloud is a separate managed service | Apache-2.0, an Apache Software Foundation project | Apache-2.0 |
| Stream ingestion | Confirm Kafka ingestion options and table engines in the current ClickHouse documentation | Native Kafka and Amazon Kinesis ingestion through supervisors | Real-time tables ingest from Kafka, Apache Pulsar and AWS Kinesis |
| Batch ingestion | Confirm file and object storage load paths in the current ClickHouse documentation | Native batch (index_parallel) tasks and SQL-based INSERT and REPLACE | Offline tables load CSV, Avro or Parquet from batch sources such as S3 or HDFS |
| Indexing | Confirm index types and primary key design in the current ClickHouse documentation | Segment-based columnar storage; confirm index options for your workload | Pluggable timestamp, inverted, star-tree, Bloom filter, range, text, JSON and geospatial indexes |
| Joins | Confirm join support and limits for your query shapes in the current ClickHouse documentation | Confirm join behavior for your query shapes in Druid SQL documentation | Fact and dimension joins listed, with a multi-stage query engine for distributed plans |
| SQL and query interfaces | Column-oriented SQL database for OLAP queries | Druid SQL and native queries over HTTP and JDBC, with a built-in web console | SQL through a query editor and REST API; Java and JDBC clients target Java 11 bytecode |
| Coordination service | ClickHouse Keeper for ReplicatedMergeTree replication, replacing ZooKeeper | ZooKeeper for service discovery, coordination and leader election | Apache Helix with Apache ZooKeeper as the state store |
| Backup approach | BACKUP and RESTORE for full and incremental backups to local disk, S3-compatible or Azure Blob storage; replication alone does not cover human error | Deep storage holds segments; back up deep storage and the metadata store (confirm procedure in Druid docs) | Batch segments are pushed to a deep store; confirm backup procedure for your deployment |
| Authentication options | LDAP, Kerberos, SSL X.509, HTTP authenticator and JWT as external authenticators | Confirm supported authentication extensions in the Druid security documentation | Confirm authentication and access controls in the Pinot security documentation |
| Kubernetes deployment | Confirm current Kubernetes operator or Helm options in ClickHouse documentation | Community druid-operator for Kubernetes deployments | Helm chart for Kubernetes deployments |
| Release cadence | Stable releases roughly monthly; LTS twice a year, supported for a year | Druid 38.0.0 published October 1, 2026, after 37.0.0 on May 8, 2026 | Pinot 1.5.1 published June 5, 2026; 1.6.0 release candidate on October 17, 2026; requires JDK 25 or later to build and run |
What Apache-2.0 covers in ClickHouse, Druid and Pinot
The ClickHouse server is open source under the Apache License 2.0, according to its GitHub repository. ClickHouse Inc. separately sells ClickHouse Cloud as a managed service, so a managed option exists alongside the self-hosted server. The license lets your team run, modify and redistribute the server code, but it does not commit anyone to patch your cluster on a schedule.
- Code license: The server source carries Apache-2.0 (SPDX: Apache-2.0), so self-hosting carries no license fee for the server itself.
- Managed option: ClickHouse Cloud is sold by ClickHouse Inc. and is a separate product from the open-source server.
- Security coverage: The ClickHouse security policy lists versions 26.9, 26.8, 26.7 and 26.3 as supported with security updates, and all other versions as unsupported.
- Release model: Stable releases ship roughly monthly, and LTS releases ship twice a year with one year of support.
- Upgrade ownership: Your team or your provider must schedule upgrades, read the changelog and test them, since minor backward-incompatible changes can occur.
Confirm with ClickHouse Inc. or your chosen provider which paid support, escalation or managed terms apply to your deployment.
Apache Druid is an Apache Software Foundation project licensed under the Apache License 2.0, according to the apache/druid repository README and license metadata. The researched facts show no commercial edition of Druid, so the license is the only vendor-level term we can confirm. Community releases continue, with Druid 38.0.0 published on October 1, 2026. Support for a production cluster is a separate question from the license.
- Project governance: Druid is an Apache Software Foundation project, which governs the code and its release process.
- Release cadence: Druid 38.0.0 followed 37.0.0 on May 8, 2026 and 36.0.0 on February 9, 2026.
- Multi-service footprint: A production cluster runs Master, Query and Data services, plus deep storage, a metadata store and ZooKeeper, so patching covers several components.
- Kubernetes tooling: The README points to the community druid-operator for Kubernetes, which is community-maintained rather than a vendor product.
- Paid options: No commercial Druid edition or managed service appears in the researched facts.
Ask any Druid provider you evaluate to state in writing whether it offers paid support, security patch commitments or managed hosting, and what those cover.
Apache Pinot is licensed under the Apache License 2.0 and is a real-time distributed OLAP datastore. The researched facts show no commercial edition of Pinot, so any paid support or managed service has to come from a named provider that you verify. The Apache license grants code rights only. It does not decide who fixes a defect in your cluster at 2 a.m.
- Project governance: Pinot is an Apache Software Foundation project under the Apache License 2.0.
- Release activity: Apache Pinot 1.5.1 was published on June 5, 2026 after 1.5.0 on April 9, 2026, and a 1.6.0 release candidate followed on October 17, 2026.
- Runtime requirement: Pinot services require JDK 25 or later to build and run, while Java and JDBC clients continue to target Java 11 bytecode.
- Coordination dependency: Pinot uses Apache Helix with Apache ZooKeeper as its state store, so ZooKeeper patching becomes part of your operations.
- Managed options: No Pinot managed service appears in the researched facts, so confirm availability with each provider.
Check the JDK 25 requirement against your hosts and approved images before you plan a Pinot build.
What drives the running cost of each cluster
The three databases share a running-cost profile: a coordination layer, storage tiers, skilled people, upgrades, backups and hardware. The cards below cover each driver and say who is paid for the work, what recurs, and what to ask for in a quote, so you can compare clusters on the same basis.
Coordination services
ClickHouse replicated tables depend on ClickHouse Keeper, which the replication guide recommends running as at least three nodes on dedicated hosts in production, with about 4 GB of RAM each. Pinot relies on Apache Helix with ZooKeeper for cluster state, and Druid depends on ZooKeeper for service discovery and leader election. Each option adds hosts to patch, monitor and back up. Ask whether your team already operates ZooKeeper or Keeper, since that changes whether this is new work or routine work.
Storage and deep store
Druid writes segments to deep storage such as S3, HDFS or local disk and keeps a separate metadata store, typically PostgreSQL, MySQL or Derby, so both must be sized, secured and backed up. Pinot pushes batch-built segments to a deep store that servers download from. ClickHouse keeps data on the cluster's own disks and uses object storage only when you choose it for backups. Storage cost recurs with retention and replication, so ask how long raw events are kept and how many copies each layout holds.
Staff skills and on-call load
Internal staff carry most of the cost for a self-hosted cluster, including tuning, incident response and capacity planning. Druid asks operators to understand its Master, Query and Data service split and three external systems. Pinot asks them to understand controllers, brokers, servers and minions with Helix. ClickHouse has fewer moving parts to learn but still needs replication and Keeper expertise. Pay a provider or DeployOpen under a written scope for training or on-call coverage if your team lacks these skills, and ask for that scope in writing.
Upgrades and release tracking
ClickHouse ships stable releases roughly monthly and LTS releases twice a year, with LTS supported for a year, and its FAQ advises a pre-production test and a changelog review before each upgrade. Druid and Pinot also publish regular releases, and Pinot's current requirement of JDK 25 or later may force a runtime upgrade. Each upgrade cycle recurs, so budget time for testing against your own queries. Confirm which release line each vendor supports for your target date before you commit.
Backup and restore testing
ClickHouse BACKUP and RESTORE cover full and incremental backups to local disk, S3-compatible storage or Azure Blob Storage, and the documentation notes that replication does not protect against human error or corruption. It also warns that a backup never test-restored will probably not restore when needed. Restore tests need a spare cluster, storage and staff hours, which recur on a schedule. Druid and Pinot require the equivalent work on deep storage and metadata stores. Ask any provider to include restore tests in the written scope.
Hosting footprint
Total hardware cost depends on the number of hosts each layout needs: coordination nodes, brokers or query nodes, data nodes and, for Pinot and Druid, controllers, minions or middle managers. Dedicated Keeper hosts, separate broker tiers and replicas for availability all multiply the server count. Larger footprints raise cloud or data center costs every month and add patching work. Ask vendors and implementers to show the node count for your traffic and retention, and compare that count across all three options.
What implementing each platform involves
The first setup decision for ClickHouse is the replicated layout. Tables that need redundancy use ReplicatedMergeTree, and ClickHouse Keeper coordinates the replicas in place of ZooKeeper. The replication guide recommends at least three Keeper nodes on dedicated hosts in production, with about 4 GB of RAM each, so a replicated cluster needs coordination capacity in addition to its data nodes. A recovered replica syncs missing data from a healthy replica without manual steps, which reduces routine recovery work. You still need to decide the number of shards and replicas, whether Keeper runs on separate hosts or inside clickhouse-server, and how upgrades will follow the monthly stable releases and twice-yearly LTS releases. Confirm each choice with a pre-production test on representative data and queries.
Druid asks you to run the most external systems of the three. A cluster has Master services (Coordinator and Overlord), Query services (Broker and Router) and Data services (Historical and Middle Manager or Indexer), and it depends on deep storage such as S3, HDFS or local disk for segments, a metadata store typically PostgreSQL, MySQL or Derby, and ZooKeeper for discovery, coordination and leader election. Each dependency needs its own sizing, backup and upgrade plan. The Druid README points to a community druid-operator for Kubernetes, so confirm which Druid versions it tracks, how it is maintained and who fixes it when a Druid release changes behavior. Pinot also depends on ZooKeeper through Apache Helix, so a ZooKeeper ensemble appears in two of the three designs. The Druid architecture documentation describes these roles in detail.
Pinot sets the first hard runtime requirement: its services need JDK 25 or later to build and run, while Java and JDBC clients still target Java 11 bytecode, so application clients and cluster hosts can change on different schedules. Controllers, brokers, servers and minions rely on Apache Helix and ZooKeeper for state, and batch-built segments move through a deep store that servers download from. Confirm the JDK and ZooKeeper versions against the Pinot release you plan to deploy, including any 1.6.0 candidate you evaluate. For ClickHouse, the backup documentation covers full and incremental BACKUP and RESTORE to local disk, S3-compatible storage or Azure Blob Storage, and it warns that replication does not protect against human error or corruption. A backup that has never been test-restored will probably fail when you need it, so schedule restore tests on spare clusters. Each implementation's scope, deliverables and timeline are agreed in writing before work starts.
How to run a proof of concept on your own workload
This sequence tests each engine against your own queries, event volumes, data model and recovery expectations, so the shortlist is decided on evidence from your environment rather than vendor material. Each step produces a written result that feeds the final comparison.
Document query shapes and concurrency targets
Your data or platform team lists the dashboards, user-facing API calls and ad hoc queries the system must serve, grouped by shape: time-range filters, group-bys, top-N lists, joins to dimension tables and point lookups by key. For each shape, record the expected number of concurrent users or API callers and the latency your product needs. Use this list as the test suite for every engine. The step is done when the team has a signed-off query catalog with concurrency targets, so each candidate is measured against the same workload rather than against demo queries.
Replay a Kafka stream at expected volume
Set up a Kafka topic with a representative sample of your events and replay it at your projected peak rate and at a higher rate to find headroom. Connect each candidate through its native Kafka ingestion path: a Druid supervisor, a Pinot real-time table, or a ClickHouse Kafka-based ingestion setup your team confirms against current documentation. Measure ingestion lag, the time from event to queryable row, error handling for malformed messages and how the system behaves when a broker or ingestion task restarts. The step is complete when each engine has a lag curve and a documented restart result under the same load.
Test upserts and joins your queries require
Identify which of your use cases need updates to existing rows, such as order status changes or deduplicated user profiles, and which need joins between event tables and dimension tables. Pinot documents real-time upserts and fact and dimension joins, and Druid and ClickHouse handle these through different data models that your team must verify for its own schema. Run the join-heavy and upsert-heavy queries from your catalog, record whether each one runs as written, what changes are needed, and how query results compare with a reference answer from your source system. The step is complete when every required pattern is marked as supported, rewritten or rejected for each engine.
Run a restore test on a spare cluster
Take a backup of a test dataset using each engine's documented backup approach, then restore it to a separate spare cluster and run the query catalog against the restored copy. ClickHouse documents full and incremental BACKUP and RESTORE and warns that a backup never test-restored will probably not restore properly, so this test is required rather than optional. For Druid and Pinot, confirm how deep storage, the metadata store and segment or table state are recovered and time the restore internally. The step is complete when each restored system returns the same query results as the source and the team has written down the exact restore steps and who runs them.
Compare release cadence with your upgrade window
Map each candidate's release model against the maintenance windows and change approval cycle your organization actually runs. ClickHouse ships stable releases roughly monthly and LTS releases twice a year, with LTS supported for a year, and its security policy lists the currently supported versions. Confirm the release and support policy for Druid and Pinot with their maintainers, including how long a given line receives fixes and how dependencies such as Java and ZooKeeper change between releases. The step is complete when the team has a table showing, for each engine, the version it would run, the date that version stops receiving fixes and the planned upgrade path, reviewed by the operations owner.
Questions buyers ask before choosing ClickHouse, Druid or Pinot
Which of the three costs the least to run?
No single engine wins on cost in every case, and the answer depends on the number of services your team must keep healthy. ClickHouse runs as one server type that you can start on a single node, with replication handled by ClickHouse Keeper, so the component count is the smallest of the three. Druid splits work across Master, Query and Data servers and depends on deep storage, a metadata store and ZooKeeper. Pinot runs controllers, brokers, servers and minions on Helix and ZooKeeper. Ask each vendor or a partner to size your own workload, including ingest rate, query concurrency, retention and the hardware and staff hours for upgrades and backups.
How long does an implementation take?
The duration depends on the written scope, not on the engine name alone. A scope that covers one Kafka topic, one dashboard use case and a single cluster is different from a multi-tenant deployment with upserts, joins, access control and a backup and restore test. Most DeployOpen engagements are fixed-scope, so scope, deliverables and timelines are agreed in writing before work starts. Ask for a timeline tied to named deliverables and to your environment, including cloud accounts, network approvals and data residency reviews.
What does the work need from our internal team?
Your team needs to own the data sources, the schema decisions, the query workload and the business acceptance criteria. Platform work also needs people who can operate Linux hosts, networks, storage and monitoring, and who can read changelogs before upgrades. For ClickHouse, the production guidance recommends a pre-production environment with representative data and queries. Druid and Pinot add more service roles to staff. Confirm who will handle on-call, upgrade windows and restore tests before choosing an engine.
Can a team run the cluster itself after launch?
Many teams can, provided they have someone who understands replication, failure recovery and capacity planning. A recovered ClickHouse replica syncs missing data from a healthy replica without manual intervention, which reduces routine work, but backups still need a plan. The ClickHouse backup documentation warns that a backup never test-restored will probably not restore properly, and it recommends regular restore tests on spare clusters. Outside help is often used for the first production rollout, then handed over with runbooks, or retained for upgrades and continuous testing.
Do Druid or Pinot require Java skills?
Yes, both platforms are Java-based and your team will need Java skills for troubleshooting, tuning and build work. The Pinot README states that Pinot services require JDK 25 or later to build and run, while Java and JDBC clients continue to target Java 11 bytecode. Druid also runs on the JVM, and its ingestion and query operations are exposed through HTTP, JDBC and a built-in web console, so routine tasks may not require writing Java. Confirm the current Druid JDK requirement with the Druid project before sizing hosts. ClickHouse is written in C++ and is operated through SQL and configuration files.
Does ClickHouse need ZooKeeper?
No. ClickHouse replicates data with ReplicatedMergeTree tables coordinated by ClickHouse Keeper, which replaces ZooKeeper for that purpose. The replication guide recommends at least three Keeper nodes on dedicated hosts in production, with about 4 GB of RAM each. Druid depends on ZooKeeper for service discovery, coordination and leader election, and Pinot uses Apache Helix with ZooKeeper as its state store. If your organization already runs ZooKeeper for other systems, confirm whether that matters for your operations model, since ClickHouse does not require it.
What does switching to another engine later involve?
Switching is mostly a data model, ingestion and query migration, not a configuration change. Each engine has its own ingestion path: Druid reads Kafka and Kinesis through supervisors, Pinot real-time tables ingest from Kafka, Pulsar and Kinesis, and ClickHouse has its own table engines and ingestion patterns. Query SQL and native query features also differ, so dashboards and jobs need review. Plan for a parallel run, a reconciliation of results on your own data, and a restore test of the backups you keep. Ask any partner to price the migration as a separate written scope.
When is outside help worth the cost?
Outside help is worth considering when the first production rollout carries high stakes, when the internal team has no one with platform operations experience, or when compliance evidence must be prepared for an assessment. DeployOpen plans, implements, hardens, backs up, upgrades, documents and supports self-hosted platforms inside your own infrastructure, and it prepares controls and evidence for assessments, but it does not issue audit reports or certifications. Ask for a written scope that names the engine, the environment, the handover deliverables and the support terms, then compare that quote with the internal hours it replaces.
How DeployOpen helps teams choose and run an analytics cluster
DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For this choice, we work through the workload, the team and the operating model before anyone picks a database, so the decision rests on your event volumes, query shapes and staffing.
How we scope
- Define the event sources, Kafka topics, query shapes and concurrency targets the cluster must serve.
- Agree in writing which candidates are tested, which node roles and coordination services are in scope, and what success looks like.
- Engagements are fixed-scope, with deliverables and timelines agreed before work starts, and written quotes follow from that scope.
How we build
- Stand up a pre-production cluster with representative data, Kafka ingestion and your own queries to compare candidates.
- Configure replication, the coordination service (ClickHouse Keeper or ZooKeeper, as applicable), backups and restore tests in your environment.
- Test security controls such as authentication, access rules and network paths, and document the results for your reviewers.
How we hand over
- Deliver runbooks for upgrades, node replacement, backup and restore, and scaling each chosen cluster.
- Document the architecture, node layout, configuration and the decision record, so your team can explain the choice later.
- Run a knowledge transfer with your operators and review the handover material against the agreed scope before closing.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, scoped separately from the build.
- Plan upgrades against each project's release and support windows, with changelog review before any version change.
- Re-run restore tests and load checks after major changes, so backups and capacity assumptions stay verified over time.
