Datadog vs Prometheus: How You Pay for Metrics at Scale

Prometheus is a metrics and alerting system. Datadog is a full observability platform. Comparing them directly is a bit lopsided, so this page compares Datadog with a Prometheus-centered stack, and it keeps the focus on metrics. Within that frame you actually have three choices: run Prometheus yourself, use a managed Prometheus service, or adopt Datadog.

All three cost money. The difference is what growth turns into. On self-hosted Prometheus, more metrics mean more infrastructure and more engineering work. On managed Prometheus, they mean more metered samples or series. On Datadog, they show up across several billing dimensions, and Prometheus labels become custom metrics. By the end of this page, you should be able to look at your metric volume, cardinality, team capacity, and need for logs and traces, and pick the model that fits.

If you're also weighing Grafana, see Grafana vs Datadog and Prometheus vs Grafana. This page treats Grafana only as the usual dashboard layer for Prometheus.

Datadog vs Prometheus at a glance

The table compares the three operating models on billing, operations, and core metrics features. Prometheus itself is an Apache 2.0 project that graduated from the CNCF in 2018.

Three operating models, not two products

Managed Prometheus deserves its own row in the decision. The provider runs more of the infrastructure, you keep PromQL, and usage is still metered. Whether that comes out cheaper or more expensive than the alternatives depends on your workload, the service, and its pricing model. It isn't simply a midpoint between "free" and "expensive."

Here's how each model turns growth into cost:

• Self-hosted Prometheus. You pay no license fee, but every new series uses memory, CPU, and disk on servers you run. Past a single server, growth also means high-availability pairs, a long-term store, and the engineering time to keep them healthy.
• Managed Prometheus. Services such as Amazon Managed Service for Prometheus (AMP), Google Cloud Managed Service for Prometheus (GMP), Azure Monitor managed service for Prometheus, and Grafana Cloud take over storage and availability, and some also offer a managed collector. Growth shows up as more samples ingested or more active series billed. Your queries, dashboards, and alert rules stay in PromQL.
• Datadog. Datadog is a managed platform for infrastructure and application observability. Growth shows up in several places at once: hosts, containers, custom metrics, log volume, and APM hosts. Prometheus-style labels turn into custom-metric series.

This page names those managed services as examples. It doesn't rank them against each other.

What each option charges for

Self-hosted Prometheus costs infrastructure plus staff time. Managed Prometheus charges per sample ingested or per active series. Datadog charges per host, per container, and per custom metric, and bills logs and APM separately. The prices below are US list prices as of October 2026. Check each vendor's pricing page before you budget.

Sources: AMP pricing, GMP pricing, Azure Monitor pricing, Grafana Cloud pricing, Datadog pricing.

A few details change how these units behave:

• Self-hosted staff time is hard to price. Running Prometheus in production means running Prometheus, Alertmanager, Grafana, exporters, and often a long-term store, each with its own upgrades. No primary source puts a number on that effort, but it belongs in the comparison.
• Datadog's host price includes custom metrics and containers. Infrastructure Pro includes 100 custom metrics and 5 containers per host. Enterprise includes 200 and 10. Custom-metric allotments are pooled across the account. Overage is billed per 100 custom metrics, and the indexed rate is set by contract.
• Containers add up in autoscaling Kubernetes clusters. Containers above the per-host allotment are billed hourly, so a cluster that scales pods up during peaks pays for them.
• Logs and APM are separate meters. Datadog Logs starts at $0.10 per GB ingested, and Standard indexing with 15-day retention costs $1.70 per million events on an annual plan. APM costs $31, $35, or $40 per host per month on annual plans, depending on tier.

Unpredictable bills are a recurring complaint about Datadog in practitioner threads on Hacker News and StackShare. The usual culprits are custom-metric cardinality, log indexing, and host and container fees in autoscaling clusters.

What ties these units together is cardinality. It drives memory on your own servers, sample and series counts on managed services, and custom-metric counts on Datadog.

How cardinality affects all three

