Datadog vs Splunk: Which Splunk, Which Bill, and What You Can Take With You

Before you can compare Datadog and Splunk, you need to know which Splunk you mean. For observability and logs, Splunk sells two separate backends: Splunk Observability Cloud for metrics, traces and real user monitoring (RUM), and Splunk Platform for log indexing, search and security. They have different capabilities and different pricing models, so the right comparison depends on what you're trying to monitor.

Cost is the second complication. List prices alone won't tell you what either platform will cost. Datadog charges across several product-specific meters, such as hosts, custom metrics, log volume and indexed events. Splunk Observability Cloud is sold per host with per-host entitlements, or on MTS- or TAPM-based plans, and Splunk Platform is licensed by ingest or by workload, with an activity-based option on Cloud Platform. What each vendor counts, and how it handles spikes and overages, shapes the bill more than the rate card does.

This article helps you do four things:

• Work out which Splunk product you're comparing against Datadog, and why it changes the answer.
• Name the billing units each vendor will meter for your workload, and the mechanics behind surprise bills on each side.
• Understand how each vendor accepts OpenTelemetry (OTel) data, and which parts of your setup you'd have to rebuild if you switched.
• Pick a default from a "choose X if…" list.

It doesn't include dollar figures, which go stale quickly and depend on your contract, or setup tutorials for either tool.

Datadog vs Splunk at a glance

The short version: for metrics, APM and RUM, you're choosing between Datadog and Splunk Observability Cloud, and your autoscaling pattern and custom metric volume usually decide it. For log-heavy and SIEM workloads, you're choosing between Datadog and Splunk Platform, where self-hosting, SPL and workload licensing are Splunk's strongest arguments. The full checklist is at the end.

Which Splunk are you comparing against?

Splunk's observability and log products run on two separate backends with separate pricing. Splunk Platform, sold as Splunk Enterprise (self-hosted) or Splunk Cloud Platform (SaaS), indexes and searches logs and is the foundation for Splunk Enterprise Security. Splunk Observability Cloud came from the 2019 SignalFx acquisition and stores metrics, traces, RUM and synthetics data, but not logs.

Logs stay in Splunk Platform even when you look at them from Observability Cloud. Log Observer Connect lets Observability Cloud display them, but it doesn't store or index anything, and it runs its searches on the Platform search head. Splunk no longer sells native log storage in Observability Cloud (Log Observer), so new customers use Log Observer Connect, which reads logs from Splunk Platform. If you want logs, metrics and traces from Splunk, you generally need both products, each with its own licensed entitlements.

That also answers a common question: is Splunk an observability tool or a SIEM? It's both, through different products. Observability Cloud covers observability, and Platform covers logs and SIEM.

Ownership is the other common source of confusion. Cisco completed its acquisition of Splunk on March 18, 2024, at about $28 billion in equity value, which is why Splunk was delisted. It now runs as a Cisco subsidiary and still sells both products, so nothing is "replacing" Splunk. The closest thing to a product change is on the APM side, where Cisco, which also owns AppDynamics, now ships a Combined Agent for Java, Node.js and .NET that can report to AppDynamics, to Splunk Observability Cloud or to both.

Fit by use case: observability, logs and SIEM

For metrics, application performance monitoring (APM) and RUM, compare Datadog with Splunk Observability Cloud. For log-heavy and SIEM workloads, compare Datadog Log Management and Cloud SIEM with Splunk Platform. If you want both from Splunk, you buy and run two products. Datadog is one integrated platform, but each product is priced separately with its own billing unit.

So "Is Datadog better than Splunk?" splits into two narrower questions, and each has a different answer.

Metrics, APM and RUM

Here the comparison is Datadog against Splunk Observability Cloud. Both are SaaS and both price their core around hosts.

Datadog packages Infrastructure, APM, RUM (with Session Replay as an add-on), Synthetics, Continuous Profiler and Database Monitoring as separate products. Splunk Observability Cloud packages them into editions:

• Infrastructure: Infrastructure Monitoring, Log Observer Connect, Network Explorer and Synthetic uptime checks.
• App & Infra: adds APM with AlwaysOn Profiling and Synthetic API tests.
• End-to-End: adds RUM and Synthetic browser tests.

Database Monitoring and Secure Application are add-ons.

The differences that most affect cost are how each vendor counts hosts during a spike, what it counts as a custom metric, and what happens when you exceed an allotment. The billing section covers each one.

