Skip to main content

OpenTelemetry Graduates CNCF in May 2026: Why Self-Hosted Collectors Beat Egress-Metered Observability SaaS

9 min readDora NodaDora Noda
Share
On this page

On May 21, 2026, at the CNCF Observability Summit in Minneapolis, OpenTelemetry became a CNCF Graduated project — the second-highest-velocity project in the entire cloud native ecosystem, behind only Kubernetes itself. That's a governance milestone, and by itself it wouldn't be worth a blog post. What's worth writing about is what graduation quietly finished settling: for a fleet doing 1.5TB of telemetry a month, the difference between an egress-metered SaaS bill and a self-hosted OTel-native stack on owned compute isn't 20% or 2x. In the worked numbers below, it's a 38x-to-166x gap, and it gets wider, not narrower, as the fleet grows.

That gap isn't new. What's new is that it no longer costs you anything to capture it. OpenTelemetry's graduation cements OTLP — its wire protocol — as the interchange format every serious observability backend now speaks natively, which means the self-hosted side of that comparison stopped being a worse product with a better price and became, for a growing list of teams, just the better product.

What Graduation Actually Locked In

CNCF graduation isn't a marketing badge; it's a checklist. OpenTelemetry cleared a third-party independent security audit of its core components (the Collector chief among them) and a formal governance review confirming the project's maturity — the same bar Kubernetes, Prometheus, and Envoy cleared before it. The adoption numbers behind that review are not small: over 12,000 contributors from more than 2,800 companies, and in the trailing twelve months the OpenTelemetry JavaScript and Python API packages were downloaded 1.36 billion and 1.3 billion times respectively, both setting new monthly records in April 2026. Organizations from Bloomberg to Alibaba to Heroku instrument with it.

The part that matters for a self-hosted platform isn't the download count — it's what those downloads are all emitting into. OTLP (the OpenTelemetry Protocol) is the wire format, and it's backend-agnostic by design. An application instrumented with the OpenTelemetry SDK doesn't know or care whether the Collector at the other end forwards spans to Datadog, New Relic, or a self-hosted ClickHouse cluster — the export config is a URL and a header, not a vendor SDK baked into the codebase. Graduation is CNCF's way of saying that protocol isn't going to fracture or get orphaned; it's the standard now, with a public governance process behind it. That's what turned "self-hosted observability backend" from a niche choice with integration risk into a drop-in swap with none — which is exactly what made the current wave of OTel-native self-hosted backends (SigNoz, the Rust-based OpenObserve) a real alternative instead of a science project.

The Cost Math, at Two Scales

Here's the comparison that graduation makes uncontroversial to run. Take a self-hosted PaaS control plane and tenant fleet emitting a realistic mix of logs, metrics, and traces, and price the same monthly volume three ways: Datadog, New Relic, and a self-hosted OpenObserve stack on owned Hetzner compute.

Scenario A — a 30-node fleet, 1.5TB/month of combined telemetry (a reasonable mid-size PaaS control plane plus tenant workloads):