Take one counter with 30 series. On self-hosted Prometheus, those 30 series cost RAM, CPU, and disk. On managed Prometheus at a 30-second scrape interval, they produce 86,400 samples a day. On Datadog under cardinality-based billing, they correspond to 30 custom-metric series. Add one high-cardinality label and all three multiply. Datadog's Metric Name pricing works differently: there, the same counter is billed by metric name and datapoint volume.

The example below works with calculated series counts. Billed usage and the final invoice are separate things. Billed usage depends on how each vendor measures series or samples over time, and the invoice depends on allowances, contract terms, and everything else you send.

What a custom metric is in Datadog

Datadog defines a custom metric as "a unique combination of a metric's name and tag values (including the host tag)". In practice, that means one series. Usage is the monthly average of the distinct series seen each hour.

When the Datadog Agent scrapes a Prometheus endpoint, Prometheus labels become Datadog tags. Each distinct combination of metric name and tags can become its own custom metric, and the OpenMetrics integration docs say that "all the metrics retrieved by this integration are considered custom metrics." Histograms multiply further, because each bucket becomes a separate series, and each Datadog distribution counts as 5 series per tag combination.

That definition applies under Datadog's default, cardinality-based custom-metric billing. Datadog also offers Metric Name pricing, covered below.

The example: http_requests_total

The example uses a plain counter, http_requests_total, with three labels:

• route: 5 values
• status: 3 values
• instance: 2 values

That's 5 × 3 × 2 = 30 Prometheus series. A counter keeps the math clean. A histogram would add a series per bucket, and Datadog's mapping of histogram buckets would change the count again.

On the Datadog side, the example assumes this configuration:

• The counter is collected through the Datadog Agent's generic OpenMetrics integration, so it's a custom metric. By default, the integration maps a counter to a Datadog count metric with a .count suffix.
• Each instance maps one-to-one to a Datadog host value. Host tags count toward series identity, but a one-to-one mapping adds no new combinations, so the count stays at 30.
• No other host or enrichment tags are added.

Whether host tags add series in a real deployment depends on how the Agent and your tagging are configured.

A hypothetical illustration under the stated configuration, not a measured Datadog outcome or a prediction of any bill. Actual series counts depend on metric type, collected tags, host identity, filtering, and check configuration. Charges also depend on the billing model, allowances, and contract.

When labels multiply

Now add a customer_id label with 100 values. That could take the counter from 30 series to 3,000, if every customer ID occurs in every existing label combination. In practice, not every combination appears, so treat 3,000 as an illustrative upper bound.

• Self-hosted Prometheus: up to 3,000 active series. Prometheus's instrumentation guidance warns that "each labelset is an additional time series that has RAM, CPU, disk, and network costs" and suggests keeping a metric's cardinality, its total series count, below 10. For a metric over 100 series, the guide tells you to look for alternatives, and 3,000 is far past that.
• Managed Prometheus: at most 3,000 series × 2,880 scrapes = 8,640,000 samples a day on per-sample services, or up to 3,000 active series on Grafana Cloud, billed as up to 6,000 at a 30-second interval. Metered usage scales with it.
• Datadog: under the configuration above, those combinations can correspond to up to 3,000 custom-metric series. On Infrastructure Pro, the two hosts in this example contribute 200 custom metrics to the account's pooled allotment. Whether the extra series become overage depends on the rest of the account's usage and allowances.

In all three models, the new label can multiply the series count by up to 100. The models differ in how that shows up: as memory pressure on your servers, as metered samples, or as custom-metric usage.

Series count also moves over time. Labels that change when workloads restart or scale, such as pod names or container IDs, keep creating new series even when the number active at any moment stays flat. Datadog counts the distinct series seen each hour and averages them over the month, so short-lived series still add to usage. On Prometheus, each new series carries the RAM, CPU, and disk cost the instrumentation guide warns about.

Metric Name pricing changes the math

Datadog also offers a contract-dependent Metric Name pricing model, generally available since June 2026. It bills per metric name instead of per tag combination. Under it, http_requests_total is one metric name, assuming the integration maps it to a single name.

Metric Name pricing has three billing dimensions:

• Metric names. A name becomes billable once it has more than 100 indexed datapoints.
• Indexed datapoints. Each billed metric name includes 10 million indexed datapoints. Volume above that is billed.
• Ingested datapoints. Ingested volume above five times the indexed volume is billed separately.

