If you're choosing an observability platform, or you're on Datadog and wondering whether Grafana would cost less (or the other way around), a headline price won't give you a reliable answer. The two platforms meter different things. Datadog combines host-based products with separate usage meters. Grafana Cloud is a composable stack built around Prometheus and OpenTelemetry, with meters tied to series, telemetry volume, users, and some host-hour products. For metrics, cardinality is a major cost driver on both. For logs and traces, volume, indexing, and retention matter more.
This page compares Datadog with Grafana Cloud and covers a self-hosted Grafana stack wherever it changes the answer. It explains how each pricing model behaves, then compares OpenTelemetry support, query lock-in, operating effort, and migration. The goal isn't to declare one universally cheaper. It's to show which characteristics of your workload will move each bill.
Which Grafana are you comparing?
Datadog is comparable to Grafana Cloud or to a self-hosted LGTM stack. It isn't comparable to Grafana OSS on its own, which is a visualization and alerting application.
"Grafana" gets used in several senses, and most ranking comparisons don't say which one they mean:
- Grafana OSS is the open-source dashboarding and alerting app. Grafana Labs moved it from Apache 2.0 to AGPLv3 in 2021.
- Grafana Labs is the company behind it.
- Grafana Cloud is Grafana Labs' managed SaaS. It runs the LGTM stack (Loki for logs, Grafana, Tempo for traces, Mimir for metrics) plus Pyroscope for profiles, Alloy for collection, Beyla for eBPF instrumentation, IRM for incident response, and more.
- Self-hosted LGTM is the same set of open-source backends, run on your own infrastructure.
- Grafana Enterprise is the self-managed commercial edition, which adds RBAC, SAML, reporting, and enterprise data source plugins.
The pricing discussion below concerns Grafana Cloud. Self-hosted LGTM has no software license bill, so it's covered in terms of infrastructure, operating effort, and when it makes sense rather than as a like-for-like SaaS price. For the full split between the open-source tool and the company, see Prometheus vs Grafana.
Datadog vs Grafana at a glance
Datadog is one integrated vendor with a meter for each product. Grafana Cloud is a composable stack centered on Prometheus and OpenTelemetry, priced per series, per GB, and per user.
| Datadog | Grafana Cloud | |
|---|---|---|
| Deployment model | SaaS on independent regional sites (US1, US3, US5, EU1, AP1, AP2, UK1, US1-FED, US2-FED). BYOC Logs runs a log engine in your own Kubernetes cluster | SaaS. BYOC is available on the Enterprise tier, and the LGTM backends can be self-hosted |
| Billing unit | Per host, plus separate meters for containers, custom metrics, ingested data, and indexed events or spans | Per active series and data point frequency, per GB processed, written, and retained, per active user, and per host-hour for some products |
| Query languages | Datadog metric syntax and DDSQL. No PromQL | PromQL (metrics), LogQL (logs), TraceQL (traces) |
| OpenTelemetry path | Datadog Agent with the embedded DDOT Collector, upstream OTel Collector with the Datadog exporter, or direct OTLP intake | Grafana Cloud OTLP endpoint, Alloy, or the upstream OTel Collector |
| Data residency and FedRAMP | Data stays on the site you choose and can't be shared across sites. US1-FED is FedRAMP High | Grafana Federal Cloud (FedRAMP High, DoD IL5), on the Enterprise tier |
| AI assistant | Bits Investigation (formerly Bits AI SRE), billed in AI Credits | Grafana Assistant, billed per active AI user |
How Datadog and Grafana Cloud price
Datadog and Grafana Cloud expose different billing levers, so comparing a single headline rate is misleading. Datadog starts with host-based products and adds product-specific usage meters. Grafana Cloud leans more heavily on telemetry volume, active series, data point frequency, active users, and host-hours for some managed experiences. Both vendors also offer tiers, allowances, commitments, and discounts that can materially change a quote.
The mechanics line up like this:
| Cost driver | Datadog | Grafana Cloud |
|---|---|---|
| Infrastructure | Primarily host-based, with additional container meters for some products | Host-hours and container-hours for Kubernetes monitoring, plus the telemetry those workloads generate |
| Metrics | Custom metrics are generally counted by metric name and unique tag combinations; an alternative metric-name model is available by contract | Active series are the main unit, with data point frequency affecting the bill at higher collection rates |
| Logs | Ingested volume, indexed event count, retention, and the storage or search tier you choose | Volume processed and written, retention, and in some cases query activity |
| Traces and APM | APM is packaged around monitored hosts, with additional considerations for ingested and indexed spans | Application monitoring host-hours plus the metrics, logs, and traces generated by the application |
| Users and AI | Core observability products are not primarily seat-based; AI usage has its own meter | Some visualization, incident-response, and AI capabilities are billed by active user |
| Commercial terms | Annual, on-demand, and committed arrangements can change the effective rate | Plan tier, included allowances, volume discounts, and enterprise terms can change the effective rate |
How Datadog's model behaves
Datadog's pricing model is easiest to understand as a collection of related product meters rather than one observability price. Infrastructure monitoring and APM are centered on monitored hosts, while containers, custom metrics, logs, indexed spans, RUM, synthetics, security products, and AI introduce their own units.
Metrics are especially sensitive to cardinality. Under Datadog's custom metric model, each metric name and unique tag-value combination can create another billable custom metric. Datadog also offers Metric Name pricing, which shifts the emphasis toward unique metric names and data point volume, but its commercial terms depend on the contract.
Logs have separate ingestion and indexing decisions. Sending a log to Datadog does not necessarily mean keeping it in a standard searchable index. Indexing more events, retaining them longer, or choosing a tier with more search and monitoring capabilities increases cost. Archives and Flex Logs can change the economics, but they also change how and where the data can be queried.
The practical advantage of this model is that teams can buy an integrated platform and tune expensive features individually. The downside is that a bill can accumulate across several products and meters, making it important to model the full deployment rather than the host price alone.
How Grafana Cloud's model behaves
Grafana Cloud's pricing model follows the underlying telemetry more directly. Metrics are driven by active series and, at higher collection rates, data point frequency. Logs and traces are driven by the amount of data processed, written, and retained. Kubernetes Monitoring and Application Observability add host-hour or container-hour meters, while some collaboration, incident-response, and AI features introduce active-user charges.
Cardinality and scrape frequency therefore matter independently. Adding labels creates more series, while collecting those series more often increases data point volume. For logs and traces, reducing noisy data before it is written can lower storage and retention costs. Grafana's Adaptive Telemetry features are designed around that kind of reduction, although the value depends on what your team can safely aggregate or drop.
Grafana Cloud plans can include allowances and volume discounts, so list pricing is not the same as the effective rate at every scale. Teams should also check whether a managed experience adds a host-hour meter on top of the telemetry it produces.
What will move your bill
The cheaper platform depends on the shape of the workload:
| Workload characteristic | Why it matters |
|---|---|
| Autoscaling hosts and dense clusters | Host counts, container counts, and host-hours affect the two platforms differently |
| High-cardinality metrics | Unique Datadog tag combinations or Grafana series can grow quickly as labels multiply |
| Aggressive scrape intervals | Higher collection frequency is particularly important when Grafana bills on data point volume |
| High log volume | Datadog separates ingestion from indexed events, while Grafana meters processing, writing, and retention |
| Small log events | Event-based indexing can make many small records behave differently from fewer large records with the same byte volume |
| Long retention | More searchable history increases storage costs, but the two platforms do not retain and search identical datasets by default |
| Large engineering teams | Active-user meters matter more on Grafana Cloud; Datadog's core observability products lean more on infrastructure and usage meters |
| Broad product adoption | Adding security, RUM, synthetics, incident response, or AI introduces more product-specific meters on either platform |
How to compare quotes
Use at least a month of real telemetry rather than a hypothetical host count. Capture host-hours, container-hours, active series, collection frequency, log bytes and event counts, trace volume, retention requirements, active users, and the share of data that must remain immediately searchable.
Then ask both vendors to price the same workload and spell out:
- which allowances are included
- how bursts and autoscaling are measured
- which telemetry is billed twice through a managed product and its underlying signals
- what changes between annual, committed, and on-demand terms
- how volume discounts are applied
- which search, monitoring, or AI capabilities disappear when data moves to a cheaper tier
This produces a more useful comparison than multiplying public list prices. It also exposes operational trade-offs that a monthly total can hide. Self-hosted LGTM removes the SaaS license bill, but replaces it with infrastructure, upgrades, capacity planning, and on-call work. See operating effort.
OpenTelemetry on Datadog and Grafana
Both platforms accept OTLP, and both translate OpenTelemetry data into their own data model. The real differences are which OTel metrics Datadog bills as custom metrics and which Datadog features still need the Datadog SDK.
Datadog
Datadog offers three ways to send OTel data:
- The Datadog Agent with DDOT, Datadog's distribution of the OpenTelemetry Collector embedded in the Agent. This is Datadog's recommended path.
- The upstream OpenTelemetry Collector with the Datadog exporter.
- Direct OTLP intake, which went GA in July 2026 along with support for the standard OTLP HTTP exporter.
If you use the Agent's OTLP ingest, logs are off by default "to prevent unexpected logs billing", and telemetry has to come from the same host as the Agent.
Whether an OTel metric is billed as custom depends on where it comes from. Metrics from supported OTel receivers aren't custom metrics. Every metric collected through the Prometheus/OpenMetrics checks is. Datadog doesn't list metrics you create with the OpenTelemetry Metrics API as free, and they don't come from a Datadog integration, so under its custom metric definition plan for them to count as custom. Datadog also warns that "incorrectly configured receivers may cause metrics to be classified as custom".
Some Datadog features require the Datadog SDK and don't work with OTel instrumentation: App & API Protection, Continuous Profiler, Data Jobs Monitoring, Real User Monitoring (RUM), and Source Code Integration. Datadog's docs disagree on Data Streams Monitoring: the compatibility matrix lists it as unavailable with OTel, while the Data Streams Monitoring page says it supports OpenTelemetry when APM is already set up with OTel.
Grafana Cloud
Grafana recommends its Grafana Cloud OTLP endpoint for OTel metrics, logs, and traces. You can send through Alloy, Grafana's Apache-2.0 OpenTelemetry Collector distribution with built-in Prometheus pipelines, or through the upstream Collector. Beyla, Grafana's eBPF auto-instrumentation for Linux, was donated to OpenTelemetry as OBI in 2025 and now builds on it. Grafana Cloud stores OTel data in Prometheus/Mimir, Loki, and Tempo formats.
Grafana's compare page says Datadog converts OTel data "into a proprietary data format". Grafana Cloud converts OTel metrics into the Prometheus data model, so both platforms translate OTel data. Datadog says that since July 2026, data from OTel sources powers the same Infrastructure Monitoring and APM experiences that previously needed the Datadog Agent or SDKs.
Query languages and lock-in
OpenTelemetry keeps your instrumentation relatively portable on both platforms. Most of the lock-in sits in your queries, dashboards, and monitors. Datadog's query syntax is its own. Grafana's metrics language is portable, but there are three query languages to learn.
Datadog queries metrics with a tag-based syntax, such as avg:system.cpu.user{env:prod} by {host}, and offers DDSQL for SQL-style queries. Datadog doesn't support PromQL. You can ingest Prometheus metrics, but you query them in Datadog's own syntax (checked against Datadog's docs on 2026-10-05). Dashboards and monitors built on those queries are Datadog-specific.
Grafana uses one query language per signal: PromQL for metrics in Mimir or Prometheus, LogQL for logs in Loki, and TraceQL for traces in Tempo. PromQL also runs on Prometheus and on other backends that implement it, so metrics queries can move with you. LogQL and TraceQL are open, but they're mostly implemented by Loki and Tempo, so they travel less well outside the Grafana ecosystem. Cross-signal work means three backends and three syntaxes, and your team has to learn all three. Grafana Assistant can help write and debug those queries from natural language.
Grafana 13 also made Git Sync generally available, so you can keep dashboards in a Git repository as code. That makes them easier to review and move between Grafana deployments.
Operating effort: SaaS vs self-hosted LGTM
Neither Datadog nor Grafana Cloud requires you to run the telemetry backends yourself. Self-hosting the LGTM stack gets rid of the license bill but turns the cost into headcount.
On Datadog, the setup work is rolling out the Agent. On Grafana Cloud, you deploy Alloy or the Kubernetes Monitoring Helm chart, and Grafana runs the backends. On both, you still own collector upgrades, telemetry pipelines, cardinality and retention settings, alerts, access control, and cost governance. How much work that is depends more on your fleet and integrations than on which vendor you pick.
Self-hosting LGTM means operating several independently scaling services, such as Mimir, Loki, Tempo, and Grafana itself. Mimir, Loki, and Tempo typically depend on object storage, and each has its own capacity planning and upgrade path. OpenObserve, which sells an LGTM replacement, describes a production Mimir deployment as "itself a small distributed system to operate, monitor, and capacity-plan for". On-call is another gap. Grafana archived OnCall OSS on 2026-03-24, and self-hosters lost the SMS, phone, and push notifications that had been relayed through Grafana Cloud. The successor is Grafana Cloud IRM. Upgrades can also take real work: Grafana 12, for example, removed support for Angular plugins.
Self-hosted LGTM has no vendor bill, but it isn't free once you count the engineers who run it. Whether self-hosting saves money depends on whether your team already has the people and the expertise to run these systems.
APM, logs, and Kubernetes compared
Feature coverage is close on the three core signals. The differences are mostly in how features are packaged and what they do by default.
APM
Datadog APM includes Watchdog, which Datadog says detects anomalies and suggests root causes with no setup. Grafana's equivalent is Application Observability, which is built on OpenTelemetry. Organizations onboarded on or after 2026-09-07 get a version powered by the Knowledge Graph, which Grafana says adds a service catalog, RED metrics, and automatic insights.
Logs
Datadog separates ingesting logs from indexing them. Logs that are only ingested aren't in the standard indexes, though archived logs can be queried through Archive Search or rehydrated. Flex Logs data doesn't support monitors or Watchdog. Loki indexes logs by label, while Grafana Cloud's managed service meters the amount of log data processed, written, and retained. Datadog's event-based indexing makes the number and average size of log records important; Grafana Cloud's volume-based meters make total bytes and retention more prominent.
Infrastructure and Kubernetes
Datadog says it has more than 1,000 integrations, and it meters Kubernetes per host and per container. Grafana Cloud sets up Kubernetes monitoring through a Helm chart or Instrumentation Hub (in public preview). Through data source plugins, Grafana can also query data where it already lives, which Grafana Labs calls its "big tent" approach.
AI assistants and the wider platform
Both vendors have an AI assistant that is generally available, and they price them differently. The bigger difference is Datadog's broader product catalog, which is the main reason teams stay with one integrated vendor.
Bits Investigation, launched as Bits AI SRE, became generally available in December 2025 and is billed through AI Credits. Grafana Assistant became generally available in October 2025 and is billed per active AI user, with usage limits attached to that user entitlement. In both cases, AI adds a separate meter rather than being an unlimited feature of the core observability plan.
Beyond the core signals, the two catalogs map roughly like this:
- Security: Datadog sells Cloud Security, SIEM, and App & API Protection.
- Frontend: Datadog RUM and Session Replay compare with Grafana Frontend Observability, which is built on Faro.
- Synthetics and testing: Datadog Synthetics compares with Grafana Synthetic Monitoring. Grafana also offers k6 for load testing.
- Incident response and SLOs: Datadog has Incident Management and On-Call. Grafana has IRM and SLOs with burn-rate alerts.
Grafana can also display Datadog data through the Datadog data source plugin. It's an Enterprise-only plugin, and Grafana describes it as querying Datadog metrics.
Migrating between Datadog and Grafana
OpenTelemetry instrumentation carries over. Queries, dashboards, and monitors have to be rebuilt, and features that need the Datadog SDK have no direct equivalent on the other side.
These carry over from Datadog to Grafana Cloud:
- OpenTelemetry SDKs and Collector configurations, after you change the exporter endpoint
- Prometheus exporters
These have to be rebuilt:
- Datadog metric queries, rewritten in PromQL
- dashboards
- monitors, converted to Grafana alert rules
- anything that sends to the Datadog Agent directly: DogStatsD on port 8125 and APM traces on port 8126
- Datadog's flat
service,env, andversiontags, mapped to OpenTelemetry resource attributes (service.name,deployment.environment.name,service.version)
In translation, metric names, label names, and the way counters become rates all change. These examples come from Dash0's Datadog migration guide. They're conceptual equivalents, not mechanical translations: the label names on the PromQL side depend on how your OTel attributes map to Prometheus labels, and the rate windows and histogram buckets depend on how each metric is exported.
| Datadog | PromQL |
|---|---|
avg:system.cpu.user{host:web-*} | avg(system_cpu_user{host=~"web-.*"}) |
sum:http.requests{service:api}.as_count() | sum(rate(http_requests_total{service_name="api"}[5m])) |
sum:custom.payment.count{method:card} | sum(rate(custom_payment_count_total{method="card"}[5m])) |
p99:trace.web.request.duration{env:prod} | histogram_quantile(0.99, rate(trace_web_request_duration_bucket{deployment_environment_name="prod"}[5m])) |
Moving the other way, from Grafana to Datadog, means rewriting PromQL in Datadog's syntax, because Datadog doesn't support PromQL. Prometheus metrics you collect through Datadog's Prometheus or OpenMetrics checks are billed as custom metrics.
This section only sketches the scope of a migration. For the full process, see Migrating from Datadog to OpenTelemetry and Dash0.
Datadog or Grafana: which to choose
Base the choice on your workload shape and your team. Datadog fits teams that want one integrated vendor, including for security and RUM. Grafana Cloud fits teams built around Prometheus and OpenTelemetry who are willing to manage cardinality and log volume.
- Small team on a modest cluster. Use the vendors' free or entry-level options to test the workflow, but estimate the paid plan with your expected hosts, telemetry volume, active users, and retention. Grafana's active-user meters grow with the team, while Datadog's core observability products lean more heavily on infrastructure and usage meters.
- Dense Kubernetes cluster. Datadog meters hosts and containers, while Grafana Cloud meters Kubernetes host-hours and container-hours alongside the telemetry those workloads generate. Model cluster density and autoscaling rather than comparing only the number of nodes.
- Log-heavy workload. Datadog's cost depends heavily on how much data you ingest and how many events you keep indexed. Grafana Cloud follows the amount processed, written, and retained. Compare the same searchable dataset and retention period; otherwise the quotes are buying different experiences.
- You need integrated security and RUM. Datadog, which sells both alongside its core products. Note that RUM requires the Datadog SDK.
- You already run Prometheus. Grafana Cloud is the more natural fit. Your PromQL and exporters carry over, and existing Grafana dashboards may need little or no rewriting. On Datadog, PromQL isn't available, and metrics collected through its Prometheus or OpenMetrics checks are billed as custom metrics.
- Regulatory or residency requirements. Datadog has independent regional sites, including US1-FED (FedRAMP High). Grafana offers Federal Cloud (FedRAMP High, DoD IL5) and BYOC deployment on its Enterprise tier. Confirm availability and commercial terms for the region and deployment model you need.
Self-hosted LGTM is an option when you have the staff to run several distributed systems and would rather spend on headcount than on a vendor bill.
FAQ
Which is better, Datadog or Grafana?
Neither is better across the board. Datadog suits teams that want one integrated vendor with security and RUM included. Grafana Cloud suits Prometheus- and OpenTelemetry-centered teams that will manage cardinality and log volume. See which to choose.
Is Grafana just dashboards?
Grafana OSS is a visualization and alerting app. Grafana Cloud and the self-hosted LGTM stack add metrics, logs, traces, and profiles backends, plus APM, Kubernetes monitoring, and incident response. See which Grafana you're comparing.
Is Grafana cheaper than Datadog?
Not necessarily. Grafana Cloud can be attractive for Prometheus- and OpenTelemetry-centered teams, while Datadog's model may suit teams that value an integrated product catalog and can control indexed data and custom metrics. The answer depends on hosts and containers, cardinality, collection frequency, telemetry volume, retention, active users, product mix, and contract terms. See how the pricing models behave.
Can Grafana show Datadog data?
Yes, for metrics. The Datadog data source plugin is Enterprise-only, and its plugin page doesn't mention logs or traces. See AI assistants and the wider platform.
Does Datadog support PromQL?
No. Datadog can ingest Prometheus metrics, but you query them in Datadog's own syntax, and metrics collected through its Prometheus or OpenMetrics checks are billed as custom metrics. See query languages and lock-in.
Final thoughts
Datadog and Grafana Cloud bill on different meters, so the useful comparison is your own workload quoted on both. Host and container growth, metric cardinality, collection frequency, log indexing, telemetry volume, retention, active users, and product mix can all change the result. With OpenTelemetry, your instrumentation is relatively portable, so more of the migration cost moves into queries, dashboards, monitors, and vendor-specific features.
If you're still evaluating, Evaluating Observability Platforms 2026 covers the criteria in more depth. If you've already ruled one of them out, see Best Datadog Alternatives and 16 Best Grafana Alternatives, or the backend-specific Loki alternatives and Tempo alternatives.
If you'd like to see how an OpenTelemetry-native backend handles the same workload, try Dash0 free for 14 days, with no credit card required.
