ClickHouse source code is published under the Apache 2.0 License. Software is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.

logo_without_text.svg

Stay informed on feature releases, product roadmap, support, and cloud offerings!

Subscribe to our newsletter

icon-github.svg

icon-slack.svg

icon-telegram.svg

icon-twitter.svg

Join the ClickHouse conversation on

ClickHouse

ClickHouse Cloud

Download

PRODUCT

Documentation

Training

Support

Comparison

Use cases

RESOURCES

Blog

Our story

Careers

Contact us

News and events

COMPANY

Linux, macOS, FreeBSD

* The problem: Aggressive log sampling, often necessitated by the scaling costs of legacy platforms, creates visibility gaps. You risk missing critical errors needed to solve outages and affecting the statistical integrity of your data.  
* The cause: Engineers typically rely on separate stacks for search (ELK) and trends (Prometheus). As data grows, neither scales efficiently for the other’s workload, forcing teams to sample logs to control costs.  
* The solution: OpenTelemetry provides the universal standards and semantic conventions required to break down the silos between logs, metrics, and traces. When this unified, OpenTelemetry-standard data needs to be stored at scale, modern columnar architectures are the solution. By using ClickHouse, teams benefit from 10-20x compression and a cloud-native design that separates compute from cost-efficient object storage. The ClickStack (the ClickHouse Observability Stack) embodies this architecture to help reduce trade-offs.  
* The proof: Engineering teams are achieving petabyte-scale ingestion and real-time analysis on 100% of their observability data, moving away from sampling to gain complete visibility without a runaway budget.

TL;DR: minimizing the need for log data compromise

## **Introduction: the scaling compromise**

As infrastructure scales into the petabytes, observability costs often follow a steep upward trajectory. To keep budgets under control, engineers are frequently advised to accept a difficult compromise: aggressive sampling.

Historically, engineers have relied on separate stacks to manage this data: search-based tools (like ELK) to isolate specific errors, and metric stores (like Prometheus) to monitor system health. Sampling became the primary survival mechanism to keep these distinct architectures affordable.

However, this compromise is a symptom of using legacy tools at a scale they were not designed for. The choice between complete visibility and a manageable budget does not have to be binary. In practice, sampling introduces risks that create critical blind spots.

### **You risk losing the "needle in the haystack"**

The most immediate risk is missing the low-frequency, high-severity event you didn't know you needed to look for. Critical system failures are often outliers: a single corrupt transaction, a slow API call causing tail latency, or a novel security threat. Aggressive sampling statistically increases the likelihood of discarding these exact events. By definition, it is difficult to write a sampling rule for an "unknown unknown" error you have never seen before. When a major outage occurs, the log line containing the root cause may have been dropped.

### **You compromise data integrity**

Beyond missing rare events, sampling can skew the statistical integrity of your data. When a percentage of telemetry is discarded, analytics become approximations. For example, sampling-based systems can under- or overestimate crucial metrics, such as duration, rendering percentile-based SLOs and trend analyses less reliable. This makes it difficult to accurately measure the true impact of minor issues or perform forensic analysis after a security incident.

### **You create operational complexity**

Maintaining complex sampling rules creates a significant operational task. Engineers must constantly adjust sampling configurations as applications evolve and new services come online. The criteria for what constitutes a "low-value" log today could be the critical signal for tomorrow's outage, requiring engineers to engage in a reactive cycle of adjusting rules.

| Risk category | Description | Business impact |
| ----- | ----- | ----- |
| Missing critical events | Low-frequency but high-severity events ("unknown unknowns") are statistically likely to be dropped by sampling rules. | Increased Mean Time to Resolution (MTTR) during major outages; missed security threats from unusual sources. |
| Compromised analytics | Discarding data skews metrics, making percentile-based SLOs, trend analysis, and capacity planning less reliable. | Inaccurate performance measurements; reduced trust in dashboards; difficult resource allocation and decision-making. |
| Operational complexity | Engineers must constantly create, manage, and update complex sampling rules as services and applications evolve. | Engineering resources spent on reactive infrastructure management; risk of human error leading to data loss. |