On traces, Splunk says its APM ingests and analyzes 100% of traces, which it calls "NoSample" full-fidelity tracing. The "NoSample" name comes from Splunk's marketing, but its APM docs also say it collects every span. Splunk's APM billing docs describe throttled spans, so "100%" applies within your trace volume entitlement. Splunk Observability Cloud keeps raw traces for 8 days by default (extendable to 15 or 30), metrics at 1-minute resolution or coarser for 13 months, and RUM sessions and spans for 8 days, according to its data retention docs.

Logs

Here the comparison is Datadog Log Management against Splunk Platform, and the two take different approaches. Datadog separates ingesting a log from indexing it. Splunk indexes what you ingest and extracts most fields when you search. Because log handling drives so much of the cost on both sides, it gets its own section below.

SIEM

Splunk Enterprise Security (ES) runs on Splunk Platform and can use the same indexed data, but it's a separately licensed premium product that requires an underlying Platform license. Like the rest of the Platform, it's quote-only and priced by activity, workload or ingest. Datadog lists Cloud SIEM per million analyzed events. Because Datadog runs detection on ingested logs, Cloud SIEM doesn't require logs to be indexed, so detection can cover logs you've chosen not to keep in a searchable index.

This article compares SIEM at the fit and billing-unit level only. Detection content, SOAR and compliance need their own evaluation.

How telemetry gets in: agents, collectors and deployment

Datadog collects through its own Agent and dd-trace SDKs into one SaaS platform. Splunk uses its OTel Collector distribution for Observability Cloud and forwarders or HEC for Platform. Of the three products, only Splunk Enterprise can be fully self-hosted.

The Datadog Agent collects host metrics, receives custom metrics through its DogStatsD server, and runs a trace agent that's on by default. Applications are instrumented with Datadog's dd-trace SDKs. Datadog also supports OpenTelemetry, covered below, but it says using the OTel API with its own SDK gives access to more Datadog features than the OTel SDK alone. Everything lands in Datadog's SaaS platform in one of its regional sites, including US government sites.

Datadog has no self-hosted product except for logs. BYOC Logs (formerly CloudPrem), announced in June 2025, moves log indexing and search onto your own infrastructure and object storage. It covers logs only, can't be queried together with other indexes, and doesn't work with Flex Logs. You activate it through your Datadog account team, and Datadog hasn't published pricing for it.

Splunk Observability Cloud's primary agent is the Splunk Distribution of the OpenTelemetry Collector. The older SignalFx Smart Agent reached end of support on June 30, 2023. In its default configuration, the Collector sends traces to a realm-specific ingest endpoint over OTLP and metrics through the SignalFx exporter.

Splunk Platform takes data from Universal Forwarders, Heavy Forwarders and HEC. Indexers store the data, and search heads distribute searches across them. With SmartStore, warm data sits in object storage with a local cache. You can run all of this yourself as Splunk Enterprise, or use Splunk Cloud Platform as SaaS. For teams that need to keep log data in their own data center, Enterprise is the only fully self-hosted option among the three products.

How each vendor bills: the units that drive cost

Each vendor meters different units, and most surprise bills come from a few specific mechanics. On Datadog, those are the host high-water mark and custom metric cardinality. On Splunk Platform, they're the license and workload model. On Splunk Observability Cloud, they're per-host entitlements and the overage terms. All of the details below describe standard plans; your contract's terms take precedence.

A useful way to read any of these models comes from Dash0's guide to choosing an OpenTelemetry backend: ask exactly what the vendor counts, count how many billing dimensions move together when traffic grows, and project the bill at 2x, 5x and 10x your current volume.

Datadog

Datadog bills each product in its own unit. Infrastructure, APM, Database Monitoring and Continuous Profiler are billed per host, containers per container, custom metrics per timeseries, logs per GB ingested and per million events indexed, RUM per 1,000 sessions, and Synthetics per test run. Annual, month-to-month and on-demand billing use the same units at different rates. A team using five Datadog products has five meters running, each with its own allotments.

Hosts use a high-water mark. Datadog meters hosts every hour, drops the top 1% of hours, and bills the highest remaining count (the 99th percentile). The APM billing page describes the same rule as the "ninth-highest" hour. In practice, a spike that lasts more than 8 hours in a month (7 in February) sets your host count for the whole month. If your fleet autoscales, this is the first number to model. Datadog also offers a hybrid plan, with a monthly commitment and hourly billing above it, which changes how spikes are charged. If you run the Agent inside each container rather than once per node, each container is billed as a host.

