Comparing a Datadog invoice to an OpenSearch infrastructure bill is comparing two different things, not two competing costs.
Short answer
Datadog and OpenSearch are not priced in comparable units, and a defensible comparison cannot start from list prices. Datadog is a managed SaaS platform whose invoice already includes most backend operations; OpenSearch's invoice — whether self-managed or run through Amazon OpenSearch Service — typically excludes the engineering effort required to keep a search and analytics cluster reliable. A real total cost of ownership model has to add platform labor to the OpenSearch side and usage-governance discipline to the Datadog side before the two numbers mean anything next to each other. Neither platform is structurally cheaper. Each moves cost to a different place: Datadog moves it into SaaS consumption dimensions that must be governed; OpenSearch moves it into infrastructure and engineering capacity that must be staffed.
Why the naive comparison fails
The comparison that gets built on a whiteboard usually looks like this: take the current Datadog invoice, estimate the infrastructure an equivalent OpenSearch cluster would need, and compare the two numbers. That comparison is incomplete in a specific, predictable way — it compares a fully loaded commercial price against a partially loaded infrastructure estimate.
Datadog's invoice already bundles cluster operations, upgrades, capacity management, and platform availability into what the customer pays. An OpenSearch infrastructure estimate — EC2 or equivalent compute, EBS storage, data transfer — bundles none of that. The team that keeps an OpenSearch cluster healthy, sized correctly, upgraded, and recoverable after a bad deployment is a real cost that does not appear on a cloud invoice, and it is usually the single largest gap between the two sides of this comparison.
This is the same discipline this site applies to the closely related OpenSearch vs Elasticsearch decision: choose between operating models, using workload fit and risk-adjusted three-year cost, not between products using a single number pulled from a pricing page.
Two decisions, not one
A Datadog-to-OpenSearch comparison is actually two separate decisions that are easy to collapse into one.
Decision 1 — which platform fits the workload. Datadog and OpenSearch are structurally different tools before cost even enters the discussion. Datadog is an integrated observability product: infrastructure metrics, APM, logs, dashboards, monitors and increasingly security capabilities inside one operational experience, with agents, integrations and a SaaS control plane. OpenSearch is a search and analytics engine. Building an observability practice on it means assembling collection (commonly OpenTelemetry or Fluent Bit/Data Prepper), storage design, dashboards (OpenSearch Dashboards), alerting and correlation yourself, or through a managed layer.
Decision 2 — who operates the target. For OpenSearch specifically, this decision has three materially different answers: self-managed OpenSearch on infrastructure the organization owns end to end, Amazon OpenSearch Service as provisioned domains, or Amazon OpenSearch Serverless. These are not the same cost model, and treating "OpenSearch" as one line item in a spreadsheet erases the distinction that actually determines the price.
Collapsing these two decisions into "Datadog vs OpenSearch, which is cheaper" is the single most common reason this comparison produces a number nobody trusts six months later.
What actually belongs in the model
A three-year total cost of ownership comparison should include every item below where it materially applies. Skipping a row does not remove the cost — it just moves it outside the model, where it resurfaces later as a surprise.
| Cost category | Datadog side | OpenSearch side |
|---|---|---|
| Platform / license cost | SaaS subscription and usage-based charges | None for self-managed software; instance/OCU and storage charges for Amazon OpenSearch Service |
| Compute infrastructure | Included in SaaS price | EC2/equivalent instances, or provisioned/serverless capacity units |
| Storage | Included, governed by retention tier | EBS or equivalent, plus UltraWarm/cold tiers where used |
| Data transfer / network | Included | Cross-AZ and egress transfer, which AWS bills separately with documented exceptions for some intra-domain traffic |
| Backups / snapshots | Included | Snapshot storage and restore-testing time |
| Kubernetes or VM operations | Not applicable | Real cost if self-managed or ECK-style deployment |
| Platform engineering labor | Lower — shifts toward SaaS governance | Higher — cluster sizing, shard design, upgrades, capacity planning |
| Upgrades | Handled by Datadog | Owned by the customer for self-managed; partially owned for managed domains |
| Security / access control | Included, governed by configuration | IAM, network policy, encryption configuration — customer-owned either way |
| Reliability / availability engineering | Datadog's operational responsibility | Customer's responsibility for self-managed; shared for managed service |
| Disaster recovery | Included | Snapshot/restore design and testing — customer-owned |
| Incident cost (platform-down time) | Rare, but customer has limited control | Directly proportional to internal operational maturity |
| Observability of the observability platform | Included | Additional tooling/effort to monitor cluster health |
| Support | Included in contract tier | AWS support plan, or internal/vendor support arrangement |
| Migration engineering (if moving from an existing platform) | One-time | One-time — often larger due to schema, dashboard and agent rebuild |
| Training / ramp-up | Lower — established product conventions | Higher if the team lacks distributed-search experience |
Datadog documents billing dimensions such as infrastructure hosts, APM hosts, custom metrics and log ingestion/indexing as separate, independently metered products — see Datadog Logs Pricing: Ingestion, Indexing and Retention Explained and Datadog Custom Metrics and Cardinality: How Costs Grow for the mechanics of two of the largest of these. On the AWS side, Amazon OpenSearch Service exposes its own separate cost surface: provisioned instance hours, storage, UltraWarm and cold-storage tiers at lower per-GB cost than hot storage, cross-AZ and egress data transfer (with documented exceptions for some intra-domain traffic), and — for domains on versions covered by AWS Extended Support — an additional normalized-instance-hour charge that is easy to miss when the original deployment decision was made.
Managed OpenSearch, self-managed OpenSearch, and Kubernetes-based OpenSearch are not the same cost curve
Amazon OpenSearch Service (provisioned domains) removes node provisioning and replacement from the customer's task list, but the customer still owns domain design, shard strategy, index mappings, capacity limits, access policy and cost governance. It is a materially lower operational burden than self-managed, not an operations-free platform.
Amazon OpenSearch Serverless changes the unit of billing to compute capacity (OCUs) and managed storage rather than provisioned instances, and recent generations of the service have introduced scale-to-zero and pay-per-use behavior. That is a meaningfully different economic curve from provisioned domains for spiky or intermittent workloads, and a poor fit for steady, high-throughput ingestion where provisioned capacity is more predictable.
Self-managed OpenSearch — on VMs or on Kubernetes — removes AWS's managed-service margin but transfers essentially the entire operational surface to the internal platform team: capacity planning, shard and index lifecycle, upgrades, snapshot and restore testing, security hardening, and incident response when the cluster itself is the incident. This can be the most economical option at meaningful scale for an organization with an established search-platform practice. It can also be the most expensive option in practice for an organization that underestimates the staffing this requires and discovers the gap during an outage rather than during planning.
Do not model "OpenSearch" as one row. Model the specific operating model under evaluation, because the three above do not share a cost curve.
A scenario-based way to reason about this, without invented numbers
Rather than asserting a savings percentage that would not survive contact with an actual contract, use scenarios to test which cost category dominates for a given organization.
Scenario A — SaaS-first platform team, moderate telemetry volume, limited backend engineering capacity. The dominant cost driver on the Datadog side is usage governance across several independently metered dimensions; the dominant cost driver on the OpenSearch side is the platform engineering the organization does not currently have and would need to build or hire. Datadog is structurally more likely to win this comparison, because the organization is paying to avoid a capability gap it does not want to close.
Scenario B — established search-platform team, high and predictable telemetry volume, AWS-standardized infrastructure. The organization already carries much of the OpenSearch operational cost in existing headcount, and Amazon OpenSearch Service or self-managed OpenSearch on already-provisioned infrastructure has a lower marginal cost per unit of additional volume than adding that same volume to a SaaS contract's usage dimensions. OpenSearch is structurally more likely to win this comparison.
Scenario C — mixed estate with some workloads well suited to SaaS observability and others requiring deep search customization. Neither platform wins outright, and the honest architecture is not "pick one." It is a workload-by-workload allocation, governed well enough that the organization does not end up paying full operational and full SaaS cost for the same telemetry twice.
The purpose of these scenarios is not to tell you which one you are in. It is to demonstrate that the answer is workload- and organization-specific, not a property of either platform.
Where a calculator helps, and where it does not
Use the Observability Stack Cost Comparison Calculator to build a first directional model of infrastructure, storage and usage inputs across platforms. Use the Datadog Cost Optimization Calculator to estimate current Datadog usage-dimension exposure before assuming a migration would change it. For the parallel Elastic/OpenSearch operating-model decision, the weighted scorecard and three-year TCO calculators in OpenSearch vs Elasticsearch for Observability apply directly if OpenSearch is being evaluated against Elastic Cloud as well as against Datadog.
A calculator produces a directional estimate from the inputs you give it. It cannot tell you whether your organization can actually staff an OpenSearch platform team, whether your Datadog usage governance is disciplined enough to avoid uncontrolled growth, or whether a migration's engineering cost is smaller or larger than the three-year savings it is meant to produce. Those questions require the workload, contract and team-capability evidence described above.
What a migration from Datadog to OpenSearch actually requires
If the TCO analysis favors OpenSearch, the decision is still not complete, because moving from an integrated SaaS product to a self-assembled or managed search platform is not a data-copy exercise. Dashboards, monitors, unified service tagging, correlation between logs/traces/metrics, and alert logic built around Datadog conventions do not transfer automatically — they require redesign around OpenSearch Dashboards, the collection layer chosen (commonly OpenTelemetry), and whatever alerting and correlation tooling replaces Datadog's integrated experience.
The execution mechanics of running that kind of transition safely — dual collection, validating that alerts and dashboards produce equivalent operational coverage, staged cutover, rollback — are covered separately in How to Run a Parallel Observability Migration Without a Big-Bang Cutover. This article's scope stops at the economic decision; that one covers how the decision gets executed once it has been made.
A practical decision table
| If this is true | The comparison usually favors |
|---|---|
| Backend operational burden must be minimized and the team is small | Datadog |
| The organization already runs OpenSearch or Elasticsearch at scale with a capable platform team | OpenSearch (managed or self-managed, depending on infrastructure standardization) |
| AWS-native operation and infrastructure control are strategic requirements | Amazon OpenSearch Service or self-managed on AWS |
| Telemetry volume is spiky or intermittent rather than steady | Amazon OpenSearch Serverless, or SaaS usage-based pricing — provisioned OpenSearch is a poor fit either way |
| Integrated logs, metrics, traces and security in one product experience matter more than infrastructure control | Datadog |
| The real driver is uncontrolled Datadog usage growth rather than the platform itself | Neither — optimize first; see Should You Optimize Datadog or Migrate? A Decision Framework |
When an independent TCO review is worth commissioning
This comparison is worth a structured, evidence-based review — rather than a spreadsheet built in an afternoon — when the annual spend at stake is material, when the organization has never modeled OpenSearch's engineering cost explicitly, or when a Datadog renewal deadline is creating pressure to decide quickly without that evidence. An Observability Migration Assessment builds the workload baseline, prices both operating models against it using the categories above, and states plainly where the evidence is strong and where it depends on assumptions the organization still needs to validate — for example, whether the platform team can actually be staffed at the size the OpenSearch side of the model assumes.
FAQ
Not automatically, in either direction. Datadog's invoice includes most backend operations; a naive OpenSearch cost estimate usually excludes the engineering effort required to run a search cluster reliably. Once platform labor is added to the OpenSearch side and usage governance is accounted for on the Datadog side, the answer depends on telemetry volume, existing platform capability and operating model, not on which platform has a lower list price.
Platform engineering labor on the OpenSearch side. A cloud infrastructure estimate for compute and storage does not include the ongoing work of capacity planning, shard and index management, upgrades, snapshot and restore testing, and incident response for the search platform itself — costs that are already bundled into a Datadog SaaS contract.
No. Amazon OpenSearch Service provisioned domains remove node-level infrastructure operations but leave domain design, shard strategy and cost governance with the customer. Amazon OpenSearch Serverless bills through compute capacity units and managed storage rather than provisioned instances. Self-managed OpenSearch removes AWS's managed-service layer entirely and shifts the full operational surface to the internal team. These are three distinct cost curves, not one.
Public pricing is a reasonable starting point for understanding billing mechanics, but it is not a substitute for a workload-specific model. Datadog's actual bill depends on usage across several independently metered dimensions and the organization's contract; OpenSearch's actual cost depends heavily on the operating model chosen and the engineering capacity available to run it. Both numbers should be built from real usage and real staffing assumptions, not list prices alone.
Generally only after confirming that the Datadog cost driver is structural — genuine, sustained telemetry volume rather than avoidable configuration or governance gaps — and after the organization has priced the OpenSearch operating model's engineering requirement honestly, including whether that capability already exists internally. If avoidable Datadog consumption is the real driver, optimization typically produces a faster and lower-risk result than a platform migration.
Sources
- Datadog — Log Management, APM and Custom Metrics billing documentation (independently metered usage dimensions).
- AWS — Amazon OpenSearch Service pricing documentation (instance, OCU, storage, UltraWarm, cold storage, Extended Support charges).
- AWS — Amazon OpenSearch Service FAQs (data-transfer treatment, Serverless scale-to-zero behavior).
- AWS — Total cost of ownership guidance for Amazon OpenSearch Service (operational management, networking, backups and availability as TCO components, not only infrastructure or licensing).
Datadog and AWS pricing, packaging and billing mechanics change. Validate current figures against official Datadog and AWS documentation and the commercial terms applicable to your organization before building a renewal or migration business case.