Datadog vs Dynatrace: Architecture, Billing and OpenTelemetry Compared (2026)

If you're shortlisting Datadog and Dynatrace, you already know the basics. Both can monitor your hosts, trace your services and page you as you're about to sleep. Naturally, their feature lists overlap somewhat, so the useful comparison is how each one operates. Datadog is modular: you turn on products one at a time, and each product has its own meter on the bill. Dynatrace is integrated, with one agent, one topology model and one data store, paid for from a single commitment pool. Each fits some environments and teams better than others, and each puts your cost risk in a different place.

This comparison follows that split through collection, data storage, billing, OpenTelemetry (OTel), deployment and AI. By the end, you should be able to say which platform fits your environment and why, explain which meters drive each bill, name the features each vendor reserves for its own agent, and take a concrete checklist into a proof of concept.

Both vendors accept OpenTelemetry data on their own terms, and those terms decide how easily you could reverse the choice later.

Datadog vs Dynatrace at a glance

The table below shows the two operating models side by side. Product names are current as of October 2026. Both vendors renamed or relaunched several components this year, so check names against current documentation.

How each platform collects data

Dynatrace automates more at install time: one agent finds your processes and instruments them. Datadog asks you to make more choices, but lets you adopt one product at a time. Which one is easier depends on how much of the stack you're trying to cover on day one.

Datadog: the Agent and per-product enablement

The Datadog Agent is an open-source process that runs on each host and forwards metrics, logs, traces and events to Datadog's SaaS backend. It runs on Linux, Windows, macOS and AIX, as well as on Docker, Kubernetes, ECS, Cloud Run, Lambda and other platforms. Datadog recommends upgrading it at least monthly.

On Kubernetes, the recommended install goes through the Datadog Operator, which deploys a node Agent DaemonSet, a Cluster Agent and Cluster Checks Runners. Helm and a manual DaemonSet are the alternatives.

The Agent on its own gives you infrastructure monitoring. APM, log management, Real User Monitoring (RUM), Synthetics and the rest are separate products that you enable and pay for separately. For traces, you can either add the Datadog tracing library (dd-trace) to each service, or use Single Step Instrumentation, where the Agent injects the SDK into supported processes without code changes. Single Step Instrumentation disables itself on any service where it detects custom instrumentation, so Datadog tells you to remove hand-written instrumentation before you enable it.

Correlation across products depends on unified service tagging. Every signal needs consistent env, service and version tags. On Kubernetes, that means labels and environment variables on every workload, or injection by the Admission Controller. Keeping those tags consistent is the main ongoing configuration task on Datadog.

Dynatrace: OneAgent, ActiveGate and the Operator

OneAgent is a single installer per host that "discovers all the processes you have running" and "automatically activates instrumentation" for them. It supports Linux, Windows, AIX, Solaris and z/OS, plus Kubernetes, Docker and Cloud Foundry.

Each host runs in one of three monitoring modes:

• Full-Stack (the installer default) adds distributed tracing, code-level visibility and profiling.
• Infrastructure monitors the host without tracing or profiling.
• Foundation & Discovery covers host health and topology. It requires DPS licensing and OneAgent 1.281 or later.

ActiveGate is the second component. It proxies and routes traffic, and handles cloud monitoring, remote monitoring, synthetics and API access. SaaS environments usually need one for Kubernetes platform monitoring. The newer AWS and Azure cloud monitoring runs from Dynatrace SaaS without an ActiveGate.

On Kubernetes, the Dynatrace Operator starts with Kubernetes platform monitoring, and you can add one of two options on top: Application observability, which injects code modules into application pods only, with no OneAgent on the nodes and no host metrics, or Full-Stack observability. The option you choose also sets how you're billed, which matters later.

Which is easier to set up?