Containers come with an allotment. Infrastructure Pro includes 5 containers per host and Enterprise includes 10, averaged across your infrastructure. Containers are metered every 5 minutes, and anything above the allotment is billed per container-hour unless you prepay.

Custom metrics are counted by cardinality. Datadog defines a custom metric as a unique combination of metric name and tag values, including the host tag. The bill uses the monthly average of distinct timeseries per hour. How often you submit or query a metric doesn't matter, but every new tag value creates a new timeseries. Pro includes 100 custom metrics per host and Enterprise 200, pooled across hosts. Overage is billed per 100 metrics. Histograms count as 5 timeseries per tag combination, and distributions count as 5, or 10 with percentiles enabled. Metrics without Limits lets you allowlist or blocklist tags to reduce the indexed count, but configured metrics are then billed on both ingested and indexed volume. Datadog also offers an opt-in Metric Name pricing model, billed per metric name plus datapoint volume.

APM includes span allotments. Each APM host includes a pooled amount of ingested and indexed spans. Extra ingested spans are billed per GB and extra indexed spans per million, priced by retention period.

Logs are billed at ingest and again at indexing. Ingest is billed per GB, and Standard indexing per million events, priced by retention. Flex Logs is billed per million events stored plus compute per instance-hour. Rehydration from archives is billed per GB scanned. Log usage above your commitment carries a 50% premium on the excess, though ingest has no on-demand premium.

Splunk Platform

Splunk has four pricing model families, and three of them apply to Splunk Platform:

• Ingest: GB per day.
• Workload: Splunk Virtual Compute units (SVCs), which bundle compute, memory and I/O, on Splunk Cloud Platform, and vCPUs on Splunk Enterprise.
• Activity: a dual meter on both ingest and search. It's Cloud-only, and Splunk doesn't disclose the units.

The fourth, entity pricing by host, container or protected device, applies to Splunk Observability Cloud and AppDynamics, not to Platform.

Splunk Cloud Platform subscriptions are workload-based by default and ingest-based only by exception. Workload plans don't meter ingest at all, and you buy storage separately. That changes what you optimize. On a workload plan, heavy or inefficient searches drive cost more than raw log volume does. Ingest plans include SVCs in proportion to your daily volume and allow you to exceed that volume at most 5 times per calendar month.

Splunk Enterprise enforces its license by disabling search. On stacks licensed below 100 GB/day, 45 license warnings in a rolling 60-day window turn off search, including scheduled searches and alerts. Indexing continues, but you need a reset license from Splunk Sales to search again. Stacks of 100 GB/day or more get warnings only, and vCPU licenses don't currently trigger violations. If your alerts run on Splunk Enterprise, a sustained log spike is an availability risk as well as a cost one.

Splunk Observability Cloud

Splunk Observability Cloud is priced per host per month, billed annually, across the three editions. MTS-based and TAPM-based (traces analyzed per minute) plans also exist. Each host comes with entitlements, and those entitlements set your real limits. Their size depends on your entitlement tier, Standard or Enterprise, which is set in your contract.

• Custom metrics: Standard includes 100 MTS per host and Enterprise 200. On MTS-based plans, every MTS counts as custom. Default metrics from the Collector and its out-of-the-box receivers count as host or container metrics, and anything you configure beyond the defaults is billed as custom MTS.
• Histograms: each histogram data point is billed as 8 MTS.
• Archived metrics: metrics you route to archive with Metrics Pipeline Management count at one-tenth of real-time MTS.
• APM: each host includes a trace volume (in MB per minute) and MetricSet cardinality entitlements.
• Containers: 10 per host on Standard, 20 on Enterprise.

Splunk's pricing-models page says entity pricing "allows unlimited data ingestion for defined entities," but these per-host entitlements, set out in its docs and legal terms, cap MTS, trace volume and containers. Check the entitlement terms in your contract before relying on that description.

On host-based subscriptions, Splunk measures infrastructure usage hourly and APM usage per minute, then bills the monthly average. A short autoscaling spike therefore moves the bill much less than it does under Datadog's high-water mark.

Exceeding an entitlement is a contractual risk as much as a pricing one. Splunk's entitlement terms allow it to bill usage above your entitlement at 150% of the effective list price, and to limit your ability to add new monitors when usage spikes. Read how your own contract applies these terms, and track entitlement usage so you see an overrun coming.

