ClickHouse® Cost Optimization Guide

Cut Your ClickHouse Costs Without Sacrificing Performance

Inside the guide:

  • Find where your ClickHouse costs come from
  • Eliminate unnecessary compute, storage, and I/O
  • Optimize resource usage without sacrificing performance
  • Make better decisions about when to resize infrastructure

Production-focused · Actionable SQL queries · Practical guidance

What you learn

A practical framework for reducing ClickHouse costs.

Find where costs come from

Identify the workloads and resources driving your ClickHouse spend and where to investigate first.

Use diagnostic SQL queries

Run practical queries to uncover expensive workloads, inefficient queries, and more.

Eliminate unnecessary work

Reduce the work ClickHouse performs across compute, storage, and I/O before changing machine sizes or cluster topology.

Optimize resource usage

Apply practical techniques to optimize storage, compute, memory, and network usage without sacrificing performance or reliability.

Preview the guide

High compute? Diagnose what’s driving it before resizing.

If you see:

High compute with modest query volume

Investigate:

  • Large scans
  • Expensive joins or sorts
  • Inefficient schema
  • Merges or mutations

Start with:

system.query_log
EXPLAIN indexes = 1
system.merges
system.mutations
system.part_log

Practical guidance for production environments.

Altinity has spent years designing, operating, and troubleshooting ClickHouse across a wide range of production environments.

This guide brings that experience together into practical techniques you can use to reduce costs while protecting the performance and reliability your workloads require.


The one constant during our deployment and scaling of ClickHouse has been Altinity. We operate a huge ClickHouse cluster and are pretty decent at ClickHouse ourselves, but even then we’ve hit issues that stumped us. Altinity’s support is second to none in terms of the quality and the speed at which they have triaged and resolved our issues. The first thing I tell anyone who is running ClickHouse in their business’s critical path is to get a contract with Altinity”

-James Greenhill, PostHog


ClickHouse Cost Review

Want help finding your biggest cost drivers?

Get a free 45-minute ClickHouse Cost Review with an Altinity engineer. Bring your architecture, cloud bill, or planned workload. We’ll help identify likely cost drivers and prioritize next steps.

Book my cost review


It was a very helpful consultation, amazing. The [engineers] gave me some pointers on how I can address the issues I am facing…overall, super helpful!


Common ClickHouse Cost Optimization Questions

What are the biggest drivers of ClickHouse costs?

ClickHouse costs are typically driven by the resources your workloads consume across compute, storage, memory, and network. Query patterns, ingestion, data retention, compression, merges and mutations, indexes and projections, and other workload characteristics can all affect resource usage. The first step is understanding where those resources are being consumed before deciding what to optimize.

How can I identify what is driving my ClickHouse costs?

ClickHouse system tables can help you investigate query activity, table and part sizes, compression, merges, mutations, ingestion behavior, and other resource usage. The guide provides a practical framework for connecting common cost signals with the areas and system tables worth investigating.

Should I optimize my ClickHouse workload before resizing infrastructure?

In many cases, yes. Before changing machine sizes or cluster topology, identify and reduce unnecessary work in the workload. Once you’ve addressed inefficiencies across compute, storage, and I/O, you can evaluate whether the infrastructure is still appropriately sized for what ClickHouse actually needs to do.

What should I investigate when ClickHouse compute usage is high?

Start by determining what is driving the compute usage. High compute with modest query volume may point to large scans, expensive joins or sorts, inefficient schema design, merges, or mutations. If compute is increasing alongside ingestion, investigate factors such as small inserts, part counts, and index or projection maintenance. Tools including system.query_log, EXPLAIN, system.merges, system.mutations, and system.part_log can help narrow down where to look.