The Real Cost of Self-Hosting Observability on ClickHouse

"ClickHouse is way cheaper." It usually is, as a database. Columnar storage, aggressive compression, no license fee, genuinely excellent economics for the price of a terabyte at rest. That's not in dispute here.

What's worth separating out is a claim that quietly rides along with it: that self-hosting observability on ClickHouse is equally cheap. Those are two different claims, and the gap between them is everything you still have to build before ClickHouse is an observability platform instead of a fast place to put rows.

This is a breakdown of exactly what's in that gap, what it costs in practice, and when building it yourself is genuinely the right call anyway.

ClickHouse's Storage Economics Are Real, Not the Problem

Worth saying plainly: ClickHouse deserves its reputation. Columnar storage with strong compression, a mature query engine, an Apache 2.0 license with no cost at any scale, and a large enough community that most operational problems have already been solved by someone, publicly. Teams that reach for it aren't making a mistake about the database. Compared to row-oriented stores or paying a per-GB SaaS tax on raw ingestion, ClickHouse's storage cost per terabyte is a legitimate, well-earned advantage.

None of what follows disputes that. It's about what sits between "a fast columnar database" and "a production observability platform," because that distance is where the actual cost of the self-hosted plan lives.

It's also why the demo always goes well. A single-node ClickHouse instance, a handful of test logs, one engineer querying it directly, that's where almost every evaluation starts, and at that scale nothing below is visible yet. There's no second team asking how they log in, so SSO isn't a gap yet. There's no resharding to do, because volume hasn't grown. There's no security review asking for per-dashboard access control, because it's still one person's proof of concept. Every cost in this piece is a production-scale, multi-team problem, which is exactly why it's invisible during the part of the process where the go/no-go decision actually gets made.

What "Observability" Actually Requires Beyond a Database

A database stores and queries rows. An observability platform does a specific list of additional things, all of which ClickHouse leaves for you to build:

• OTel-native ingestion for three signal types. Logs, metrics, and traces each need their own schema design, their own ingestion pipeline, and their own indexing strategy tuned for how that signal is actually queried. ClickHouse doesn't speak OTLP out of the box; you're writing and maintaining that translation layer.
• Cross-signal correlation. The entire value of unified observability is pivoting from a metric spike to the traces active in that window to the specific log lines that explain it, via a shared identifier like trace_id. That correlation logic, and the query patterns that make it fast, is application logic you design and maintain, not something a generic SQL database gives you.
• A query and dashboard layer. Someone still has to build (or operate) the UI: dashboards, saved queries, a way for non-SQL-fluent teammates to explore data. Raw ClickHouse SQL access is not that.
• Alerting. Scheduled queries, thresholds, notification routing, deduplication, none of it ships with the database.
• Application-level RBAC. ClickHouse's RBAC is real, but it's database grants: row and column access tied to database users. Per-dashboard, per-team access control for a hundred engineers across a dozen services is a different, unbuilt layer.
• SSO/SAML/OIDC. Not a ClickHouse feature at all. Getting from "database has users" to "engineers log in with your identity provider and land in exactly the data they're scoped to" is authored software.
• Multi-tenancy. If more than one team or environment shares the cluster, isolation, quotas, and access boundaries between them are your design decisions.
• Retention and lifecycle management. TTL policies, tiering, and cleanup that don't silently degrade query performance as data ages, tuned and re-tuned as volume grows.

None of this is a knock on ClickHouse. A general-purpose columnar database was never supposed to ship with all of this. It's the reason "ClickHouse is free" and "a production observability platform on ClickHouse is free" are different sentences.

The Part That Actually Breaks: Scaling and High Availability

This is where the DIY math gets worst, and where it matters most for a team whose ingestion volume is actively growing, not staying flat.

A single-node or lightly-sharded ClickHouse setup that runs fine at moderate volume typically needs real re-architecture well before it reaches several times that volume: repartitioning, adding shards, rebalancing existing data across the new topology, ideally without downtime on a system your on-call already depends on. This is a well-documented, genuinely difficult category of ClickHouse operations work, not an edge case.

High availability compounds the same problem rather than solving it separately: every ClickHouse replica stores a full copy of its shard's data, so adding replicas for HA multiplies your provisioned disk by the replica count, on top of whatever resharding growth already required. Coordinating that replication also means running ClickHouse Keeper (or the ZooKeeper-based setup it replaced) for quorum, itself another distributed system to size, monitor, and keep healthy.