RUM is billed per session, using the same 15-minute inactivity and 4-hour maximum session rule as Datadog. Synthetics is billed per browser, API or uptime run. Logs viewed through Log Observer Connect cost nothing extra in Observability Cloud, but they're billed under your separate Splunk Platform entitlement.

Published vs quote-only pricing

Datadog publishes list prices for nearly every product, although a few, such as Flex Logs compute and indexed custom metric overage, are "specified in your current contract" or available only from sales. Splunk Observability Cloud publishes "starting at" prices for its editions. Splunk Platform, Enterprise Security, SOAR and ITSI are quote-only. On the log and SIEM side, you can't model Splunk's cost from public numbers alone, though you can still model the units.

Mapping one workload to each vendor's units

The table below maps one example workload to the units each vendor would meter. It shows units only, not prices, and it's a model of what gets counted, not an invoice forecast.

The example workload:

• 50 hosts, scaling to 80 for 10 hours during a 30-day month
• 400 containers
• 20,000 custom metric series (unique name and tag combinations), plus 200 histogram series
• 100 GB/day of logs, at an average of about 1 KB per log event
• 500,000 RUM sessions a month

The assumptions:

• Datadog: Infrastructure Pro allotments on the high-water-mark host plan, not the hybrid plan.
• Splunk Observability Cloud: End-to-End edition, Standard tier, on a host-based subscription.
• Datadog histograms: sent as cumulative OTel histograms through the Agent or a Collector exporter, which map to distributions at 5 timeseries each by default. Delta histograms, and histograms sent to the agentless OTLP endpoint, are stored natively, so confirm how Datadog bills them.
• Allotments: calculated at the 50-host baseline, because the extra 30 hosts run for only 10 of the month's 720 hours. Datadog bills hosts at the high-water mark but measures containers and custom metrics as averages, so confirm with Datadog how your contract applies allotments. If they're based on the 80 billed hosts, Datadog's included containers rise to 400 and included custom metrics to 8,000.

Under these assumptions, the same autoscaling pattern adds 30 billed hosts on Datadog and only about 0.4 hosts to the monthly average on Splunk Observability Cloud. Custom metric overage is similar in volume on both sides, but the histogram multipliers differ (5 vs 8), and Splunk's overage falls under its 150% entitlement terms. Logs are where the two Splunk products split. Observability Cloud doesn't store them, so they need a Platform entitlement whose cost depends on whether you're on an ingest or a workload plan.

To use the table for your own workload, replace each number with your own and check which tier you'd buy, because the Enterprise tiers of Datadog Infrastructure and Splunk Observability Cloud double the per-host container and custom metric allotments. Then rerun it at 2x and 5x your current volume to see which line grows fastest.

Controlling volume before it is billed

Both vendors sell pipelines that filter, sample or route data before it reaches a billing meter.

Datadog Observability Pipelines runs a Worker, based on the open source Vector project, in your infrastructure, with the control plane hosted by Datadog. It can send data to Datadog, S3, Splunk or Microsoft Sentinel, and it's sold separately, per GB or per vCPU. Inside Datadog, index exclusion filters and Metrics without Limits do a similar job for logs and metrics after ingest.

On the Splunk side, Edge Processor (customer-hosted) and Ingest Processor (Splunk-hosted, Cloud only) are pipelines written in SPL2. Ingest Processor can route data to Splunk Platform, Observability Cloud, S3 or Azure. Ingest Actions can also filter, mask and route data on Heavy Forwarders or in Splunk Cloud. On Observability Cloud, Metrics Pipeline Management lets you archive metrics at one-tenth of the real-time MTS rate.

Logs: indexing, retention and query languages

Datadog separates ingest from indexing and offers Flex Logs and rehydration from archives. Splunk extracts fields at search time and tiers storage through DDAS, DDAA and DDSS. SPL provides richer query-time transformation and aggregation than Datadog's log search syntax, which is closer to Lucene.

Datadog calls its model Logging without Limits. Every ingested log can go through pipelines, archives, log-based metrics and Cloud SIEM, whether or not you index it. Indexes then decide what becomes searchable, using filters, exclusion filters with sampling, and daily quotas. Excluded logs still reach Live Tail, archives and metrics. That lets you pay to ingest everything but index only what you search. Log-based metrics count against your custom metric allotment. On-demand customers get 15-day retention by default.

For longer retention, Datadog has two options:

