Grafana vs Datadog: Which Bill Does a Fintech on AWS Want?

Every Grafana vs Datadog comparison we have read ends the same way: Datadog is polished and expensive, Grafana is open and cheap, pick the one that suits your culture. That is a decision about taste. The decision that sets the bill is about units.

Datadog bills you per host and hides a hundred custom metrics inside each one. Grafana Cloud charges per active series, however many machines produced them. The same fleet can be cheap on one and startling on the other, and you can find out which before you sign.

So here is the position: choose the unit that matches the shape of your fleet, then ask who is going to run the thing. Most teams do it the other way round and meet the unit on the second invoice.

What is each of them actually counting?

Datadog's unit is the host. Its billing documentation says the billable count "is calculated at the end of the month using the maximum count (high-water mark) of the lower 99 percent of usage for those hours", which is why we called it the ninth-busiest hour in the post on cutting a Datadog bill. Infrastructure Pro is $15 a host a month on an annual commitment, $18 on demand; the rest of the rate card is in the estimate post.

Grafana Cloud's unit is the series. Its metrics pricing documentation defines an active series as "a time series that has received new data points within the previous 20 minutes", and bills "on the 95th percentile of the active series and total DPM it tracks", which "forgives the top five percent of usage time in each monthly billing period, roughly the top 36 hours in a 720 hour month". Pro includes 10,000 series behind a $19 platform fee and then starts at $6.50 per thousand, per its pricing page.

Read those two definitions twice; the whole comparison is in them. Datadog forgives about seven hours a month; Grafana forgives thirty-six. Datadog charges you for a machine that sent nothing interesting. Grafana bills a label somebody added on a Friday.

Why did the Grafana bill move when nobody added a host?

Because a series is a metric name multiplied by every combination of its label values. Grafana's own worked example is a CPU metric with six modes on ten hosts with four cores: one metric, 240 active series. Put a pod name label on a metric that already carries the container and the endpoint, and every rollout that recreates the pods doubles the count for twenty minutes.

Datadog has the same arithmetic; it just hides it. A custom metric is "uniquely identified by a combination of a metric name and tag values (including the host tag)", per its custom metrics page, and Pro includes "100 ingested custom metrics per host", with the same allowance indexed. Integration metrics, the ones the agent pulls from EC2 and RDS, do not count at all. So forty hosts carry four thousand series of application metrics inside the host price, and only the ones nobody planned for bill above it.

Grafana's answer to the label you regret is Adaptive Metrics, which works out whether each metric is "unused, partially unused, or an integral part of your observability ecosystem" and, once you approve its recommendations, applies aggregation rules "to lower the count of persisted time series". It works; it rescued the first Kubernetes bill we moved across. But it is a review queue somebody has to own. Datadog's per-host allowance needs nobody.

Is Grafana really free of a host charge?

Not on Kubernetes, not any more. Grafana Cloud's Kubernetes Monitoring "bills on active host hours and active container hours in a calendar month", where a host is the node "as reported by kube-state-metrics" and a container is active if it has reported "within the last 15 minutes". Plans that started after 13 February 2026 get "no credits applied for telemetry use", per the host-hours page. A node that runs all month is 720 host hours. A container that lived for two minutes is billed for seventeen, because of the fifteen-minute minimum.

So the line you will hear from the open-source camp, that Datadog charges for hosts and Grafana does not, is now half true on EKS. A plain EC2 fleet scraped by node exporter still has no host line on Grafana. We got this wrong in a comparison sheet this spring and had to redo it; the pricing changed under us. Which parts of an EKS cluster are yours in the first place is the question in the managed Kubernetes post.

Where do the logs go, and what do they cost?

Logs are where the two models converge and the regulator diverges from both. Datadog charges $0.10 a gigabyte to ingest and $1.70 per million events to index, per its pricing page. Grafana Cloud includes 50 GB a month and then meters "GBs processed", "GBs written" and "GBs retained", from $0.05, $0.40 and $0.10 a gigabyte, with 30 days' retention on paid accounts and longer billed per gigabyte, per its logs documentation.

