"Datadog or Grafana?" is almost never really a feature question. Both stacks can collect metrics, logs and traces, both can alert, and both can draw a dashboard your CTO will screenshot. The question that actually decides it is what your bill looks like in eighteen months when traffic has tripled, you have added forty services, and someone has enabled debug logging in production on a Friday. The two platforms answer that question in very different ways.
The two pricing models in one paragraph each
Datadog bills primarily per host, then per signal on top. Infrastructure monitoring is priced by host per month, with APM, log ingestion and retention, synthetics, RUM, custom metrics, profiling and security each carrying their own line. The model is predictable in the small: a hundred stable hosts cost roughly the same every month. It becomes unpredictable in the places teams don't watch — custom metric cardinality, indexed log volume, container counts on autoscaling nodes, and the long tail of per-product add-ons that individual teams switch on without a budget conversation.
Grafana bills primarily per unit of data (or not at all). Grafana Cloud charges by active metric series, log and trace volume ingested, and retention window, with a genuinely usable free tier. Self-hosting Grafana with Prometheus, Loki, Mimir and Tempo has no licence cost at all — you pay in storage, compute, and a named engineer's time. The model rewards teams who control cardinality and are comfortable owning infrastructure, and punishes teams who treat "just ship every label" as a default.
Where each one tends to get expensive
Datadog: hosts you forgot, and cardinality
The three cost surprises we see most often, in order of frequency:
- Elastic infrastructure billed as though it were static — aggressive horizontal autoscaling, short-lived CI runners, and per-pod agents all convert into host-hours.
- Custom metrics with unbounded tags. One well-meaning user_id or request_path tag on a busy service can generate hundreds of thousands of custom metric series.
- Log indexing used as log storage. Indexing everything for 30 days when you only query 1% of it is the single biggest avoidable line on most Datadog invoices.
None of this is a criticism of the product — it is genuinely excellent, and the correlation between traces, logs and infrastructure out of the box saves real engineering hours. But the pricing model means the cost of a careless instrumentation decision lands on finance, not on the team that made it, which is why cost governance has to be part of the rollout rather than an afterthought.
Grafana: the bill you don't see on the invoice
Self-hosted stacks look free until you cost the people. A production-grade Prometheus/Mimir setup with long-term storage, high availability, an alerting pipeline, upgrade cadence and a Loki deployment that doesn't fall over during an incident is a standing commitment — realistically a meaningful slice of one engineer indefinitely, plus the object storage and compute underneath. If that engineer leaves, the platform becomes the thing nobody wants to touch. Grafana Cloud removes most of that operational load and pushes you back into usage-based billing, where the same cardinality discipline applies: active series and ingested log volume are the numbers to watch.
Self-hosted Grafana/Prometheus vs Grafana Cloud
The honest split is about who you want on call for the observability platform itself. Self-hosting makes sense when you already run stateful infrastructure competently, have data residency or air-gap requirements, or your data volumes are large enough that per-unit cloud pricing dwarfs the cost of running it yourself. Grafana Cloud makes sense when your scarcest resource is engineering attention — which is true for most teams under about fifty engineers — and when you would rather spend that attention on the instrumentation than on Mimir compactors.
A pattern that works well in practice: start on Grafana Cloud, keep everything OpenTelemetry-native and Prometheus-compatible, and revisit self-hosting only when the invoice makes the operational cost look cheap. Because the query languages and exposition formats are open, that migration is a genuine option later — which is itself part of the cost calculation.
A rough guide by team size and maturity
- Small team, few services, no on-call rotation yet: Grafana Cloud free or low tier, or a managed metrics offering from your cloud provider. Do not buy a platform to solve a problem you cannot yet describe.
- One to three product teams, a real on-call rotation, growing incident count: this is where Datadog earns its price. Correlated traces, logs and infrastructure shorten debugging materially, and host counts are still small enough to be predictable. Set indexing and custom-metric budgets on day one.
- Scale-up with dozens of services and elastic infrastructure: expect a hybrid. Keep high-value services on the premium platform, route high-volume low-value telemetry (debug logs, verbose access logs) to cheap object storage with query-on-read, and enforce cardinality review in code review.
- Enterprise with a platform team: self-hosted or Grafana Cloud Enterprise usually wins on unit economics, provided the platform team is genuinely resourced. If it is not, per-host pricing is cheaper than an unowned Prometheus cluster.
How to actually compare them
Vendor calculators model the estate you have today, not the one you will have. Before you sign anything, model three numbers per platform: cost at today's volumes, cost at three times today's volumes with the same instrumentation, and cost at three times volumes with the instrumentation you actually want (tracing on every service, structured logs everywhere, SLO-based alerting). The gap between the second and third figure is where most teams get caught, because good observability increases telemetry volume on purpose.
Then add the constraints that don't appear on any invoice: how long onboarding takes, whether your engineers will actually use the query language, whether you can leave later without re-instrumenting everything, and what happens to your bill during an incident when log volume spikes tenfold. Instrument with OpenTelemetry regardless of the answer — it is the only decision here that keeps every other option open.
The short version
Datadog trades money for engineering time and gives you predictability per host with sharp edges around cardinality and log indexing. Grafana trades engineering time for money and gives you control with sharp edges around operational ownership. Neither is the right answer in the abstract; the right answer depends on how elastic your infrastructure is, how disciplined your instrumentation is, and whether anyone is funded to own the platform.