• Flex Logs bills storage and compute separately on its scalable compute tiers, which retain logs for 30 to 450 days. Flex Logs Starter bundles both at one rate, with 3- to 15-month retention. Monitors and Watchdog don't run on Flex. Dashboard queries consume compute, and queries slow down or fail when you run out. The larger compute tiers aren't available on every Datadog site.
• Archives sit in your own S3, Azure or GCS bucket. Rehydration is billed on the total archive volume scanned, not on the logs that match, and you're still billed if you cancel. Datadog now recommends Archive Search for accessing archived logs, and it has announced Flex Frozen, a managed tier for retention of around seven years.

Splunk Platform indexes what you send and extracts most fields at search time, which Splunk recommends. In effect, you can define new fields after the data has arrived without reindexing. Splunk Cloud Platform tiers storage as follows:

• DDAS is searchable storage.
• DDAA is a Splunk-managed archive with retention up to 10 years. Restored data becomes searchable within 24 hours, and stays available for up to 30 days. Your DDAA subscription includes an additional 10% of searchable (DDAS) capacity for restored data.
• DDSS exports data to your own bucket, where Splunk can no longer search it.

The query languages are the bigger day-to-day difference. SPL pipes search results through commands that filter, transform and aggregate them, so a single query can go from raw events to a report. Datadog's log search syntax is a Lucene-like filter language built on facets and attributes, not SQL. For how SPL compares with other log tools, see Dash0's Graylog alternatives comparison.

A search for server errors in SPL:

1
index=web status=500 | stats count by host

A similar filter in Datadog's log search syntax:

1
service:web @http.status_code:500

In Datadog, you'd group the result by host in the Log Explorer rather than in the query. Teams that have built years of saved searches, reports and alerts in SPL should treat rewriting them as part of any move away from Splunk Platform.

OpenTelemetry support

Datadog accepts OTel data in four ways, and each has feature gaps compared with its own Agent and SDKs. Splunk is Collector-first, but OTel logs go to Splunk Platform, not Observability Cloud.

Datadog's four OTel paths are:

1. DDOT, the Datadog Distribution of the OTel Collector. It ships inside Agent v7.65 and later and is Datadog's recommended path.
2. OTLP ingest in the Agent on ports 4317 and 4318. Logs are off by default "to prevent unexpected logs billing."
3. The upstream OTel Collector. Datadog recommends the standard OTLP HTTP exporter for new setups; the Datadog Exporter remains supported.
4. Agentless OTLP intake, sent straight to Datadog with no Agent or Collector. Datadog announced it as generally available for metrics, logs and traces in July 2026. The metrics endpoint accepts delta temporality only, and the traces endpoint doesn't accept gRPC.

The gaps depend on the path. With the OTel SDK instead of dd-trace, Datadog doesn't support Continuous Profiler, RUM, App and API Protection, Jobs Monitoring or source code integration. The upstream Collector path also loses Database Monitoring, Cloud Network Monitoring, Live Containers, Live Processes and Universal Service Monitoring. Agentless intake has no host list or Kubernetes views. And running the Collector on EKS Fargate, in Datadog's words, "will result in incorrect infrastructure host billing."

Metric conversion matters for cost too. Datadog converts cumulative monotonic sums to deltas and drops the first point. On the Agent and Collector exporter paths, cumulative OTel histograms map to distributions by default, which count as 5 timeseries each. Delta histograms, and all histograms sent to the agentless endpoint since September 2026, are stored natively with their bucket structure, and Datadog doesn't document how they're billed, so check your Usage page.

Do OTel metrics cost more in Datadog? Datadog doesn't say so directly on any page. But it counts as custom any metric that doesn't come from one of its 1,000+ integrations, and OTel attributes become tags, which drive cardinality. By that definition, metrics from your OTel-instrumented applications would be billed as custom metrics. That's an inference from Datadog's own definition, not a documented rule. Datadog does say the extra metrics its OTel mapping creates don't affect billing. Check your Usage page after a trial before you commit to a volume.

Splunk's model is simpler. The Splunk Distribution of the OTel Collector is the primary agent for Observability Cloud, and recent releases have dropped the bundled collectd and Python runtime. Metrics still go through the SignalFx exporter by default. Trace support in that exporter is deprecated and scheduled for removal in December 2026, and the default config sends traces over OTLP. Splunk publishes OTel distributions for Java, Node.js, .NET, Python and Go (the Go one is code-based), and documents upstream OpenTelemetry instrumentation for PHP and Ruby (its own Ruby distribution reached end of support in March 2025). For zero-code Go instrumentation, Splunk points to eBPF-based OBI, which is in beta. If you're migrating from the SignalFx Java agent to Splunk OTel Java, expect span names and attributes to change, which affects existing dashboards and detectors.