Neither is a 180-day tool out of the box, and CERT-In's directions of 28 April 2022, at clause (iv), want logs kept "for a rolling period of 180 days" and "within the Indian jurisdiction". Do not buy that retention from either vendor. Keep the fortnight on-call actually searches in the tool, and put the regulator's copy in S3 in ap-south-1 with object lock, priced as storage. Which of the two can hold even the fortnight inside India is the residency post; briefly, Grafana Cloud has an ap-south-1 region and Datadog has no Indian site.

Who is on call for the tool itself?

This is the question the rate card cannot answer, and the one that has usually decided it.

Datadog is one agent, one vendor and one support ticket. When the dashboard is wrong at 3am, it is their problem or it is your query, and nothing in between. Grafana Cloud is managed too, but what sits in front of it is yours: Grafana Alloy, "a vendor-neutral distribution of the OTel Collector", on every node with a configuration somebody on your team wrote, plus the recording rules and the dashboards. When a scrape target silently drops, the first person paged is you.

Price that honestly. A platform engineer who spends a day a fortnight on the observability stack is a real cost against the gap between two invoices; what that engineer earns is in the hire-or-partner post. If nobody wants that day, Grafana is not cheaper; it is unpaid. Seats are the other line people miss: $8 per active Grafana user beyond three, and $20 per IRM user for on-call, so count the engineers who open a dashboard before you compare quotes.

How do you estimate Grafana Cloud pricing from the Prometheus you already run?

In ten minutes, and series, not hosts, is the number to get. Ask the TSDB directly:

# Active series today
count({__name__=~".+"})

# Which jobs produce them
sort_desc(count by (job) ({__name__=~".+"}))

# Ten worst metric names
topk(10, count by (__name__) ({__name__=~".+"}))

# Samples per minute; divide by the first number for DPM
sum(rate(prometheus_tsdb_head_samples_appended_total[5m])) * 60

Subtract the 10,000 included, divide by a thousand, multiply by $6.50, and you have the metrics line before any discount. Pro accounts include "a default resolution of 1 DPM per active series", so if the last number divided by the first is well above one, your scrape interval is costing you as well. After signup the same count is grafanacloud_instance_active_series in the grafanacloud-usage data source.

For the Datadog side, a trial exposes datadog.estimated_usage.hosts and datadog.estimated_usage.metrics.custom, with the caveat on Datadog's usage metrics page that "there is a 10-20% difference between estimated usage and billable usage on average". Run both sheets with no discount applied. The discount is what the sales call is for; the shape of the bill is what you are choosing now.

Grafana vs Datadog: when is each one the honest answer?

Datadog, when nobody owns observability and nobody is about to. A five-engineer fintech with forty hosts, a handful of custom metrics and no platform team pays $600 a month for Infrastructure Pro on an annual commitment, adds logs and APM through the same agent, and never thinks about cardinality. The Grafana equivalent may be cheaper on paper and will cost that team its only senior engineer's Fridays.

Grafana, when the fleet is many small hosts sending few series each, when you are already on Prometheus, or when the residency answer has to be ap-south-1 with the vendor inside it. Many small Kubernetes nodes on Datadog is the expensive quadrant: the host charge multiplies with the node count while the useful metrics do not. On Grafana the same cluster now carries host hours as well, so run the arithmetic rather than assume it.

And the middle path exists. Datadog for the fortnight, S3 for the regulator's copy, and a cardinality review whichever tool you chose. Where we usually land with a regulated team on AWS is Grafana Cloud in Mumbai with a partner or an engineer who owns Alloy, and Datadog when there is no such person. Both are defensible. "It is cheaper" on its own is not.

The short version

Decide the unit before the tool. Count your active series from the Prometheus you have, count your hosts from EC2, and price the fleet against both rate cards with no discount. Then name the person who will own the collector, the recording rules and the cardinality review. If you cannot, the Datadog quote is the cheaper one whatever the sheet says.

Keep the 180 days out of either vendor and in S3 in ap-south-1. And if you are on EKS, re-run the Grafana sheet with host hours in it, because the answer changed in February and most comparisons online have not caught up.

This is engineering guidance, not legal advice. Regulations and their annexures are amended over time; read the current text and take your compliance position from counsel.