5 Years Running Petabyte-Scale ClickHouse Clusters: Lessons Learned
Original: I've operated petabyte-scale ClickHouse clusters for 5 years
Why This Matters
ClickHouse adoption is accelerating; honest operational guides from practitioners at scale are rare and high-value for engineering teams evaluating self-hosted vs. managed paths.
Tinybird engineer shares operational lessons from five years managing petabyte-scale ClickHouse clusters, covering schema design, ingestion patterns, query tuning, and the hidden operational costs teams routinely underestimate when running ClickHouse in production.
Tinybird, a managed ClickHouse platform, published a practitioner's retrospective from an engineer who has operated petabyte-scale ClickHouse deployments for five years. The post draws on real production experience rather than documentation-level guidance. Key themes include schema design trade-offs specific to ClickHouse's columnar storage model, the importance of choosing the right table engine and sort key upfront, ingestion pipeline pitfalls (particularly around small parts and merge pressure), and query performance patterns that differ significantly from traditional OLTP databases. The author also addresses operational realities: monitoring what actually matters, handling schema migrations without downtime, and the staffing burden of on-call responsibilities at scale. The piece is framed partly as a case for Tinybird's managed offering, but the technical content stands independently as a candid account of where teams consistently stumble when self-hosting ClickHouse. No specific customer names or performance benchmarks are cited, but the operational scope—petabytes of data across multi-node clusters—gives context for the advice.