Logs work differently. Observability Cloud doesn't accept OTLP logs. The Collector sends them to Splunk Platform through the splunk_hec exporter or the Splunk Connect for OTLP add-on, and they count against your Platform license. A full OTel setup on Splunk, with logs included, therefore touches both products and both sets of entitlements.

Dash0 Special Edition: OpenTelemetry For Dummies

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

Get the ebook free

What's portable and what isn't

OpenTelemetry makes your instrumentation portable, which lowers the cost of getting started with either vendor. Dashboards, queries, alerts and billing assumptions stay behind, so OTel does much less to lower the cost of leaving.

With OTel SDKs and a Collector, switching backends doesn't mean re-instrumenting your applications. Your application code and semantic conventions come with you. The Collector configuration still needs work: exporters and authentication change, and so can vendor-specific processors, resource attribute mappings and filtering rules. That portability is still the main reason to instrument with OTel even if you plan to stay on one vendor.

What doesn't move:

• Queries. SPL, SignalFlow and Datadog's query syntax are all vendor-specific. Every saved search, chart and report needs rewriting.
• Dashboards and alerts. Datadog monitors, Splunk Observability Cloud detectors and Splunk Platform alerts have no common export format, and each depends on that vendor's queries.
• Billing assumptions. The tagging and sampling decisions you made to manage Datadog's custom metric cardinality or Splunk's MTS entitlements were made for that vendor's meter. They may not make sense for the next one.
• Vendor-specific features. Anything that depends on dd-trace or Splunk's own agents, such as Datadog's profiler or RUM, needs replacing.

We found no public data on how often teams move from Splunk Cloud to Datadog or back. But the work involved is mostly in this list, not in re-instrumentation. If you're moving off Datadog, Dash0's guide to migrating from Datadog to OpenTelemetry covers dual-shipping during the transition. Dash0's OpenTelemetry backend guide has a broader checklist for judging how locked in a backend makes you. A practical test before you sign with either vendor is to ask whether you could leave within a month, and what you would have to rebuild.

Datadog or Splunk: how to choose

Start with your main use case, then check deployment needs, how well you tolerate billing variability, and what you already run.

Choose Datadog if:

• You want metrics, APM, RUM and logs on one platform, and you're comfortable managing a separate meter for each product.
• Your host count is stable, or you can model the high-water mark against your autoscaling pattern.
• You want to separate log ingest from log indexing, keeping everything for pipelines, metrics and SIEM while indexing only what you search.
• You can control custom metric cardinality through tagging discipline or Metrics without Limits.

Choose Splunk Observability Cloud if:

• Your main need is metrics, APM and RUM, and you prefer an agent built on the OTel Collector.
• Your fleet autoscales in bursts, and monthly averaging suits you better than a high-water mark.
• You want edition-based packaging with published starting prices, and you'll watch per-host entitlements closely to stay clear of the overage terms.
• You already run Splunk Platform for logs, or you're willing to, since Observability Cloud no longer offers log storage to new customers.

Choose Splunk Platform if:

• Your workload is log-heavy or SIEM-driven, and SPL's analytics depth matters to your team.
• You need a fully self-hosted platform. Splunk Enterprise offers that; Datadog's closest option, BYOC Logs, runs log storage and search in your own infrastructure but still uses Datadog's SaaS UI.
• You already have a large investment in SPL searches, dashboards and Enterprise Security content.
• Your search patterns suit a workload (SVC or vCPU) license better than paying per GB ingested, and you can work with quote-only pricing.

If you need both observability and logs and you're leaning toward Splunk, plan for two products, two sets of entitlements and two query languages. If you're weighing Splunk Observability Cloud against other options besides Datadog, see Dash0's Splunk Observability Cloud alternatives.

Final thoughts

Datadog vs Splunk becomes a manageable decision once you know which Splunk product you're comparing. From there, model the bill in the units each vendor counts, such as peak hosts, timeseries, indexed events or SVCs, at today's volume and at several times it, and read the entitlement and overage terms in the contract rather than the pricing page. Treat OpenTelemetry as a way in, not a way out. It keeps your instrumentation portable, but your queries, dashboards, alerts and billing assumptions still belong to whichever vendor you choose.

If you want to see how an OpenTelemetry-native platform handles the same telemetry, try Dash0 free for 14 days. No credit card required.