Third-party hands-on tests disagree. SigNoz and Better Stack found Dynatrace easier to get started with, while Datadog needed ddtrace and extra YAML configuration to collect logs. In SigNoz's test, OneAgent started monitoring both the Python application and its MongoDB database with nothing else installed, though SigNoz found OpenTelemetry setup simpler on Datadog. Sentrial reached the opposite conclusion, saying Datadog deploys in hours while Dynatrace needs more configuration up front.

Both can be true, because they measure different scopes. If your goal is full-stack coverage of a fleet of existing services, OneAgent's automatic injection does more of the work for you. If you want to start with infrastructure metrics or logs and add APM later, Datadog's one-product-at-a-time model has less to configure before you see value. Two more factors push in opposite directions. Dynatrace adds a choice of Operator option and the learning curve of DQL. Datadog's tagging discipline and choice of instrumentation path (Single Step, dd-trace, or OpenTelemetry) are decisions you have to get right for correlation to work.

Where the data lives and how you query it

Datadog exposes separate ingestion, indexing, retention and query controls for each product. Dynatrace puts all signals into one store, Grail, queried with one language, DQL, and connected by one topology model, Smartscape.

Datadog's per-product controls give you cost levers at every step. In APM, ingestion controls are separate from retention filters, and indexed spans are kept for 15 days. Logs come in three tiers: Standard Indexing, Flex Logs (which Datadog describes as "decoupling storage from compute costs") and Archives. For custom metrics, Metrics without Limits separates the custom metrics you ingest from the ones you index. That gives you control, but you have to decide, product by product, what to keep queryable, and cross-signal correlation only works as well as your tags.

Grail stores logs, metrics, traces and events together, and DQL queries all of them. Smartscape is a real-time dependency graph of your hosts, processes and services. Dynatrace calls the new Smartscape the recommended approach going forward, and classic topology remains supported alongside it.

If you evaluated Dynatrace a few years ago, the product has changed underneath you. Dynatrace now distinguishes Classic from "Latest Dynatrace", which is the Grail-based platform with AppEngine and AutomationEngine. Dynatrace calls Classic "entity-first" and Latest "data-first". In the Latest apps, Segments replace management zones, and auto-tagging rules have no effect on Smartscape on Grail or in any Latest app. Teams moving over have to rebuild those scoping rules and learn DQL. Dynatrace Intelligence can translate natural language into DQL to ease that. Dynatrace itself acknowledges that if you don't write queries every day, "the learning curve can feel steep".

Latest Dynatrace runs only as SaaS, on AWS, Azure and Google Cloud. Google Cloud regions are available on request.

How Datadog and Dynatrace bill

Datadog's bill is the sum of many independent meters, one or more per product, each with its own unit and allotments. Dynatrace's bill is one commitment pool that different kinds of usage draw down at different rates. Each model has its own surprise-bill triggers. This section explains the mechanics only. List prices change and negotiated contracts vary, so check current figures with each vendor.

Datadog: per-SKU meters

Each Datadog product has its own billing unit. Infrastructure is billed per host per month, APM per APM host, custom metrics per 100, RUM per 1,000 sessions, and Synthetics per 10,000 API test runs or per 1,000 browser test runs. Logs are billed per GB ingested, plus per million indexed events at the retention you choose, plus Flex storage. Annual commitments cost less than on-demand rates, and usage above your commitment is billed at on-demand rates. Log Management is the exception: log commitments are monthly, and log usage above the commitment is "charged with a 50% premium".

A few mechanics drive most of the variance:

• Host counting uses a high-water mark. Datadog counts hosts every hour and bills "the maximum count (high-water mark) of the lower 99 percent of usage". The top 1% of hours is excluded, which absorbs brief spikes. Because 1% of a 30-day month is about seven hours, a sustained autoscaling peak longer than that can start to raise your billable host count for the month. If you run an Agent per container, each container counts as a billable host.
• APM bills hosts and spans. APM is billed on "the ninth highest measurement" of hourly APM hosts on high-water-mark plans. Each APM host includes an allotment of ingested and indexed spans, and usage above that is billed per unit.
• Containers have their own meter. Each host includes a number of free containers, which varies by plan. Containers are metered every five minutes and averaged per hour.
• Custom metrics are billed by cardinality. Each unique combination of metric name and tag values is one billable custom metric, averaged over the month, with a per-host allotment. A distribution produces several custom metrics per tag combination, and enabling percentiles adds more. Metrics from OpenMetrics and Prometheus integrations are all custom metrics, and Datadog warns that wildcard configurations can have a "significant impact" on billing.
• Logs and spans have separate ingestion and indexing meters. Ingesting data and indexing it are billed separately, so a log line you ingest and index costs more than one you ingest and archive.

In June 2026, Datadog made Infinite Cardinality Metrics generally available. A metric is "priced by its metric name, not by the number of unique time series created by tag combinations", which Datadog says aligns cost with data volume rather than cardinality. If you're considering it, ask Datadog how it coexists with per-combination billing on your account and whether it applies to your OpenTelemetry metrics.

Dynatrace: the Dynatrace Platform Subscription

The Dynatrace Platform Subscription (DPS) is a minimum annual commitment over a one- to three-year term. Every capability draws down that commitment at the rates on a published rate card. Usage beyond the commitment is billed on demand at the same rates, with "no overage premiums".

The rate card has many dimensions, but they all draw from the same pool:

• Full-Stack hosts are billed per memory-GiB-hour. Infrastructure and Foundation hosts are billed per host-hour.
• Kubernetes Platform Monitoring is billed per pod-hour, and Code Monitoring per container-hour.
• Logs and traces have three meters: ingest per GiB, retain per GiB-day and query per GiB scanned.
• Metrics are billed for ingest per 100,000 data points and retention per GiB-day. Metric queries are included in the ingest price.
• RUM is billed per session, and Synthetics per action or request.
• AppSec, workflows, data egress, AppEngine functions and AI units are metered as well.

Full-Stack metering is where host size shows up on the bill. Memory is measured in 15-minute intervals and rounded up to the nearest 0.25 GiB, with a minimum of 4 GiB per host and 256 MiB per container. Each GiB includes an allotment of custom metric data points and trace volume, and profiling is included. Because the unit is memory, a large-memory host costs proportionally more to monitor than a small one. This can materially affect large-memory JVM workloads.

Metric ingest is counted per data point, and a histogram counts as 10 data points. Log retention can be set anywhere from 1 day to 10 years, and a "Retain with Included Queries" option bundles queries over recent data. Enrichment can increase the volume billed for ingest.

On Kubernetes, the Operator option determines what you pay for. Pod-hours on Full-Stack hosts are included. Application observability without Full-Stack bills both pod-hours and container GiB-hours.

You may still see Classic licensing in older documentation: host units based on memory, Davis Data Units (DDUs) and Digital Experience Monitoring (DEM) units. Latest Dynatrace features require DPS.

Which bill is harder to forecast?

Both are hard to forecast, for different reasons. On Datadog, the risk is spread across many meters that move independently. A new Kubernetes cluster raises host and container counts. A developer adding a user_id tag to a metric multiplies custom metric cardinality. A noisy service increases indexed log volume. None of these show up in the others, and each has its own allotment and overage rate. Practitioner reports and third-party pricing breakdowns commonly name custom metrics, log indexing and host or container growth as the sources of surprise bills.

On Dynatrace, there's one number to watch, the remaining commitment, but the meters that draw it down behave differently. Moving a workload onto larger-memory hosts raises Full-Stack consumption even if traffic stays the same. A new log source adds ingest, retain and query charges, and a dashboard that scans a lot of data adds query cost every time it runs. The commitment absorbs this until it runs out, at which point usage continues at on-demand rates. Third-party reviews describe this consumption model as hard to forecast too.

On both platforms, model your expected usage against the actual meters before signing, and set up the vendor's usage dashboards on day one of a trial.

