You Don't Need a Three-Node ClickHouse Cluster to Get Started
By Ordinal Science ·
A common belief about ClickHouse is that you need a three-node cluster from day one. Many guides and diagrams show one, so teams assume it is the minimum. It is not.
ClickHouse runs very well on a single server. For many small teams, that is the right place to start. You can add replicas later, and then move to a full cluster when you actually need one.
Here is how the three approaches differ, who each one suits, and why a staged path often makes sense.
Option one: a single node.
This is one ClickHouse server holding all your data and answering all your queries. There is no replication and no coordination between machines.
The benefits are simple. It is cheap. It is easy to set up. There are fewer moving parts to monitor and fewer things to break. ClickHouse is built to make good use of a single machine's CPU cores and disks, so one well-sized server can handle a lot of data and fast queries.
The trade-off is resilience. If that server goes down, your analytics go down with it. You will need regular backups and a tested restore process.
A single node suits small teams, early-stage products, internal reporting, and proofs of concept. It also suits any workload where a short outage is annoying but not critical.
Option two: a single node with replicas.
Here you still have one copy of the logical dataset, but it lives on two or more servers. Each server holds a full copy of the data. ClickHouse keeps them in sync using replicated tables and a coordination service called ClickHouse Keeper.
You are not splitting data across machines yet. You are copying it. This is one shard with multiple replicas.
The main benefit is availability. If one server fails, another can keep serving queries. You can also spread read queries across replicas to share the load. Maintenance gets easier too, because you can take one server offline while the others keep running.
The cost is extra complexity. You now run Keeper, and for a reliable setup you want three Keeper instances so they can agree on state if one fails. These can be small and can sit alongside your ClickHouse servers. You also pay for more hardware and need to understand how replication behaves.
This option suits teams whose dashboards or customer-facing features cannot go down for long. It fits when your data still fits comfortably on one machine, but uptime matters.
Option three: a three-node cluster
A full cluster spreads data across multiple servers, each a shard. Each shard holds part of the data. Queries run on all shards in parallel, and the results are combined. Clusters often combine shards and replicas, so you get both scale and resilience.
The benefit is horizontal scale. When your data or query volume outgrows one machine, you add more machines instead of buying a bigger one. Large queries can finish faster because the work is shared.
The trade-off is the most complexity of the three. You need to choose a sharding key. You need distributed tables. You need to think about how data is balanced and what happens when you add shards later. Operations, monitoring and troubleshooting all take more effort and more skill.
A cluster suits teams with large and growing datasets, heavy concurrent query loads, or strict performance targets. It also suits organisations with engineers who have time to run and tune distributed systems.
Why a staged approach makes sense for small teams?
Starting with a cluster can feel like the safe choice. In practice, it often slows small teams down.
First, you may not need it. Many workloads run comfortably on one good server for a long time. Building for scale you do not have yet costs money and attention.
Second, simpler systems are easier to learn. A single node lets your team understand how ClickHouse stores data, how table design affects speed, and how queries behave. Those lessons carry straight into replicated and clustered setups.
Third, you make better decisions with real data. Choosing a sharding key is much easier once you know your actual query patterns and data growth. Guessing early can lock you into a design you later regret.
Fourth, the path forward is clear. You can move from a single node to replicated tables when uptime starts to matter. You can add shards when one machine is no longer enough. Each step solves a real problem you can name.
There is one thing worth planning early. If you expect to add replicas, consider using replicated table engines from the start, even on one node. It can make the later move smoother.
The short version
Start with a single node if you are small or early. Add replicas when downtime becomes a real business risk. Move to a cluster when your data or query load outgrows one machine.
Let your actual needs drive each step. That way you spend your time building useful analytics, not running infrastructure you do not need yet.