BackendHow it's billedMonthly cost
Datadog$0.10/GB log ingestion + $1.70/million indexed log events (using Datadog's own ~1KB-per-event sizing guidance, ≈1M events/GB) + $23/host/mo (Enterprise, 30 hosts)≈$3,390
New Relic$0.40/GB flat across all telemetry types, minus the 100GB/mo free tier≈$560
Self-hosted OpenObserve (3× Hetzner CPX22, post-June-2026 pricing)Compute only, plus object storage for compressed Parquet data≈$80

Datadog splits its bill into three independently metered dimensions — raw ingestion, indexed events (what you can actually search), and per-host monitoring — and the indexing line dominates: at this volume it's $2,550 of the $3,390 total, more than seven times the ingestion charge it's layered on top of. New Relic's flat $0.40/GB is simpler and meaningfully cheaper, but it's still metering the same thing self-hosted infrastructure doesn't meter at all: how many bytes you sent it. The self-hosted number is dominated by three CPX22 instances running the Collector gateway and OpenObserve's query/storage tier — OpenObserve ships as a single Rust binary with its own Parquet-based storage engine, not a multi-service ClickHouse stack, which is why three small instances cover it. Storage itself barely registers: OpenObserve's own published benchmark — streaming 1.1TB of identical Kubernetes-format log data to Elasticsearch and OpenObserve simultaneously on identical AWS hardware — measured a 140x lower storage cost, driven by 10x-40x compression ratios from columnar Parquet encoding. At 1.5TB raw ingested, what's actually sitting on disk is closer to 40-150GB.

Scenario B — a 200-node fleet, 15TB/month (the same platform after real growth, not a hypothetical):

BackendMonthly cost
Datadog≈$31,600
New Relic≈$5,960
Self-hosted OpenObserve (3× Hetzner CCX13, dedicated vCPU)≈$190

The self-hosted side barely moved — three CPX22s became three CCX13s, a compute upgrade, not a rearchitecture, because the bottleneck at this scale is CPU for compaction and query, not a per-GB meter. The metered side moved in a straight line, because that's what a per-GB or per-event bill does: it has no ceiling and no economy of scale in the customer's favor. The gap between Datadog and self-hosted widens from 38x at 1.5TB/month to 166x at 15TB/month. That's the actual argument for owning the stack: it isn't that self-hosted is cheaper at any one snapshot, it's that the SaaS bill and the self-hosted bill scale on fundamentally different curves, and every month of growth moves the comparison further in the self-hosted platform's favor, not closer to parity.

(Both scenarios use published list pricing and standard sizing assumptions — Datadog's own ~1KB-per-log-event guidance for the indexing estimate, and typical retention/compaction settings for OpenObserve. Actual bills vary with cardinality, retention window, and negotiated enterprise discounts, but the order of magnitude holds across every published comparison we found.)

The Architecture: What the Platform Owns vs. What Tenants See

The deployment pattern behind both scenarios' self-hosted column is the same one CNCF's own guidance recommends: agents on every node, forwarding to a centralized, horizontally scaled gateway.

  • DaemonSet agents — one Collector pod per node, scraping host metrics, container logs, and local trace spans. This tier stays as close to the workload as possible and does minimal processing; its only job is to get telemetry off the node reliably.
  • Deployment gateway — a pool of stateless Collector replicas behind a load balancer, receiving from every agent. This is where batching, PII scrubbing, sampling decisions, and routing rules live, centralized instead of duplicated across every node.
  • Backend — OpenObserve or SigNoz, receiving OTLP from the gateway tier and handling storage, indexing, and query.

For a self-hosted PaaS, that two-tier collector pattern serves two audiences that need to stay separated. The platform's own control-plane telemetry — API server latency, reconciler loop timing, node health, the Cluster API machinery provisioning tenant infrastructure — flows through one gateway path into a backend only platform operators can query. Tenant application telemetry flows through a second, tenant-scoped path: each tenant gets its own OTLP ingest endpoint and a dashboard scoped to their own data, with no visibility into the platform's internal metrics and no visibility into other tenants' data. Both paths run the identical Collector and identical backend software — the isolation is a routing and access-control decision at the gateway, not two different observability stacks bolted together. That's the practical payoff of OTLP being the interchange format everywhere: control-plane and tenant observability are the same infrastructure, multiplexed, instead of two integrations to build and maintain separately.

Why This Stopped Being a Preference and Became a Compliance Answer

The cost argument would be reason enough, but there's a second pressure pushing in the same direction: telemetry isn't exempt from data residency law just because it's "operational" data. Logs routinely carry IP addresses, user IDs, and session identifiers embedded in request paths and error messages — the same categories of personal data GDPR governs everywhere else — and a centralized SaaS pipeline that ships every log line to a US-based vendor's ingestion endpoint is a cross-border transfer like any other, whether or not anyone on the team thought of it that way. Cloud-to-cloud egress for moving that data across regions runs $0.02-$0.09/GB on its own, before a vendor's ingestion price is even applied — a cost that's structurally invisible in most "just point the SDK at a hosted endpoint" evaluations, because it shows up on a cloud bill, not an observability vendor's invoice.

Regulators are already leaning on the egress side of this specifically: the EU Data Act, fully applicable since September 2025, mandates that cloud providers support switching between services and requires egress fees to be eliminated entirely by January 2027 — a direct response to egress pricing being used as a lock-in mechanism, in observability pipelines as much as anywhere else. A self-hosted Collector-to-backend pipeline sidesteps the entire question: telemetry never leaves the cluster (or the region) it was generated in, because there's no vendor endpoint to ship it to in the first place. That's why "self-hosted by default" for telemetry is turning into the mainstream 2026 answer for compliance-conscious teams specifically, not just the self-hosting crowd's long-standing preference — the regulatory and cost pressure now point the same direction the ideology always did.

The Standard Did Its Job Quietly

None of this required a new product category. It required OpenTelemetry to become boring enough — standard enough, well-governed enough, security-audited enough — that a team could point at OTLP as a graduated CNCF interchange format instead of a startup's proprietary SDK, and self-hosted backends had a stable, universal protocol to build against instead of chasing every vendor's export format. Graduation is the moment that stopped being a bet.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. It runs its own control-plane observability on the same OTel-native, self-hosted pattern described above, with tenant telemetry isolated behind per-tenant OTLP endpoints rather than a shared, metered pipe. Star the repo on GitHub or deploy your first app today.


Sources

Related articles

Run this on infrastructure you own

bex is the open-source, AI-native Render alternative — push a git repo and get a running HTTPS service on your own machines.

Get started with bex