OpenTelemetry on Datadog and Dynatrace

Both platforms ingest OpenTelemetry Protocol (OTLP) data, but each imposes its own transport, semantic and feature constraints. They transform or restrict OTel data on arrival and reserve some flagship features for their own agents or SDKs. They also bill OTel data differently. Instrumenting with OTel doesn't remove those differences, but it does keep your instrumentation portable, which makes the decision reversible.

How OTel data gets in

Datadog offers three paths:

1. The DDOT Collector, Datadog's distribution of the OpenTelemetry Collector, embedded in the Agent. Datadog labels it the recommended path. It supports bringing your own OTel components and Fleet Automation, and on Kubernetes it requires Kubernetes 1.29 or later. Datadog documents DDOT on Kubernetes (DaemonSet and gateway), Linux and Windows hosts, and ECS Fargate.
2. The upstream OpenTelemetry Collector with the Datadog exporter.
3. Agentless OTLP intake, generally available for traces, metrics and logs, with payload-size limits. Datadog positions it for serverless and resource-constrained environments rather than as a general alternative to the first two.

The Agent can also receive OTLP directly on ports 4317 (gRPC) and 4318 (HTTP), though OTLP ingestion in the Agent is off by default. Log ingestion in particular is "disabled by default to prevent unexpected logs billing." Datadog's own tracing SDKs also implement the OTel Traces, Metrics and Logs APIs, behind flags and minimum versions, so you can write OTel API calls and still use dd-trace underneath.

Dynatrace exposes an OTLP API at /api/v2/otlp/v1/{traces,metrics,logs}. It accepts only HTTP with binary protobuf. If your SDKs export over gRPC or JSON, you need a Collector in between to convert. Authentication uses a token with OpenPipeline ingest scopes. Dynatrace calls its own OTel Collector distribution "the preferred choice for most use cases". Each minor version is supported for three months, and the Operator can manage it.

OneAgent and OTel can also run together. OneAgent offers a local OTLP endpoint, and its OTel Span Sensor captures spans created with the OTel API in Java, Go, Node.js, PHP and .NET and treats them as OneAgent trace data. Running both routes for the same service duplicates spans. For most OTel use cases, Dynatrace recommends exporting directly over OTLP without OneAgent.

What happens to the data on arrival

Datadog maps OTel data onto its own model. Resource attributes become tags: service.name becomes service, deployment.environment.name becomes env (Agent 7.58 and later) and service.version becomes version. Kubernetes attributes are renamed too, so k8s.cluster.name becomes kube_cluster_name. Your OTel resource attributes have to cover what unified service tagging needs, because DD_* environment variables are "not supported out of the box in your OpenTelemetry configuration." Metric types are converted as well: cumulative monotonic sums become delta counts, and cumulative histograms become Datadog distributions. Delta histograms, which Datadog recommends, are ingested natively with their bucket structure preserved. Queries and dashboards then run against Datadog's representation of the data.

Dynatrace restricts which OTel metrics it accepts. Its metrics ingest has these limits:

• Only delta temporality is accepted. Cumulative counters and histograms are rejected. Most OTel SDKs default to cumulative, so you need to configure delta temporality in the SDK or convert in a Collector.
• Explicit-bucket histograms keep their buckets only if "Advanced OTLP metric dimensions" is enabled.
• Exponential histograms are accepted, but their buckets aren't kept.
• Summary metrics aren't supported.
• Dimension and request-size limits apply.

Trace ingest also has limits. Span end times must fall between 60 minutes in the past and 10 minutes in the future, and requests are capped at 8 MB.

On the topology side, Dynatrace's Service Detection v2 builds services from resource-attribute rules, using attributes such as service.name and Dynatrace's k8s.workload.name. That second attribute isn't an OpenTelemetry semantic convention: the Dynatrace Operator or Collector derives it from k8s.deployment.name and similar attributes, so don't set it in your SDKs. Since version 1.343, these rules detect services the same way across OpenTelemetry and OneAgent data for Kubernetes and AWS Lambda workloads. For OneAgent on other hosts, this is still in Early Access. Since 1.344, Smartscape can link OTel services to their hosts and processes, but only when the OpenTelemetry Host Monitoring extension is installed.