And critically: self-hosted, open-source ClickHouse cannot fully decouple storage from compute the way object storage does. It can tier older data parts to S3, but the MergeTree engine underneath was designed around local disk, so S3-backed parts query slower and background merges generate a steady stream of object storage API calls against data that still, ultimately, belongs to a specific replica. True compute-storage separation, ClickHouse's SharedMergeTree, exists only in ClickHouse Cloud, the commercial managed offering, not in the self-hosted open-source version. If the plan is "self-host to avoid a vendor," the storage-efficiency argument that made ClickHouse attractive in the first place doesn't fully carry over to the self-hosted deployment model.

Pricing the Build: A Worked Scenario

Say a team is ingesting logs, metrics, and traces at meaningful daily volume today, growing several times over within a year, and needs the full list above: unified querying, dashboards, alerting, application-level RBAC, and SSO, because that's what a real production rollout across multiple teams requires.

Rough shape of the build, not exact numbers, since team composition and existing expertise vary a lot:

• Initial build: ingestion pipelines for three signal types, a correlation layer, a basic query/dashboard UI, and an alerting system. This is realistically a multi-engineer, multi-month project before anyone outside the platform team is using it day to day, not a sprint.
• RBAC and SSO layer: a distinct project on top of the above, building or integrating an auth layer that maps identity-provider groups to per-dashboard, per-tenant access.
• Scaling for growth: resharding and adding replicas as volume climbs, plus the Keeper/coordination overhead, which shows up as recurring operational work, not a one-time cost, since it recurs every time volume crosses another threshold.
• Ongoing ownership: someone is now effectively a part-time ClickHouse operator for as long as the platform exists, on-call for the database itself in addition to whatever they were already on-call for.

Translate that into fully-loaded engineering time (salary, benefits, overhead, typically $150-250K+/year per senior platform engineer depending on market) amortized over the first 12-18 months, and it's common for the "free" self-hosted option to cost more in people-hours than a platform that ships the same capability set already built, before infrastructure spend is even counted separately. That's not a knock on the team's competence, it's simply how much software this actually is.

When Self-Hosting on ClickHouse Is Still the Right Call

This is the part that's easy to skip in a piece like this, and shouldn't be: for some teams, building on ClickHouse directly is genuinely the correct decision, not a mistake they haven't discovered yet.

• You already have deep ClickHouse expertise on staff. If sharding, Keeper, and MergeTree tuning are things your team already lives in, a meaningful chunk of the build cost above is sunk cost you've already paid.
• Your query patterns are unusual enough that a generic observability platform's abstractions get in the way. Highly custom analytical workloads sometimes benefit from direct SQL access more than a purpose-built UI layer.
• You have a dedicated data platform team whose job is exactly this kind of build, and the observability layer is one of several systems they're already resourced to own long-term, not a side project bolted onto an SRE team's existing workload.
• Your scale and requirements are stable, not growing several-fold, which removes the resharding problem that drives most of the ongoing operational cost above.

If none of those describe your situation, the honest read is that you're not choosing "cheap" over "expensive." You're choosing "pay in engineering time, spread out and easy to underestimate" over "pay on an invoice, visible up front."

Where a Purpose-Built Platform Changes the Math

OpenObserve is built on the same class of storage economics teams like about ClickHouse, Parquet-format columnar data on object storage (S3, GCS, Azure Blob), not a proprietary engine that only decouples storage from compute in a paid cloud tier. The difference is that the observability layer described above isn't something you build afterward:

• OTel-native ingestion for logs, metrics, and traces out of the box, no custom translation layer to write and maintain.
• Unified SQL querying across all three signals with built-in correlation, not a bolt-on join you design yourself.
• Dashboards and alerting included, not a separate project.
• Native RBAC and SSO/SAML, application-level, not database grants you extend yourself. OpenObserve's self-hosted enterprise edition includes SSO, RBAC, and sensitive data redaction free up to 50 GB/day of ingestion; above that, it's a licensed tier, priced as software, not re-billed as your own team's time.
• No shard-and-replica math on your end. Durability comes from the object storage layer itself; scaling out is adding stateless compute nodes in front of a bucket, not resharding a stateful cluster.

This doesn't remove the option to self-host, OpenObserve is open source (AGPL-3.0) and runs entirely on your own infrastructure if that's the requirement. It removes the specific cost this piece has been walking through: the months of engineering time spent building ingestion, correlation, RBAC, and SSO before a team can use any of it in production.

The Question Worth Asking Internally

Not "what does ClickHouse cost to run," which is a real and genuinely low number. The question that actually determines total cost is: what does it cost to reach a production-grade observability platform, with RBAC, SSO, and high availability that survives real growth, and who on the team is building and then owning that indefinitely?

Answer that question honestly, with fully-loaded engineering time included, not just infrastructure spend, and the comparison usually looks very different than "ClickHouse is free."

For a direct feature-by-feature comparison, see ClickHouse vs OpenObserve for Logs, Metrics & Traces.

Talk to us about your ingestion volume and requirements →