## **The architectural shift: unifying search and trends**

For years, sampling was a reaction to the architectural boundaries of available tools. We relied on search engines (Splunk, Elastic) that excelled at finding a specific error message but were less efficient at high-level aggregations and trends. Conversely, we used metric stores (Prometheus) that were excellent for trends but lacked the context of the raw event.

Modern OLAP databases eliminate this trade-off by excelling at both fast aggregations and high-speed filtering. ClickStack, the ClickHouse Observability Stack, embodies this architecture to provide an end-to-end, open-source solution. It allows engineers to see high-level trends and quickly drill down to the raw logs without jumping between tools.

The solution starts with open, vendor-neutral data collection via OpenTelemetry. OpenTelemetry acts as the critical bridge, providing the shared semantic conventions that allow you to seamlessly correlate logs with metrics and traces. From there, ClickStack uses ClickHouse as the scalable storage and analytics engine, and HyperDX as a purpose-built UI.

### **From storage overhead to efficient analytics**

Legacy platforms often face two challenges at scale: storage overhead and query performance. The first is a significant "indexing overhead." Reliance on inverted indexes for search creates storage requirements that can grow larger than the raw data itself. It's not uncommon for an initial 3GB of logs to [consume 30GB of disk space](https://stackoverflow.com/questions/27972246/elasticsearch-index-much-larger-than-the-actual-size-of-the-logs-it-indexed) in an Elasticsearch cluster.

