.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
Fifteen dollars per host per month, billed annually. That is Datadog Infrastructure Pro, it is the number people quote at each other in these arguments, and on its own it settles nothing.
The two products solve the same problem from opposite ends. Datadog is finished software you point agents at and start paying for. A Grafana stack is a set of open source components you assemble and keep running. Their feature checklists overlap enough that reading them side by side tells you almost nothing you can act on.
What decides it is money shape and hours. Datadog's bill scales with your infrastructure whatever you do, and its operational cost is close to zero. A self-hosted Grafana stack has a nearly flat bill and an operational cost that lands on someone in your team. Everything below is about which of those two curves fits your situation.
What you get out of the box with Datadog
You install one agent per host. Within about ten minutes you have infrastructure metrics, process-level detail, container discovery, log collection if you enable it, plus several hundred integrations that light up automatically when the agent notices Postgres or nginx or Redis running. Dashboards for those integrations exist before you have written anything.
Add the tracing library to an application and you get distributed traces, service maps, flame graphs and per-endpoint latency percentiles correlated with the host metrics underneath. That correlation is genuinely hard to build yourself. It is the strongest argument for the product, and nothing in the open source world hands you a service map that accurate without deliberate work.
Some of what you are buying never appears on a comparison table. Nobody upgrades the storage layer. Nobody gets paged because the monitoring system fell over. Retention and query performance are somebody else's problem, and that somebody has a support contract.
What you assemble with the Grafana stack
Four moving parts, and only one of them is Grafana. Grafana handles dashboards, alerting, access control and provisioning. Prometheus or Mimir stores metrics. Loki stores logs. A collector runs on each host, which today means Grafana Alloy, an OpenTelemetry Collector distribution with Prometheus pipelines and native Loki and Pyroscope support built in. The split between the display half and the storage half is the thing most people have to unlearn first, and Grafana versus Prometheus works through it properly. Skip that one if you already run Prometheus.
Grafana Agent reached end of life on 1 November 2025, so the Alloy documentation is the reference for anyone with older configs lying around. It carries migration paths from both Static and Flow modes.
None of those pieces is hard on its own. A single VPS running Grafana and Prometheus with node_exporter on a handful of targets is an afternoon, and the commands are in installing Grafana on an Ubuntu VPS if you want to follow along. The cost is not the install. It is the tail: retention policy, backups of the Grafana database, TLS renewal, an upgrade every couple of months, plus a decision about who gets woken up when the monitoring host itself goes quiet.
Adding tracing steps the effort up again. Tempo plus instrumentation gets you traces, and the trace-to-log and trace-to-metric links in Grafana are good, but you are wiring the correlation that Datadog ships pre-built. Budget for that honestly.
How the two bill
Both vendors change pricing regularly, so the shape below matters more than the numbers, and the numbers carry a date. These are from the vendors' own pricing pages, checked on 26 August 2026.
| Line item | Datadog | Self-hosted Grafana stack | Grafana Cloud |
|---|---|---|---|
| Metrics | Per host, per month, with a custom metric allotment per host | Server cost only | Per 1,000 active series |
| Logs | Per GB ingested, then separately per million events indexed, priced by retention | Server and disk cost only | Per GB, split into process, write and retain |
| APM | Per host, per month, with span ingest and indexed span allotments | Server cost only | Per GB of traces |
| Users | Not billed per user for core products | Unlimited, free | Per active user, per month |
| Growth driver | Host count, then custom metric count | Series cardinality and disk | Series cardinality and log volume |
The figures from Datadog's pricing page that day, for the record. Infrastructure Pro at $15 per host per month billed annually or $18 on-demand. Enterprise at $23 annually. Log ingest at $0.10 per uncompressed GB, with standard indexing at $1.70 per million events. APM at $31 per host per month annually, including 150 GB of span ingest per APM host. Treat every one of those as a rough order of magnitude by the time you read this.
The self-hosted equivalent is one server, or two if you separate Grafana from Prometheus, plus disk. That bill does not move when you add a host to monitor. It moves when you add series or log volume, and it moves in whole-server steps.
Custom metrics and how the Datadog bill grows
Infrastructure plans include an allotment of custom metrics per host, listed as 100 on Pro and 200 on Enterprise at the time of checking. A custom metric is a unique combination of metric name and tag values. Add a tag with meaningful cardinality to a metric you emit everywhere, a customer ID or a URL path, and one metric becomes thousands of billable custom metrics. Datadog's pricing page notes that custom metrics are counted hourly and averaged monthly across the whole account rather than per host, so the allotment pools, which softens the edge without changing the mechanism.
Nothing warns you at write time. A developer adds a tag in a pull request, the metric fans out, and the invoice reflects it a month later. Self-hosted Prometheus punishes the same mistake, and it punishes it faster and more visibly: the Prometheus process starts eating RAM within the hour and you go fix the label.
Given a choice between those two failure modes I take the Prometheus one every time. An out-of-memory kill at three in the afternoon gets fixed at three in the afternoon. A line on an invoice gets noticed by finance six weeks later, and by then three other teams have copied the pattern because it looked fine in review.
Operational effort and who gets paged
Run the numbers as hours rather than currency. A self-hosted stack for a small fleet costs a few hours to build, then perhaps an hour a month of care, plus an unpredictable half day two or three times a year when something breaks in a way you have not seen. Grafana upgrades are usually uneventful.
Loki upgrades are the ones I brace for. Two have gone badly for me across five years and I still cannot tell you what those two had in common, so the routine is now to read the changelog and snapshot the volume before starting. There may be a real pattern in it that I have not spotted.
The failure mode that costs you most is the monitoring host going down at the same time as everything else, because they share a provider, a region or a power feed. Datadog does not have this problem for you. Self-hosted, you fix it with a dead man's switch: a heartbeat alert that fires when the stack stops reporting, sent through an independent channel. Put the Grafana instance in a different region from the systems it watches and the whole class of correlated failure mostly evaporates.
The other honest cost is expertise. PromQL, LogQL, relabelling rules and Grafana's alerting model are real skills, and the person who holds them becomes a dependency. Datadog's query builder is friendlier to someone who never wants to learn a query language, and on a mixed team that is worth something.
Data ownership and residency
With Datadog your telemetry leaves your infrastructure and lands in the site you chose at signup. The Datadog site documentation lists US1, US3 and US5 in the United States, EU1 in Germany, AP1 in Japan and AP2 in Australia, plus the government sites, and it states plainly that each site is completely independent and you cannot share data across sites. Picking the wrong one is a re-onboarding, not a settings change.
A small aside on those names, since the docs are confusing to skim. US1 is the original site. US3 and US5 came later on different cloud providers. There is no US2 in the current list, and nothing in your setup depends on any of this. It just means that when somebody says "the US site" in a ticket, you have to ask which one.
For a European team under GDPR, an EU site handles the question adequately for most cases. Where it stops being adequate is when a contract, a public sector tender or an internal policy requires that telemetry never sits with a US-headquartered processor at all. Logs are the sharp end of this, because application logs pick up personal data constantly and no amount of scrubbing rules is airtight.
Self-hosting sidesteps the argument. Your metrics and logs sit on a machine you rent, in a country you named, under a processor agreement you signed. If that is the deciding factor, running the stack on a European VPS in Frankfurt, Amsterdam or Helsinki is straightforward, and LumaDock's one-click Grafana template gets the visualisation half up without the install steps. The data never leaves the box you chose.
Migration friction in each direction
Datadog to Grafana is easier than it used to be and still not free. Metrics collection ports over cleanly if you are already emitting Prometheus-format or OpenTelemetry metrics, since Alloy can scrape the same endpoints. Dashboards do not port. There is no reliable converter and you will rebuild them, which takes a week of evenings for a real estate of dashboards. Monitors become Grafana alert rules or Prometheus rules, rewritten by hand. APM is the hard part, because you are swapping tracing libraries and rebuilding the correlation.
Grafana to Datadog is the smoother direction, which is a fair point in Datadog's favour. The agent ingests Prometheus and OpenTelemetry metrics, so your existing exporters keep working, and you get value on day one without touching application code. You still rebuild dashboards and alerts, and you inherit a bill that grows with your host count.
In both directions, run the two systems in parallel for a month before switching off the old one. Alerts you forgot to port are only visible by their absence, and you find them by comparing what fired where.
Where Datadog genuinely wins
APM is the clearest win. Automatic instrumentation, service dependency maps, endpoint-level latency breakdowns and the ability to jump from a slow trace to the host metrics and logs from the same second, all without building anything. The open source path gets you there with Tempo and careful instrumentation, and it takes real work.
Integration breadth is the second. Several hundred maintained integrations with dashboards and monitors included beats hunting for a community Grafana dashboard ID and discovering it was written for a metric naming scheme two exporter versions ago. Security monitoring, synthetics, RUM and incident management under one login is the third: assembling equivalents from separate open source projects is possible and it is a project, not an afternoon.
And the operational point stands. If your team is four engineers shipping product, the correct number of self-hosted observability stacks to maintain may well be zero.
Which one to pick
Pick Datadog if you have fewer than roughly fifty hosts, no one whose job includes infrastructure, plus a product where engineering time is worth more than the invoice.
Also pick it if APM is the reason you are shopping at all. I have watched two teams build the Tempo equivalent from scratch. Both got there, and both spent a quarter on something they had budgeted a fortnight for, which is the sort of estimate error that only shows up once you are committed.
Pick a self-hosted Grafana stack if you already run servers competently, your host count is large enough that per-host pricing has started to look silly or data residency is a contractual requirement rather than a preference. Also pick it if your metrics are high cardinality by nature, since you would be buying the expensive part of Datadog's model on purpose. The exposure checklist is in Grafana security best practices, and it stops being optional the moment the instance has a public IP. Do the loopback bind and the reverse proxy before anything else on the list.
Take the middle option if you want Grafana's query experience without running Mimir and Loki. Grafana Cloud is a managed version of the same stack with a free tier that covers small setups, and the arithmetic is in Grafana Cloud versus self-hosted. It bills on series and ingested gigabytes rather than per host, which suits a few large machines and punishes high cardinality. If neither vendor is what you want, the alternatives roundup has ten lighter options in it.
One habit is worth having regardless of which side you land on. Keep collection vendor-neutral: emit OpenTelemetry or Prometheus-format metrics from your applications and let the collector decide where they go. Do that and switching costs you dashboards and alert rules, which is annoying, instead of costing you instrumentation, which is a quarter of engineering time. Operating the open source side properly is covered in the complete Grafana guide.