Datadog doesn't publish rates for these dimensions. Because the bill follows datapoint volume rather than tag combinations, a 100-fold increase in series doesn't translate directly into a 100-fold increase in charges.

Label growth still shows up as datapoints, though. At the Agent's default 15-second check interval, the 30-series counter produces about 5.2 million datapoints in a 30-day month, inside the 10 million included for one metric name if every point is indexed. At 3,000 series, the same counter produces about 518 million, more than 50 times that allowance.

Metric Name pricing is an opt-in contract and can't be combined with the per-series model. If your organization isn't on it, cardinality-based billing applies.

Collection and architecture

The pull vs push split is blurrier than most comparisons suggest. The Datadog Agent scrapes Prometheus endpoints, and Prometheus 3 accepts pushed OTLP. The bigger architectural difference is what you have to run to get high availability and long-term storage.

How Prometheus collects and stores metrics

Prometheus pulls metrics over HTTP from targets it finds through service discovery (including Kubernetes) or static configuration. Exporters expose metrics for third-party systems, and the Pushgateway covers short-lived jobs. In Kubernetes, many teams manage scrape targets with the Prometheus Operator's ServiceMonitor and PodMonitor resources.

Scraped samples go into a local time series database on a single node. A single server can handle "tens of millions of active series," according to the Prometheus FAQ. The storage docs are just as direct about the limits: local storage "is not clustered or replicated" and isn't durable against drive or node failures. Retention defaults to 15 days.

High availability means running identical Prometheus pairs plus an Alertmanager cluster, then deduplicating the pairs downstream. Durable long-term storage and global querying need another system:

• Thanos: CNCF incubating, Apache 2.0
• Cortex: CNCF incubating, Apache 2.0
• Grafana Mimir: AGPL-3.0
• VictoriaMetrics: Apache 2.0 open source edition

This is where self-hosted growth turns into cost. Local storage sits on one unreplicated node, so durable retention beyond a few weeks, or a single query view across clusters, means operating one of these systems, its object storage, and the upgrades that come with it.

How Datadog collects metrics

Datadog collects metrics through the Datadog Agent, which runs on each host (as a DaemonSet in Kubernetes) and sends data to Datadog's SaaS backend. Applications can send metrics to the Agent over DogStatsD. For Prometheus-format endpoints, the Agent's OpenMetrics check scrapes a configured openmetrics_endpoint.

In Kubernetes, autodiscovery can find pods annotated with prometheus.io/scrape: "true" and scrape them automatically. This needs Agent 7.27 or later and is enabled with prometheusScrape in Helm or DD_PROMETHEUS_SCRAPE_ENABLED.

Datadog's collection scrapes Prometheus endpoints too. The difference is the storage tier, which Datadog runs for you along with ingestion, retention, and availability. Your part is the Agent.

Metrics capabilities side by side

PromQL and Datadog's query syntax both work well for metrics, but they don't translate one-to-one. Default retention differs by an order of magnitude (15 days of local Prometheus storage vs 15 months on Datadog), and Prometheus needs Grafana or another tool for dashboards.

Querying: PromQL vs Datadog queries

PromQL is a functional query language built around label matching, range vectors, and functions such as rate() and histogram_quantile(). It's the common language of the Prometheus ecosystem, so managed Prometheus services, Grafana, and many open-source tools speak it.

Datadog uses its own query syntax: a metric name with tag filters, followed by time and space aggregation, rollups, and functions. It also offers DDSQL. The concepts overlap, but queries, dashboards, and monitors have to be rewritten when moving between the two.

Retention and resolution

Prometheus keeps 15 days of data locally by default. Local storage is single-node and unreplicated, so longer retention usually means a long-term store. Managed Prometheus services include longer retention: 24 months on GMP, 18 on Azure, and 13 on Grafana Cloud Pro. AMP keeps 150 days by default and can be configured for up to 3 years. Datadog retains metrics for 15 months.

Resolution in Prometheus is whatever scrape interval you configure. Datadog Agent checks collect every 15 seconds. That figure describes Agent check collection, so don't assume it holds for every way you send data to Datadog.

