Datadog Alternative: Which Ones Actually Keep Data in India?

Every list of Datadog alternatives ranks the same dozen tools on price per gigabyte. Not one of them asks the question that decides it for a payments company in Mumbai: where does the data physically land, and can you produce 180 days of it from inside the country when somebody asks?

Ask that first and the shortlist collapses. Datadog runs nine sites and none of them is in India. The obvious AWS-native replacement is not in Mumbai either, which caught us out the first time we checked and sent us back to redraw a migration diagram.

So here is the position this post defends: for a regulated fintech on AWS, a Datadog alternative is chosen on residency first and cost second. Pick on price alone and the cheaper bill buys you an audit finding.

Why do most Datadog alternative lists not help a fintech?

They are written for a buyer in San Francisco, where every serious vendor is already in us-east-1 and the only variable left is the invoice. Residency never appears as a filter because it is never a constraint.

Reverse the order. First filter on the vendor's region list. Then ask who inside the vendor can read what you send. Only then does the per-gigabyte rate matter, and by that point you are usually choosing between two tools rather than twelve.

There is also a cheaper move most teams skip. A large share of an observability bill is logs nobody queries and metrics nobody alerts on, and that waste migrates with you. We went through where it hides in the post on cutting a Datadog bill. Do that first, or you will benchmark the new tool against your own waste and draw the wrong conclusion from it.

Where does Datadog actually keep your data?

In one of nine sites, and you choose it once. The site documentation lists US1, US3, US5, EU1 in Germany, UK1, AP1 in Japan, AP2 in Australia and two United States government sites. There is no Indian site on that list.

One sentence on that page matters more than the list itself: "Each site is completely independent, and you cannot share data across sites." A site is not something you flip during a compliance review. Changing it means a new organisation, new API keys, every agent re-pointed, and the history left behind.

For plenty of teams AP1 in Tokyo becomes the answer by default, because it is the closest and the latency looks fine. It is still Japan. If the obligation is that logs sit in India, Tokyo does not meet it however good the round trip is.

Which alternatives actually have an India region?

Grafana Cloud does. Its regional availability page lists India twice, on AWS ap-south-1 and on GCP asia-south1. For a managed tool that is the short honest answer, and it is the one we most often end up recommending.

With one catch, from the same page: "Grafana does not support changing the Grafana Cloud region of an existing stack. Instead, create a new stack." The region is fixed at signup, exactly like the Datadog site. If somebody on your team spun up a free stack in us-east-1 two years ago and it quietly became production, that stack cannot be moved into India.

The other category is the one you run yourself: Prometheus, Loki, OpenSearch or SigNoz in your own ap-south-1 account. Residency stops being a vendor's promise and becomes a fact about your VPC that you can demonstrate from a console. You pay for it in engineer hours. That is the real trade, and it is the one these comparisons usually leave out.

Why is the AWS-native answer only half an answer?

Because the two halves are not in the same place. Amazon Managed Service for Prometheus is in Mumbai: its service documentation lists ap-south-1 and ap-south-2 among the supported regions. Amazon Managed Grafana, the thing you would naturally put in front of it, is not. Its supported Regions table has Seoul, Singapore, Sydney and Tokyo, and no Indian region at all.

That is survivable. A dashboard in Singapore querying a workspace in Mumbai is not the same thing as storage sitting abroad. But it is a conversation with your auditor you had not planned, and the way out is small: run Grafana yourself on a container in your own account and the question stops being asked.

Worth knowing before you commit to the cloud provider's own tools, though: this estate moves under you. AWS has closed CloudTrail Lake to new customers from 31 May 2026 and now points people at CloudWatch, noting that data from before 2023 will not migrate. Native is not automatically the stable choice.

Does any of this satisfy CERT-In?

Only if you check the retention number, because the default will not get you there. Metrics in a Prometheus workspace are stored for 150 days by default, per the same AWS documentation, and can be configured up to 1,095. CERT-In's directions of 28 April 2022 ask for a rolling 180 days of logs, held within Indian jurisdiction. A workspace left alone is thirty days short and nothing warns you about it.

Set retention on the day the workspace is created, per workspace. And keep the two copies apart: the regulator's 180 days belongs in S3 in ap-south-1 with object lock, priced like storage, while the tool holds the fortnight your engineers actually search. Whether the payment data should ever reach the tool is the harder question, and that one is in the data localisation post.

How do you trial an alternative without re-instrumenting everything?

Send to both at once for two weeks. The OpenTelemetry Collector makes that cheap, because a pipeline takes a list of exporters rather than one: the configuration documentation shows several exporters on a single pipeline and notes you can use the same component "in more than one pipeline".

This is the piece to hand your platform engineer on Monday:

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317

processors:
  batch:

exporters:
  datadog:
    api:
      site: datadoghq.com
      key: ${env:DD_API_KEY}
  otlphttp/candidate:
    endpoint: https://<your-candidate-otlp-endpoint>/otlp
    headers:
      Authorization: ${env:CANDIDATE_TOKEN}

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [datadog, otlphttp/candidate]
    metrics:
      receivers: [otlp]
      processors: [batch]
      exporters: [datadog, otlphttp/candidate]

Point one service at it, not the fleet. Two weeks later you have the same traffic in both tools, which is the only comparison worth trusting, and you have found out how many of your Datadog monitors and dashboards nobody was willing to rebuild.

While that runs, find out what you are paying to collect in the first place:

aws logs describe-log-groups --region ap-south-1 \
  --query 'reverse(sort_by(logGroups,&storedBytes))[:10].[logGroupName,storedBytes,retentionInDays]' \
  --output table

A retentionInDays that comes back empty means the group never expires. Those are usually the ones at the top of the list.

What does the switch actually cost?

More than the difference between two rate cards, and the gap is people. Budget the rebuild of every monitor and dashboard, the re-education of everyone who knows where to click at 3am, and a stretch where both tools are running and you are paying for both. Against the fleet we priced in the Datadog estimate post, a month of platform engineering eats a good share of the first year's saving.

The saving that does survive that arithmetic is structural rather than a discount. On a stack you host, log volume lands on S3 at storage prices instead of an indexing rate, and that gap widens as you grow. If your bill is mostly logs, that is the lever worth pulling. If it is mostly hosts and seats, read how per-seat pricing changes the arithmetic before you assume a migration helps at all.

When is staying on Datadog the honest answer?

More often than a post like this usually admits.

If your entity is outside the scope of the directions, if your telemetry carries no payment or personal data, or if you have five engineers and nobody who wants to own a Prometheus cluster, the residency argument is theoretical and the migration is six weeks you do not have. Datadog is a better product than most of what replaces it, and the integrations you would be rewriting took somebody years to build.

There is a middle path teams forget, too. Keep Datadog for the fortnight on-call actually searches, strip the regulated fields in the forwarder before anything leaves the box, and hold the 180 days in S3 in ap-south-1. No migration, and the residency question is answered for the data where it matters.

The short version

Filter on the region list before the rate card. Datadog has no Indian site and will not move your data between sites. Grafana Cloud has ap-south-1, and its region is fixed at signup as well, so choose it on purpose rather than by accident. Amazon Managed Service for Prometheus is in Mumbai and Amazon Managed Grafana is not, so plan to host the dashboard. Raise that 150-day default if you are counting to 180, and keep the compliance copy in S3 rather than inside the tool.

Then run the Collector with two exporters for a fortnight on one service and decide on your own traffic rather than on anyone's comparison table. If nobody on your team can say which site or region your current tool writes to, start there. That answer takes ten minutes and it often ends the discussion.

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.