Prometheus 3.0 is the biggest release in the monitoring project's history, and its headline feature is native OpenTelemetry support: Prometheus can now ingest OTLP metrics directly, without an intermediary collector. It also adds full UTF-8 support for metric and label names, native histograms, a modernized web UI enabled by default, and Remote-Write 2.0. If your observability stack is moving toward OpenTelemetry, Prometheus 3.0 is the version that finally makes Prometheus a first-class OTel backend.
For teams that have run Prometheus for years, this release changes the calculus. The long-standing friction of mapping OpenTelemetry's dotted metric names into Prometheus's underscore-only world is gone, and you can point OTLP exporters straight at Prometheus. According to the official Prometheus 3.0 announcement, interoperability with OpenTelemetry was a primary design goal of the release.
This guide covers what's new in Prometheus 3.0, the OpenTelemetry integration in detail, native histograms, and whether you should upgrade in 2026.
Key Takeaways
- Prometheus 3.0 can ingest OpenTelemetry metrics natively via an OTLP endpoint — no separate collector required.
- Full UTF-8 support means metric and label names no longer need dots converted to underscores.
- Native histograms replace classic histograms with automatic, exponentially growing buckets — more efficient and cheaper to store.
- A redesigned web UI is enabled by default, including a PromLens-style tree view for PromQL.
- Remote-Write 2.0 adds metadata, exemplars, created timestamps, and native histograms, with string interning to shrink payloads.
What is Prometheus 3.0?
Prometheus 3.0 is a major version of the open-source monitoring and alerting system, redesigned around cloud-native observability and deep OpenTelemetry interoperability. It keeps the core PromQL query language and pull-based model that made Prometheus the de facto standard, while modernizing how it ingests, stores, and displays metrics — most notably by accepting OpenTelemetry data directly.
The motivation is the industry's convergence on OpenTelemetry as the standard for instrumentation. Previously, feeding OTel metrics into Prometheus meant running a collector to translate names and formats. Prometheus 3.0 removes that translation layer, letting you send OTLP metrics straight to Prometheus and query them with PromQL. That simplification is the through-line of the whole release. For the storage layer beneath your metrics, the same upgrade-versus-stay reasoning applies as in our PostgreSQL 18 new features guide.
How does Prometheus 3.0 support OpenTelemetry?
Prometheus 3.0 supports OpenTelemetry by acting as a native OTLP receiver: it exposes an endpoint at /api/v1/otlp/v1/metrics that accepts OpenTelemetry metrics directly, so exporters can push OTLP data to Prometheus without an intermediary collector. Combined with UTF-8 name support, this makes storing and querying OTel metrics far less painful than before.
The two changes work together. Enabling the OTLP receiver lets Prometheus ingest OpenTelemetry data, and UTF-8 support means OTel's dotted names — like http.server.request.duration — are preserved instead of being mangled into underscores. According to Grafana Labs, this lets teams store and query OTel data in Prometheus with far less friction.
Enabling the OTLP receiver is a small config change:
# prometheus.yml
otlp:
# keep OpenTelemetry-style dotted names
translation_strategy: NoUTF8EscapingWithSuffixes
storage:
# required for native histograms + OTLP features
tsdb:
out_of_order_time_window: 30m
You also start Prometheus with the OTLP receiver feature enabled, then point your OpenTelemetry exporter at the /api/v1/otlp/v1/metrics endpoint. From there, PromQL queries work as usual — now over metrics that keep their original OpenTelemetry names.
What are native histograms in Prometheus 3.0?
Native histograms are a new, more efficient metric type in Prometheus 3.0 that automatically set exponentially growing bucket boundaries, replacing the manual, fixed buckets of classic histograms. They capture distribution data at higher resolution while using less storage, which lowers the cost of tracking latency and size distributions at scale.
With classic histograms, you had to predefine bucket boundaries — and getting them wrong meant either poor resolution or wasted storage. Native histograms remove that guesswork: buckets grow exponentially and adapt automatically, so you get accurate percentiles without hand-tuning. For high-cardinality latency metrics, that translates directly into lower storage and query cost.
The efficiency gains matter most for large deployments. If you're running monitoring across many services and containers — the kind of environment where you're also weighing Podman vs Docker for your runtime — native histograms meaningfully reduce the overhead of observability at scale.
What else is new in Prometheus 3.0?
Beyond OpenTelemetry and native histograms, Prometheus 3.0 ships a completely redesigned web UI and an upgraded Remote-Write 2.0 protocol. The new UI is enabled by default, cleaner and more modern, and includes a PromLens-style tree view that makes complex PromQL queries far easier to understand and debug.
The main additional changes:
- Redesigned UI. A modern interface with a query tree view (PromLens-style) that visualizes how PromQL expressions evaluate.
- Remote-Write 2.0. Adds native support for metadata, exemplars, created timestamps, and native histograms, and uses string interning to shrink payloads and cut CPU on compression.
- UTF-8 everywhere. All valid UTF-8 characters are allowed in metric names, label names, and label values by default.
- Cloud-native alignment. The whole release is oriented toward standards-based, interoperable observability.
Remote-Write 2.0 is particularly relevant if you ship metrics to a long-term store or a managed backend. The payload and CPU savings from string interning add up across a large fleet — the same efficiency mindset you apply when choosing between Cloudflare Workers and Vercel Edge Functions for compute.
Should you upgrade to Prometheus 3.0 in 2026?
Yes — most teams should upgrade to Prometheus 3.0, especially if you use or plan to use OpenTelemetry. The native OTLP ingestion, UTF-8 support, and native histograms are substantial improvements, and the upgrade path from Prometheus 2.x is designed to be smooth, with few breaking changes for typical setups. The main reason to wait is if you depend on a removed legacy flag or an old UI you can't yet migrate off.
Before upgrading, plan for these:
- Review deprecated flags. Some long-deprecated command-line flags were removed; check your startup configuration.
- Test the new UI. It's enabled by default; confirm your team's saved dashboards and workflows still fit.
- Validate OTLP ingestion in staging. If adopting OpenTelemetry, test name translation and native histograms before production.
- Check remote-write compatibility. Confirm your long-term storage backend supports the elements Remote-Write 2.0 sends.
For most standard deployments, the upgrade is low-risk and high-reward. If your observability roadmap includes OpenTelemetry — as most do in 2026 — Prometheus 3.0 is the version that makes that path straightforward. It also pairs naturally with durable, observable backends like the ones in our Temporal durable execution guide.
Frequently asked questions
What is the biggest new feature in Prometheus 3.0? The biggest new feature is native OpenTelemetry support. Prometheus 3.0 can ingest OTLP metrics directly through a dedicated endpoint, removing the need for a separate collector to translate OpenTelemetry data into Prometheus format.
Does Prometheus 3.0 support OpenTelemetry natively? Yes. Prometheus 3.0 acts as a native OTLP receiver via the /api/v1/otlp/v1/metrics endpoint, accepting OpenTelemetry metrics directly. Combined with UTF-8 name support, it stores and queries OTel data with minimal friction.
What are native histograms in Prometheus? Native histograms are a new metric type that automatically sets exponentially growing bucket boundaries, replacing manually configured classic histogram buckets. They provide higher-resolution distribution data while using less storage.
Is it safe to upgrade from Prometheus 2.x to 3.0? For most deployments, yes. The upgrade path is designed to be smooth with few breaking changes, though some deprecated flags were removed. Review your configuration and test OTLP ingestion in staging before upgrading production.
What is the new UI in Prometheus 3.0? Prometheus 3.0 ships a redesigned web UI enabled by default. It's cleaner and more modern and includes a PromLens-style tree view that visualizes how PromQL queries evaluate, making complex queries easier to debug.
What is Remote-Write 2.0? Remote-Write 2.0 is the upgraded protocol for shipping metrics to remote storage. It adds native support for metadata, exemplars, created timestamps, and native histograms, and uses string interning to reduce payload size and CPU usage.
The verdict
Prometheus 3.0 is a genuine milestone: it turns Prometheus into a native OpenTelemetry backend, removes years of naming friction with UTF-8 support, and modernizes both storage (native histograms) and the interface. For any team standardizing on OpenTelemetry, it eliminates a whole layer of translation plumbing and makes the observability stack simpler and cheaper to run.
Our recommendation: upgrade if you're on Prometheus 2.x and either use OpenTelemetry or plan to. Test the OTLP receiver and new UI in staging, confirm your remote-write backend supports the 2.0 elements, then roll forward — the native histogram efficiency alone often pays for the migration effort. As you modernize the rest of your platform, our guides on PostgreSQL 18 and OpenTofu vs Terraform will help you keep the whole stack current.