Histograms differ too. Prometheus native histograms have been stable since v3.8. From v3.9, scraping them needs scrape_native_histograms: true, which defaults to false as of Prometheus 3.15. When Datadog scrapes classic Prometheus histograms, it maps _bucket, _sum, and _count to .bucket, .sum, and .count metrics, and summary quantiles to .quantile gauges. Each bucket adds to the custom-metric count.

Alerting: Alertmanager vs monitors

In Prometheus, alerting rules are PromQL expressions evaluated by the Prometheus server. When they fire, Alertmanager handles grouping, deduplication, silencing, and routing to notification channels. For high availability, you run Alertmanager as a cluster.

Datadog uses monitors, defined in its own query syntax and managed in the Datadog UI or API. Datadog also offers Watchdog anomaly detection, which needs no setup. Moving between the two means translating every alert rule.

Dashboards

Prometheus has an expression browser and a built-in UI, refreshed in 3.0, for running queries and checking targets. For dashboards, teams use Grafana or another tool, which is one more component to run unless you use a managed service. Datadog includes dashboards as part of the platform.

OpenTelemetry on both sides

Both Prometheus and Datadog accept OpenTelemetry (OTel) metrics, and both translate them into their own data model. Prometheus defaults to cumulative temporality and treats delta as experimental, while Datadog's direct OTLP metrics endpoint requires delta. Sending metrics through OTel doesn't automatically exempt them from Datadog's custom-metric billing.

OTLP into Prometheus

Prometheus 3 has a native OTLP/HTTP receiver at /api/v1/otlp/v1/metrics. It's off by default and enabled with --web.enable-otlp-receiver. It accepts metrics only.

Translation happens on the way in:

• OTel resource attributes go to a separate target_info metric. promote_resource_attributes turns selected attributes into labels, and it promotes none by default.
• Metric names are translated according to translation_strategy, which defaults to UnderscoreEscapingWithSuffixes.
• Pushed metrics get no up metric and no staleness markers, and they bypass metric_relabel_configs.
• Delta temporality is experimental. The otlp-deltatocumulative flag converts delta to cumulative and can hurt performance. otlp-native-delta-ingestion is at a very early stage. The two can't be used together.

For setup details, see Dash0's guide to OpenTelemetry and Prometheus.

OTLP into Datadog

Datadog offers three OTel paths:

1. The Datadog Agent with DDOT, an embedded OpenTelemetry Collector that bundles OTLP, Prometheus, hostmetrics, kubeletstats, and filelog receivers.
2. The upstream OpenTelemetry Collector with the Datadog exporter.
3. Direct OTLP intake with no Agent, generally available since July 2026. It accepts only delta metrics, and requests are capped at 512 KiB compressed.

OTel data is mapped to Datadog metrics and tags, just as Prometheus maps it to series and labels. Some Datadog features still need the Datadog SDK or Agent. These include App and API Protection, the Continuous Profiler, Data Streams Monitoring, and RUM, plus Agent-dependent features such as Cloud Network Monitoring and Live Processes.

Temporality and billing caveats

Prometheus uses cumulative temporality by default, while Datadog recommends delta temporality for the relevant OpenTelemetry metric types. The Datadog paths handle this differently:

• The Datadog Agent and Collector-based pipelines can take cumulative metrics and convert them through stateful conversion.
• The direct OTLP metrics endpoint requires delta metrics and returns an error for cumulative ones.

So one OTel SDK configuration exporting straight to Prometheus and to Datadog's direct endpoint won't work for both. If you send the same metrics to both, export cumulative metrics and send the Datadog copy through the Agent or a Collector.

Billing needs the same care. Sending application metrics through OpenTelemetry doesn't automatically exempt them from Datadog's custom-metric billing. Whether a metric counts as custom depends on its classification, and the billing model that applies depends on your organization's contract.

OpenTelemetry makes instrumentation portable. Queries, dashboards, alert rules, and stored history still live in each backend's own model, and each side translates metric names and histograms its own way. Switching backends still means the rewrite described in the lock-in discussion below.

Dash0 Special Edition: OpenTelemetry For Dummies