What OTel-only data can't reach

Both vendors reserve some features for their own agents. If your services are instrumented only with OpenTelemetry, check this list first.

On Datadog, availability depends on how the OTel data arrives, according to its compatibility matrix:

• Requires the Datadog SDK plus DDOT: App and API Protection, Continuous Profiler, Data Observability: Jobs Monitoring, RUM and source code integration.
• Requires DDOT (not available with the upstream Collector or agentless intake): Database Monitoring, Cloud Network Monitoring, Universal Service Monitoring, Live Containers and Live Processes.
• Not available with OTel at all: Data Streams Monitoring.

On Dynatrace:

• RUM (sessions, Core Web Vitals, Session Replay) still needs the Dynatrace RUM JavaScript or the mobile agent.
• Code-level visibility and profiling are Full-Stack OneAgent features.
• Smartscape host and process links for OTel services need the OpenTelemetry Host Monitoring extension.

In practice, both platforms will display OTel traces, metrics and logs. Datadog's profiling, database monitoring and network features, and Dynatrace's code-level analysis, assume you've installed their agent.

How OTel data is billed

On Datadog, the answer depends on where the metric comes from. Datadog says metrics from supported OpenTelemetry receivers come "at no extra cost", but "incorrectly configured receivers may cause metrics to be classified as custom." Under Datadog's general definition, metrics that don't come from a Datadog integration are custom metrics, so application metrics you define with an OTel SDK can be classified as custom and billed by cardinality. Cumulative OTel histograms arrive as distributions, and each distribution produces several custom metrics per tag combination. Datadog's billing docs don't say how natively ingested delta histograms are counted, so confirm that in your proof of concept. Either way, histogram-heavy instrumentation is worth testing before you commit.

On Dynatrace, OTLP metrics are billed per data point, and each histogram counts as 10 data points. OTLP traces from sources outside Full-Stack monitoring are billed per GiB ingested, with 10 days of retention included. Enrichment increases the billed size, so the GiB you send isn't necessarily the GiB you pay for.

Lock-in and switching cost

Each platform has its own lock-in points. On Datadog, they're dd-trace instrumentation, query syntax, monitors and dashboards. On Dynatrace, they're OneAgent, DQL, the Smartscape entity model and integrations built on the Dynatrace MCP Server. Dashboards, alerts and queries have to be rebuilt in any migration. Instrumentation is the expensive part, because it's spread across every service you own.

OpenTelemetry keeps that cost down. If your services emit clean OTLP through a Collector, changing exporters removes most of the application-instrumentation work. Queries, dashboards, backend-specific processing and the signal semantics a backend doesn't support still need migrating. You can also send the same data to both platforms during an evaluation or a migration. Teams already on Datadog can follow the Dash0 guide to migrating from Datadog to OpenTelemetry, which covers dual-shipping and mapping Datadog tags to OTel semantic conventions. The limit is the agent-only features listed above: the more you depend on them, the less OTel protects you from lock-in.

Dash0 Special Edition: OpenTelemetry For Dummies

This book shows you how to bring order and clarity to observability with OpenTelemetry.

Get the ebook free

Deployment, self-hosting and data residency

Datadog runs only as SaaS. BYOC Logs moves log storage into your environment, but the platform itself stays SaaS. Dynatrace offers a self-hosted option in Dynatrace Managed, but not with Grail or the AI features.

Datadog runs separate regional sites, including US1, US3, US5, EU1, AP1, AP2, UK1 and US1-FED, which is FedRAMP High. "Each site is completely independent, and you cannot share data across sites", so the site you pick determines where your data lives. BYOC Logs keeps log storage in your own AWS, Google Cloud or Azure account. Metrics, traces and the rest of the platform remain SaaS.