The second challenge is analytical performance. While effective for search, inverted index architectures can struggle with the large-scale aggregations needed for observability. In contrast, ClickHouse is built for analytics. It uses lightweight [sparse primary indexes](https://clickhouse.com/docs/guides/best-practices/sparse-primary-indexes) on data that is physically sorted on disk. When you query a time range, ClickHouse uses this index to skip reading vast blocks of data. This I/O reduction is combined with a vectorized execution engine that processes data in batches and massively parallel processing that uses available CPU cores.

### **From row-oriented storage to columnar compression**

Traditional platforms are often row-oriented, storing all values for a single log event together. ClickHouse uses a columnar format, storing all values for a single column (e.g., all timestamps, all service names) together. This structure is highly effective for compression, creating results that routinely achieve [10-20x compression](https://clickhouse.com/resources/engineering/database-compression) ratios.

A common trade-off with columnar stores has been handling messy, semi-structured logs efficiently. ClickHouse addresses this with its native [JSON data type](https://clickhouse.com/blog/a-new-powerful-json-data-type-for-clickhouse). This feature offers the performance of a defined schema with the flexibility of a document store.

The JSON data type works by dynamically analyzing the data structure:

* Optimized column generation: It automatically identifies the most frequent properties and creates dedicated, optimized columns for them.  
* Long-tail bucketing: Rare or "long-tail" properties are bucketed into a generic store to prevent "column explosion," which effectively balances write performance with query speed.  
* Native types: Integers stay integers and aren't lazily cast to strings, maintaining high query performance.

*Note: While this simplifies ingestion significantly, it does require engineers to consider query patterns. Accessing the dedicated columns is faster than querying the "long-tail" bucket, meaning schema design still matters for optimal performance on your most frequent queries.*

This efficiency applies not just to logs, but also to high-volume traces and high-cardinality metrics. To further bridge the gap between metrics and logs, ClickHouse is actively working on PromQL support, which will allow engineers to bring their existing Prometheus queries and dashboards directly to ClickHouse without rewriting logic.

### **From coupled architecture to decoupled storage and compute**

Legacy systems often couple storage and compute resources. In these systems, storage and compute are tightly linked, forcing you to scale expensive servers just to retain more data. In contrast, ClickHouse was [designed for the cloud](https://www.slideshare.net/slideshow/clickhouse-at-cloudflare-by-marek-vavrusa/79778005), using cost-efficient and scalable [object storage](https://blog.cloudflare.com/log-analytics-using-clickhouse/) like Amazon S3 or Google Cloud Storage. This decouples storage from compute, allowing you to retain 100% of your data at a lower cost while scaling compute resources independently.

## **Proof in production: handling massive scale**

This architectural shift is becoming the standard for companies operating at the largest scale.

Cloudflare, which helps secure and accelerate a significant portion of the internet, was an [early adopter of ClickHouse](https://blog.cloudflare.com/log-analytics-using-clickhouse/). Their previous Elasticsearch-based pipeline struggled with ingestion limitations when faced with millions of requests per second. The ingestion rate limited their ability to query data in real-time. By migrating to ClickHouse, they removed these ingestion bottlenecks. The engineering outcome was the ability to query across massive datasets with low latency, powering critical systems like firewall analytics.

More recently, Anthropic required an architecture capable of ingesting [semi-structured data](https://clickhouse.com/blog/how-anthropic-is-using-clickhouse-to-scale-observability-for-ai-era) in real time to support their Claude AI models. When the Claude 3 and 3.5 models saw explosive user adoption, their existing observability systems faced scaling friction. With ClickHouse, Anthropic can now affordably store and instantly query 100% of their log data. The system is robust enough that engineers report they "sometimes don't even notice that the database is running."

| Company | Challenge | Solution with ClickHouse | Key outcome |
| ----- | ----- | ----- | ----- |
| Cloudflare | Previous pipeline struggled with ingestion throughput and resource efficiency at millions of logs per second. | Migrated logging pipelines to a self-managed ClickHouse cluster for superior ingestion speed and compression. | Petabyte-scale real-time analysis. Engineers can grep through massive datasets in seconds, enabling faster debugging and reliable customer analytics. |
| Anthropic | Existing systems faced scaling friction due to the data volume generated by Claude AI models. | Deployed ClickHouse to ingest and analyze 100% of their log data in real-time within their secure environment. | Full data retention at scale. Enabled deep model insights and robust debugging without requiring data sampling. |

## **Conclusion: stop sampling, start analyzing**

The trade-offs regarding log sampling have shifted. The practice of sampling was largely a workaround for the architectural limitations of search-based platforms and the separation of "search" and "metrics" tools. Storing 100% of your data is becoming the strategic standard for modern engineering teams.

A modern columnar platform like ClickStack, built on ClickHouse, changes the relationship between cost and performance. By decoupling compute from cost-efficient object storage and using 10-20x compression, it is economically feasible to retain petabytes of data. This architecture provides the visibility to find any "needle in the haystack," accurately analyze trends, and reduce the risk of missing the one critical event that explains a major outage.

It's time to move beyond the choice of sampling and start analyzing everything.

Ready to see for yourself? [Start a free ClickHouse Cloud trial](https://clickhouse.com/cloud) to experience petabyte-scale analytics firsthand. You can also [read our case studies](https://clickhouse.com/user-stories) with companies like Anthropic and Cloudflare who manage massive-scale observability with ClickHouse.

Frequently asked questions

Beyond sampling: managing petabyte-scale logs without losing data

For many engineering leaders, the observability bill has become one of the largest infrastructure expenses. OpenAI reportedly spends [$170 million annually on Datadog alone](https://finance.yahoo.com/news/guggenheim-downgrades-datadog-fears-openai-135303763.html). While most companies aren't operating at OpenAI's scale, teams consistently report that observability tools [consume a significant portion of their total cloud spend](https://www.reddit.com/r/sre/comments/186nnh6/benchmarks_for_observability_spend/), and the trend only goes in one direction: up.

The root cause? SaaS platforms charge per gigabyte ingested, per host monitored, or per high-cardinality metric tracked. The more visibility you need, the more you pay. You're stuck choosing between understanding your systems and staying within budget. This model prevents you from being able to “send everything.”

You can break this cycle by changing how you pay for observability. Instead of variable costs tied to data volume, you can move to predictable infrastructure costs. This guide shows you exactly how to calculate and reduce your [observability](https://clickhouse.com/resources/engineering/observability) Total Cost of Ownership (TCO) using a unified architecture powered by ClickHouse and the open-source ClickStack.

## **Key takeaways**

* Observability costs are driven by misaligned models: The primary problem is punitive SaaS pricing based on data ingestion or per-host metrics, forcing a choice between visibility and budget.  
* Incumbent architectures are inefficient: Traditional tools built on search indexes are ill-suited for observability workloads. They suffer from massive storage overhead and fail at high-cardinality analytics, causing costs to explode.  
* Columnar architecture is the solution: Shifting to a columnar database like ClickHouse is the single biggest cost-reduction lever. It provides superior compression (15-50x) and excels at high-cardinality queries that cripple other systems.  
* A true TCO must include "people costs": A self-hosted stack is not free. The "People TCO" for engineering maintenance and on-call duties can add $1,600-$4,800 per month, often making a managed service like ClickHouse Cloud more cost-effective, especially for bursty workloads.  
* A unified stack (ClickStack) eliminates silos: Adopting a unified architecture like the open-source ClickStack consolidates logs, metrics, and traces, eliminating data duplication and the high TCO of managing multiple, federated systems.  
* Significant savings are achievable: Industry leaders like Anthropic, Didi (30% cost cut, 4x faster), and Tesla (1 quadrillion rows ingested) have used this approach to achieve substantial savings.

## **Why your observability bill is exploding (and it's not your fault)**

The explosion in observability costs comes down to [architectural failure](https://clickhouse.com/resources/engineering/best-open-source-observability-solutions#what-makes-the-database-the-heart-of-a-modern-observability-stack), not budget failure. Two core problems drive these costs: inefficient technology and misaligned pricing models.

Many traditional observability platforms rely on search indexes like Lucene. While these work well for text search, they're fundamentally mismatched for the [aggregation-heavy analytical workloads](https://clickhouse.com/docs/use-cases/time-series/analysis-functions) that modern observability demands.

This mismatch creates two major cost drivers:

1. Massive storage and operational overhead: The Lucene inverted index creates huge storage overhead, often multiplying data size, and compresses data poorly. A team ingesting 100TB daily could face storage costs exceeding $100,000 per month. Worse, this architecture is fragile at scale. A single node failure can trigger a massive data rebalancing process that throttles the cluster and can take days to recover, severely impacting stability.  
2. The high-cardinality crisis: Modern distributed systems generate telemetry rich with unique dimensions (user_id, session_id, pod_name). Systems like Prometheus struggle because every unique combination of labels creates a new time series, leading to an explosion in memory usage and slow queries. Index-based systems crumble under this load. Query times balloon, memory errors appear, and clusters become unstable.

Beyond architecture, misaligned pricing models penalize scale. SaaS vendors often charge a "tax" on visibility: you pay for ingestion, but to keep that data indexed and searchable requires a separate, expensive retention SKU. Furthermore, pricing models based on "per-host" or "per-container" counts punish modern microservices architectures, where infrastructure is ephemeral and highly distributed.

The fix requires two changes: switch to a [columnar database](https://clickhouse.com/resources/engineering/what-is-columnar-database) like ClickHouse that compresses data properly and handles analytics efficiently, then separate storage from compute using cheap object storage like S3 as your primary data tier. This approach tackles both cost problems head-on.

Columnar storage groups similar data types together, enabling specialized compression codecs that achieve [remarkable compression ratios](https://clickhouse.com/blog/log-compression-170x). ClickHouse's internal observability platform compresses 100 PB of raw data down to just 5.6 PB. This level of efficiency contributes to significant cost savings, with our internal use case proving to be up to 200x cheaper than a leading SaaS vendor.

ClickHouse was built specifically for fast analytical queries scanning select columns across billions of rows. It handles high-cardinality aggregations that would bring other systems to their knees. Tesla's platform demonstrates this power, [ingesting over one quadrillion rows with flat CPU consumption](https://clickhouse.com/blog/how-tesla-built-quadrillion-scale-observability-platform-on-clickhouse), solving the high-cardinality problem that cripples other metrics systems.

## **How to calculate your observability TCO: a practical framework**

To make good financial decisions, you need a comprehensive Total Cost of Ownership (TCO) model. A proper TCO analysis [includes all direct and indirect costs](https://en.wikipedia.org/wiki/Total_cost_of_ownership), especially engineering time that often gets overlooked.

This framework compares three primary architectural models:

1. SaaS platforms (e.g., Datadog, Splunk): All-in-one vendor solutions priced on data ingestion, hosts, or users.  
2. Federated OSS (e.g., "LGTM" Stack): Self-managed stacks using separate open-source tools (Loki for logs, Mimir for metrics, Tempo for traces).  
3. Unified OSS database (e.g., ClickHouse): Self-managed or cloud-hosted stacks built on a single, high-performance database for all telemetry.

Use this table as your TCO calculation template:

| Cost category | Variable / calculation method | Key considerations by model (SaaS, Federated, Unified) |
| ----- | ----- | ----- |
| Licensing and service fees | ($/GB Ingested) + ($/Host) + ($/User) + (Add-on Features) | **SaaS:** This is the primary cost. It is highly variable and scales directly with data volume and system complexity.   **Federated/Unified (OSS):** $0 for open-source licenses.   **Unified (Cloud):** A predictable service fee that bundles compute, storage, and support. |
| Infrastructure - compute | Instance Cost/hr × Hours/mo × # Nodes | **SaaS:** Bundled into the service fee.  **Federated OSS: very high.** Requires provisioning and managing *separate* compute clusters for logs, metrics, and traces.  **Unified database: medium.** A single cluster handles all data types. Cloud models can scale compute to zero. |
| Infrastructure - storage | (Price/GB-mo × Hot Data) + (Price/GB-mo × Cold Data) | **SaaS:** Bundled, but often with high markups and expensive "rehydration" fees to query older data.  **Federated OSS: medium.** Data and metadata (e.g., labels) are often duplicated across three different systems.  **Unified database: low.** A single store with high-compression (15-20x) and native tiering to object storage minimizes this cost. |
| Operational - personnel | SRE Hourly Rate × Hours/mo (for Maintenance, Upgrades, On-call) | **SaaS: minimal.** Covered by the vendor's service fee.  **Federated OSS: very high.** Requires 24/7 on-call expertise for 3+ complex distributed systems. Unified database: high (for self-hosted) or minimal (for a managed cloud service). |
| Migration and training | (Engineer Hours × Rate) to rebuild assets & train staff | **SaaS: High lock-in.** Migrating *off* requires rebuilding all assets.  **Federated OSS: High.** Team must learn and use 3+ different query languages and datastores (LogQL, PromQL, TraceQL), each with their own scaling properties and considerations.   **Unified database: Medium.** Team learns one powerful, standard language (SQL). |

## **The 'People TCO': a deeper look at personnel and training costs**

The "Operational - personnel" and "Migration and training" line items deserve special attention. While they're easy to list, these "People TCO" categories often become the most significant and unpredictable factors in your entire cost model.

The operational personnel cost varies dramatically by architecture. SaaS platforms require minimal personnel investment. A unified database demands dedicated database and systems engineering expertise. But federated OSS stacks often cost the most, requiring 24/7 on-call coverage for three or more separate distributed systems.

Migration and training present two distinct challenges:

1. Asset migration: For established organizations, this is a large engineering project. You'll need to recreate hundreds or thousands of dashboards, alerts, and service integrations.  
2. Cultural and educational shift: The ongoing training burden varies significantly. Federated OSS stacks force teams to learn multiple domain-specific query languages (LogQL, PromQL, TraceQL). A unified SQL approach consolidates training onto a single standard, though teams still need to transition from proprietary tools like Splunk's SPL.

Budget for this transition using:

Training Cost = (Number of Engineers x Avg. Training Hours x Loaded Engineer Hourly Rate) + (Productivity Dip %)

While this represents a real short-term cost, the long-term benefits are substantial. Engineers can grow from dashboard operators into data analysts. They gain the ability to run deep, ad-hoc SQL analyses and correlate observability telemetry directly with production business data. This level of insight remains impractical, if not outright impossible with proprietary, siloed tools.

But SQL empowerment brings its own challenge: incident response. When production is on fire, SREs don't have time to craft complex SQL joins. They need answers fast. That's why a database alone won't cut it. ClickStack includes [HyperDX](https://clickhouse.com/docs/cloud/manage/hyperdx), which puts a familiar Datadog-style interface on top of the SQL engine. You get Lucene-style querying for quick debugging during incidents, plus full SQL access when you need to dig deeper for root cause analysis. Your on-call team stays productive while your senior engineers retain full analytical power.

## **Architectural trade-off: unified SQL vs. federated OSS stacks**

Once you select the OSS deployment model for observability, you face a more fundamental decision: why choose a unified SQL database over popular alternatives like the federated "LGTM" stack?

The federated model follows a "divide and conquer" principle. Loki optimizes for index-free log ingestion and label-based querying. Mimir provides horizontally scalable Prometheus-compatible metric storage. Tempo handles high-volume trace ingestion and lookup by ID. Each component scales independently and excels at its specific task.

But this specialization creates significant long-term TCO and usability challenges. You're deploying and securing three or more complex distributed systems because the individual tools have no native support for other signals. For example, Prometheus cannot store logs or traces, and Loki cannot process metrics. Data remains siloed. This forces a choice between label-driven search (Loki) or fast aggregations (Mimir), but you cannot get both in one system. While Grafana provides correlation, it forces engineers into a rigid, opinionated workflow (e.g., metrics-to-traces-to-logs) and fails when exploratory analysis is needed. This model has two critical flaws:

* It fails on high-cardinality data and encourages pre-aggregation. Prometheus's data model struggles with high-cardinality dimensions, leading to performance issues and cost explosion. The common workaround is pre-aggregation, which destroys data fidelity and prevents true root cause analysis because the raw, detailed data is lost before it's even stored.  
* Loki's design blocks exploratory analysis. It's fast for lookups by indexed labels (like a trace ID) but cannot be used for the 'search-style' discovery that SREs rely on in a crisis.

The [unified SQL model](https://clickhouse.com/blog/evolution-of-sql-based-observability-with-clickhouse) treats observability as a single analytical data problem. All telemetry flows into one database, one system. This brings several key advantages:

1. True correlation: Engineers use standard SQL to JOIN across all three signals and correlate with business data to find root causes.  
2. Operational simplicity: Manage a single, scalable data store instead of three.  
3. No data duplication: Labels and metadata get stored once, not triplicated across separate databases.  
4. A single query language: SQL provides a powerful, universal standard most engineers already know.

Furthermore, a unified database is the only architecture that enables true "observability science." This is the ability to JOIN observability data with business data (e.g., user signups, revenue tables) for deeper, more impactful root cause analysis. This strategic differentiator, highlighted by customers like Sierra, connects system performance with business outcomes in a way that siloed tools cannot.

While federated stacks offer specialized tools, the unified SQL approach delivers more power, better economics, and simpler operations by solving signal correlation at the database level.

## **Designing a cost-effective observability architecture**

ClickHouse enables you to abandon the siloed "three pillars" model for a unified architecture where logs, metrics, and traces live in a single database. This eliminates data duplication and unlocks powerful cross-signal analysis through standard SQL.

This unified model also handles high-performance text search for logs, using features like inverted indices (currently in beta) and bloom filters, allowing it to replace both analytical (Prometheus) and search (ELK) backends in a single system.

![image1.png](/uploads/image1_bf1ccbfe4c.png)

You can deploy this architecture three ways, each with distinct TCO implications:

1. [Self-hosted ClickHouse](https://clickhouse.com/docs/operations/tips): Deploy and manage open-source ClickHouse on your infrastructure. Maximum control comes with the highest operational burden. Collect data with agents like [OpenTelemetry Collector](https://clickhouse.com/docs/use-cases/observability/clickstack/ingesting-data/otel-collector) and visualize with tools like Grafana.  
2. [ClickStack (Open-source bundle)](https://clickhouse.com/use-cases/observability): An end-to-end open-source stack bundling OpenTelemetry Collector, ClickHouse, and HyperDX UI for a cohesive, [ready-to-deploy experience](https://clickhouse.com/docs/use-cases/observability).  
3. [ClickHouse Cloud](https://clickhouse.com/cloud) with ClickStack: The official managed service provides production-ready ClickHouse with zero infrastructure management. Near-zero operational overhead and elastic scaling let engineering teams focus on their core product. This option includes a bundled ClickStack experience, with HyperDX integrated into the Cloud console.

Choose based on your team's expertise, budget, and strategic priorities:

| Feature | Self-hosted ClickHouse | ClickStack (Self-hosted) | ClickHouse Cloud with ClickStack |
| ----- | ----- | ----- | ----- |
| Typical cost model | Fixed infrastructure cost (CapEx/OpEx) | Fixed infrastructure cost (CapEx/OpEx) | Usage-based (compute, storage, egress) |
| Operational hours/week | High (5-15+ hours) | Medium (2-5 hours) | Very Low (<1 hour) |
| High availability (HA) | Manual setup (replication, keepers) | Manual setup (replication, keepers) | [Built-in (2+ availability zones)](https://clickhouse.com/docs/cloud/manage/cloud-tiers) |
| Security and compliance | User-managed | User-managed | [Managed (SAML, HIPAA/PCI options)](https://clickhouse.com/docs/jp/cloud/security) |
| Best for | Large teams with deep infra expertise and strict data residency needs. | Teams wanting a unified OSS experience without building from scratch. | Teams that want to focus on their product instead of infrastructure, especially those with variable workloads. |

## **Self-managed vs. ClickHouse Cloud: a break-even analysis**

The self-hosting versus managed service decision often reduces to simple math: when does paying engineers to manage the database exceed the managed service cost?

For small to medium workloads, managed services are often the clear winner. Just 5 hours of engineering time per month, at $150/hour, adds $750/month to your TCO. This "soft cost" often exceeds the entire ClickHouse Cloud fee, which handles all maintenance, upgrades, and on-call duties.

Bursty or unpredictable workloads make the case even clearer. Self-hosted clusters must handle peak load, leaving you paying for idle resources during quiet periods. This wastes [40-60% of your compute budget](https://www.flexential.com/resources/blog/cloud-cost-optimization). ClickHouse Cloud's architecture, which [separates compute from storage](https://clickhouse.com/docs/guides/separation-storage-compute) (using object storage), enables automatic scaling (including scale-to-zero) and converts that waste into savings. Users can also take advantage of compute-compute separation to isolate read and write workloads. This allows a lightweight, continuous compute layer for ingestion, while scaling read capacity dynamically based on demand - consuming only the resources required at any given time and keeping costs low. Combined with high compression and object storage, long-term data retention becomes exceptionally cost-efficient, approaching cloud storage provider pricing per terabyte.

Self-hosting becomes cost-effective only at very large scale with predictable workloads, and only if you already have mature SRE teams with deep distributed database expertise.

A practical guide to observability TCO and cost reduction

Top 5 cloud data warehouses in 2026: Architecture, cost, and open-source

Resource hub

Engineering

Beyond sampling: managing petabyte-scale logs without losing data

A practical guide to observability TCO and cost reduction

Top 5 cloud data warehouses in 2026: Architecture, cost, and open-source