This book shows you how to bring order and clarity to observability with OpenTelemetry.

Get the ebook free

Beyond metrics: what it takes to match Datadog's scope

To match Datadog's breadth with open source, you'd add and operate separate tools for logs, traces, dashboards, and on-call. A fair comparison either counts that whole stack or limits itself to metrics. This page does the latter.

Datadog claims more than 1,000 integrations, and its products range from APM and logs to RUM, synthetics, security, and incident response, each with its own meter. On the open-source side, Prometheus covers metrics and alerting only. Matching that breadth means adding a log store such as Loki, a tracing backend such as Tempo or Jaeger, Grafana for dashboards, and an on-call tool, then running and upgrading each of them.

If you need integrated logs, traces, and APM, that stack is part of the real cost of the Prometheus route, and the metrics comparison on this page understates it. For a comparison of Datadog with the full Grafana stack, see Grafana vs Datadog.

Running Datadog and Prometheus together

The Datadog Agent can scrape your existing Prometheus endpoints through the OpenMetrics check and autodiscovery, but every metric collected this way is a custom metric, and Datadog warns about the cost. Running both also means ingesting the same data twice and operating two systems.

To set it up, point the OpenMetrics check at an endpoint, or turn on Prometheus autodiscovery so the Agent scrapes annotated pods. By default, each OpenMetrics check instance returns up to 2,000 metrics. The limit applies per check instance, not across all your scrape targets, so two targets with 1,500 series each don't necessarily hit it. The Agent status output shows how many metrics each instance returns, and Datadog's integration docs say to contact support if you need more.

The cost needs more attention. Datadog's own Kubernetes Prometheus docs warn that enabling autodiscovery "without advanced configuration can cause a significant increase in custom metrics." Under cardinality-based billing, each distinct tag combination on a scraped metric can count as a custom metric, as in the example above. If Prometheus keeps scraping the same targets, you pay twice: once in the infrastructure that stores the data in Prometheus, and again in Datadog custom metrics. You also maintain two sets of dashboards and alerts that can drift apart.

Running both usually makes sense as a migration step or for a small, filtered set of metrics. As a permanent arrangement, it combines the operating work of one model with the metered cost of the other.

Lock-in runs both ways. Moving from Prometheus to Datadog means rewriting PromQL queries, Grafana dashboards, and alert rules in Datadog's syntax. Moving from Datadog to Prometheus or an OpenTelemetry-based backend means the reverse, plus replacing any Datadog SDK instrumentation. For the Datadog-to-OpenTelemetry direction, including a query translation table, see Migrating from Datadog to OpenTelemetry and Dash0.

Which should you choose?

Self-hosted Prometheus fits teams with metrics-led needs and the capacity to operate the stack. Managed Prometheus fits teams that want PromQL without running storage and high availability. Datadog fits teams that want one managed platform across logs, traces, and APM, and that accept billing across several dimensions. Cardinality matters, but it's only one of the criteria.

Choose self-hosted Prometheus when:

• you mainly need metrics and alerting
• you have engineers who can run Prometheus, Alertmanager, Grafana, and a long-term store
• your retention needs are short, or you're prepared to operate Thanos, Mimir, or similar
• you want full control over data location and configuration

Choose managed Prometheus when:

• you want PromQL and the Prometheus ecosystem without running storage or high availability
• you need months of retention without building a long-term store
• your series count and scrape frequency are predictable enough to estimate metered usage
• you already run on the provider's cloud

Choose Datadog when:

• you want logs, traces, APM, and infrastructure in one managed platform
• you'd rather pay a vendor than staff an observability team
• you can control cardinality, or you're on a contract model that suits your label patterns
• you need features beyond metrics, such as RUM, synthetics, or security monitoring

Whether Datadog is worth the cost depends on whether you'd use its breadth. For metrics alone, you pay for a platform you only partly use. For Kubernetes, all three models work. Prometheus and its ecosystem are native to Kubernetes, while Datadog's per-host and per-container pricing needs watching in autoscaling clusters.

Worked decision: 50 nodes, metrics only, two-person platform team, 12-month retention