Dynatrace Managed is self-hosted and still receives monthly releases, with no end of life announced. But Grail and the agentic and generative AI features are not available on Managed, and the Latest Dynatrace experience is SaaS-only. If you need to self-host the whole stack, Dynatrace is the only one of the two that can do it, but you won't get the platform described in most of this article.

AI and root-cause analysis

Both vendors ship an AI layer, and each one builds on its own data model.

On Datadog, Watchdog provides anomaly detection and automated root-cause insights. Bits Investigation (formerly Bits AI SRE), generally available since December 2025, is an AI agent for incident investigation. At DASH 2026, Datadog previewed Bits Detection, Remediation and Memories. Because Datadog correlates signals through tags, these features work better when unified service tagging is consistent.

On Dynatrace, Dynatrace Intelligence is now the umbrella name for all of the platform's AI. It replaces Davis AI and Davis CoPilot and covers predictive, causal, generative and agentic AI. Dynatrace announced it at Perform in January 2026 as an "agentic operations system", alongside the new Smartscape, SRE and Developer agents, and the Dynatrace MCP Server. Its generative assistant, Dynatrace Assist, translates natural language into DQL. The causal analysis draws on the Smartscape topology, so how complete that topology is affects what it can find. These features are SaaS-only. You'll still see "Davis" and "CoPilot" in APIs, Swagger definitions, token scopes and Grail data, so expect both names when you configure access or automation.

No independent benchmark compares the root-cause accuracy of the two. Test them on your own incidents during a proof of concept.

Which should you choose?

Match the platform to your environment and team.

Cloud-native and Kubernetes-heavy teams. Both work well. Datadog suits teams that want to start small, add products as they go, and already have good tagging habits. Watch container and custom metric growth closely. Dynatrace suits teams that want Full-Stack coverage across many clusters with less per-service setup. Choose the Operator option carefully, because it determines your billing.

Large estates of legacy Java and .NET services. Dynatrace's automatic OneAgent injection and code-level visibility cover a fleet of existing services with the least instrumentation work. Keep in mind that memory-weighted Full-Stack metering can make large-memory JVM hosts comparatively expensive to monitor, so model that early.

Hybrid, regulated or self-hosted requirements. If you must run the backend yourself, Dynatrace Managed is the only option of the two, without Grail or the AI features. If SaaS in a specific region is acceptable, Datadog's isolated sites may be enough, and BYOC Logs keeps log storage, but only log storage, in your environment.

OpenTelemetry-first teams. Both platforms accept OTLP, and both will ask you to adapt. Dynatrace's OTLP endpoint accepts only HTTP/protobuf, its OTLP metrics ingest requires delta temporality, and it doesn't keep exponential-histogram buckets. Datadog maps your attributes and metric types to its own model and may classify application metrics as custom. On both, decide up front which agent-only features you need. If the answer is "none", run the fan-out test below, since your instrumentation can stay portable.

Teams that want product-by-product control of spend. Datadog's meters let you limit spend per product (index fewer logs, drop tag combinations), at the cost of managing many meters, and log usage above your commitment carries a 50% premium. Dynatrace's single commitment is simpler to buy and has no overage premium, but you need to understand which meters draw it down.

What to test in a proof of concept

Before you sign with either vendor, run both against the same workload. The most useful version sends the same OpenTelemetry data to both platforms through a single Collector that exports to each one, as described in Dash0's guide to choosing an OpenTelemetry backend. Then check:

1. Temporality. Send cumulative counters and histograms. Confirm that Datadog converts them as expected, and that the Dynatrace path converts them to delta before export, since cumulative data is rejected.
2. Histograms. Send explicit-bucket and exponential histograms, in both delta and cumulative temporality. Check whether bucket data survives on Dynatrace (with and without Advanced OTLP metric dimensions) and how many custom metrics each histogram produces on Datadog.
3. Resource attributes. Check that service.name, deployment.environment.name and k8s.* attributes produce the services, environments and tags you expect on Datadog, and the services and Smartscape links you expect on Dynatrace.
4. Billing classification. After a few days, check the usage pages. On Datadog, find which OTel metrics were counted as custom and at what cardinality. On Dynatrace, compare billed GiB and data points to what you sent, including the effect of enrichment.
5. Feature coverage. List the features you plan to use and confirm which ones populate from OTel-only data and which need the Datadog Agent and SDK or OneAgent.
6. Correlation. Follow one request from a trace to its logs and to the host metrics. Note how much configuration each platform needed to get there.
7. Growth scenarios. Ask each vendor to model your bill if hosts double, if a high-cardinality tag is added, and if log volume triples. On Dynatrace, include host memory size, and on Datadog, the high-water-mark host count.
8. AI on real incidents. Replay or wait for a real incident and compare what each AI layer finds.

Where Dash0 fits

If your team is standardizing on OpenTelemetry and doesn't want features tied to a proprietary agent, Dash0 is another option. Dash0 is OpenTelemetry-native: it ingests OTLP as its primary path and works with OTel resource attributes and semantic conventions directly. It's a newer platform than either incumbent, with a smaller integration catalog and a shorter enterprise track record. If you depend on specific integrations or established enterprise deployment patterns, validate those during your evaluation.

For a closer look, see Dash0 as a Datadog alternative and Dash0 as a Dynatrace alternative, or compare more vendors in Datadog vs New Relic, the best Datadog alternatives and the best Dynatrace alternatives.

FAQ

Can Dynatrace be self-hosted? Is Datadog SaaS-only?

Dynatrace Managed is a self-hosted option, but Grail and the AI features aren't available on it. Datadog runs only as SaaS, with isolated regional sites. BYOC Logs keeps log storage in your own cloud account while the rest of the platform stays SaaS.

Do Datadog and Dynatrace support OpenTelemetry?

Yes, both ingest OTLP traces, metrics and logs. Datadog maps OTel attributes and metric types onto its own model. Dynatrace's OTLP endpoint accepts only HTTP/protobuf, its metrics ingest accepts only delta temporality, and it doesn't keep exponential-histogram buckets. On both, some features still need the vendor's own agent or SDK.

Which is more expensive, Datadog or Dynatrace?

It depends on your workload, not on list prices. Datadog costs grow with hosts, containers, custom metric cardinality and indexed log and span volume. Dynatrace costs grow with host memory on Full-Stack monitoring and with ingest, retention and query volume, all drawn from one annual commitment. Model your own usage against both meter sets.

Can you use Datadog and Dynatrace together?

Yes. The simplest way is to send the same OpenTelemetry data to both through a Collector with one exporter per vendor. That's the usual way to evaluate both side by side or run a migration.

What's the difference between Watchdog and Davis?

Watchdog is Datadog's engine for anomaly detection and automated root-cause insights, and Bits Investigation (formerly Bits AI SRE) handles incident investigation. Davis was Dynatrace's AI engine. Dynatrace Intelligence has replaced the Davis AI and Davis CoPilot names as the umbrella for all of Dynatrace's AI, and its causal analysis works from the Smartscape topology. The Davis name survives in Dynatrace's APIs and scopes. Each vendor's AI is tied to its own platform's data model.

Final thoughts

Datadog gives you modular adoption and independent cost controls, and expects tagging discipline in return. Dynatrace gives you automatic instrumentation and a unified data model, and expects you to adopt OneAgent and DQL. Pick the one whose cost risk you can monitor, and instrument with OpenTelemetry where you can: it won't erase either platform's data-model, feature or billing differences, but it keeps your instrumentation portable so you can compare both fairly now and switch later.

If you'd like to see how an OpenTelemetry-native platform handles the same workload, try Dash0 free for 14 days, with no credit card required.