Node count alone doesn't decide this. Here's how the profile plays against each model.

Self-hosted Prometheus. Twelve months of retention is well past the 15-day local default. Local storage isn't replicated, so a year of data on one node isn't durable, and in practice you'd run a long-term store such as Thanos or Mimir, plus Prometheus pairs and an Alertmanager cluster for high availability. That's a lot of infrastructure for two people who also have other platform work. It's workable if cardinality is modest and one of them already knows the stack. It's risky if they don't.

Managed Prometheus. GMP (24 months), Azure (18 months), and Grafana Cloud Pro (13 months) all include 12 months of retention. AMP keeps 150 days by default, so you'd raise its retention setting and pay for the extra storage. The team keeps PromQL and runs the collectors, or pays for a managed collector where the service offers one. Cost follows sample volume or active series, so estimate it from your actual series count and scrape interval. At a 30-second interval, every series produces 2,880 samples a day.

Node count says little about that volume. Here are two hypothetical workloads on the same 50 nodes, both scraped every 30 seconds:

The cluster is the same, but metered usage differs tenfold. On Grafana Cloud, the 30-second interval also doubles billable usage, to 100,000 and 1,000,000.

Datadog. Retention covers 12 months. On Infrastructure Pro, 50 hosts bring a pooled allotment of 5,000 custom metrics and 250 containers. Since every Prometheus metric scraped through the OpenMetrics integration is a custom metric, compare your expected series count with that pool. Even the smaller workload above would be 10 times the pool if all 50,000 series came in that way. Datadog's breadth is the main reason to choose it, and this profile doesn't need it.

For this profile, managed Prometheus is the strongest starting point. It meets the retention requirement without asking a two-person team to run a long-term store, and it keeps the team on PromQL, so there's nothing to rewrite. Treat that as provisional until you've measured your series count, scrape interval, and query load, since those set the bill, and validate the estimate with a limited pilot before committing.

The answer changes if:

• Cardinality is high or unpredictable. Metered usage climbs on managed Prometheus, and custom-metric usage climbs on Datadog under cardinality-based billing. Fix the labels first.
• You scrape more often. A 15-second interval doubles the samples on per-sample services and doubles billable usage on Grafana Cloud. It doesn't change Datadog's custom-metric count, though it does raise datapoint volume under Metric Name pricing.
• Retention drops to a few weeks. Self-hosted Prometheus without a long-term store becomes much more realistic.
• The team grows or already runs Thanos or Mimir. Self-hosting becomes a realistic option, because the operating skills are already in place.
• You need logs and traces soon. Datadog's integrated platform becomes a stronger candidate, or you'd need to budget for the open-source stack alongside.

Where Dash0 fits

If you want managed observability but would rather keep Prometheus-style metrics and PromQL, Dash0 is an OpenTelemetry-native option. It collects Prometheus metrics with an OpenTelemetry Collector and forwards them over OTLP. In Kubernetes, the Dash0 Operator scrapes annotated Prometheus endpoints and, when enabled, supports ServiceMonitor, PodMonitor, and certain ScrapeConfig resources. Dash0 exposes the data through a Prometheus-compatible query API, so you can query it with PromQL. Logs and traces live in the same backend. Published list prices for metrics are $0.02 per million datapoints ingested and $0.18 per million datapoints stored, with 13-month retention. The same cost logic applies here as on per-sample managed Prometheus: series count and scrape interval drive the bill. There's a 14-day trial but no permanent free tier. See Dash0 pricing.

Final thoughts

Every option here can scale. What differs is what scaling asks of you. Self-hosted Prometheus asks for infrastructure and engineering time. Managed Prometheus asks for metered usage. Datadog asks you to manage several billing dimensions in exchange for a broader platform. Pick the one whose cost you can predict and control for your workload. Before you commit to any of them, measure your series count, how fast new series appear, your scrape interval, and your retention needs, then check the estimate against a short pilot.

For related comparisons, see Grafana vs Datadog, Prometheus vs Grafana, and the best Prometheus alternatives.

If you'd like to see how an OpenTelemetry-native platform handles Prometheus metrics alongside logs and traces, try Dash0 free for 14 days. No credit card required.