Datadog vs Splunk - Where Per-Host Prices and Billing Structures Differ

Why the Comparison Target Is Narrowed to Splunk Observability Cloud

The biggest reason Splunk-versus-Datadog comparisons fail to connect is that "Splunk" refers to two product families. One is the data platform consisting of Splunk Enterprise and Splunk Cloud Platform, whose main battleground is log search and SIEM, and which is positioned as a product usable in hybrid environments including on-premises and data centers (as of September 2026, Source: Splunk Enterprise). The other is Splunk Observability Cloud, a SaaS that bundles infrastructure monitoring, APM, RUM, and synthetic monitoring. The former's pricing is based on ingest volume or search compute resources (Workload Pricing), there is no unit price table on the pricing page, and quotes are obtained via "Contact Us" (Source: Splunk Pricing FAQs). Since unpublished unit prices cannot be compared by guesswork, this article does not treat any amounts for the log product. What is compared is Splunk Observability Cloud, whose pricing page explicitly states per-host prices, and Datadog, which likewise publishes per-host prices. To state the conclusion first: within the range of infrastructure + APM, Datadog's way of stacking, adding the SKU only to the hosts that need APM, has a structure that makes it easier to hold down the bill than a package type that moves every host up to a tier that includes APM, while for organizations already collecting logs in Splunk Platform, the Splunk side has a practical benefit in that Observability Cloud can connect to those log assets. Which is the better deal is determined by "where your logs live": that is the backbone of this article.

The Difference in Billing Structure - Tiered Packages vs SKU Stacking

Splunk Observability Cloud's pricing page is built as tiered packages of per-host prices. As of September 2026 there are three tiers, Infrastructure, App & Infrastructure, and End-to-End, each shown as a monthly amount per host (annual contract, labeled "Starts at"). Infrastructure includes, in addition to infrastructure monitoring, Log Observer Connect, Network Explorer, Synthetic Uptime Monitoring, and Incident Intelligence, and App & Infrastructure adds APM (including Always On Profiling). End-to-End is the top tier, extending to Database Monitoring (Source: Splunk Observability Cloud Pricing). The same page also lists standalone prices, and APM alone is likewise shown as a monthly amount per host. Datadog, by contrast, is SKU stacking. As of August 2026, Infrastructure Monitoring is a per-host monthly amount in two tiers, Pro and Enterprise; adding APM adds a per-host APM unit price (APM Enterprise including Continuous Profiler is a separate unit price), and logs and network monitoring are added as separate SKUs only in the amounts needed (Source: Datadog Pricing).

The structural difference shows up in the shape of the invoice. With Splunk, the monthly amount is almost entirely determined by host count x package unit price, and the pricing page promotes "predictable pricing with no unexpected overages based on peak usage". With Datadog, a portion proportional to log and span volume sits on top of host count x base unit price, so an estimate requires measuring volume. The split is: predictability to Splunk, the freedom not to buy what you do not need to Datadog.

Line Items That Can Be Compared Side by Side, and Those That Cannot Be Converted Because the Units Differ

The only line items that line up one to one on published prices are the per-host ones. The table below is a correspondence table of line items that can be mapped per host, and for Datadog it shows the combination that reaches an equivalent range. Fill in the actual amounts from each vendor's pricing page, aligned on the same unit (1 host / month / annual contract).

On the other hand, let us also be clear about the line items that cannot be converted because the unit systems differ. For logs, the Splunk side depends on the Platform license (unit price unpublished), and the Datadog side is on 2 axes, GB ingested and number of events indexed (unit price by retention period), so there is no basis for lining up numbers. For synthetic monitoring, Splunk counts uptime requests and Datadog counts API test runs; both are billed per run, but uptime requests and API tests verify different things, so they cannot be placed in the same row. Database Monitoring is included in Splunk's End-to-End package, while in Datadog it is a separate SKU billed as a monthly amount per database host, so the included / not-included structure differs. This article explains how billing works. For current unit prices and plans, refer to each vendor's official pricing page.

Where Splunk Wins: Log Assets, Full-Fidelity Traces, and Price Predictability

Here are three points where the Splunk side has a clear practical benefit. First, existing log assets. For organizations operating Splunk Platform as their SIEM or log search foundation, the fact that Observability Cloud's Log Observer Connect is designed to connect to the logs on that Splunk and reference them from the monitoring screens is a direct practical benefit (as of September 2026, Source: Splunk Observability Cloud Pricing). Being able to correlate within the scope of the existing license without ingesting logs twice is a big difference in both cost and operations for a log-centric organization. Second, the handling of traces: Splunk APM promotes "NoSample full-fidelity trace ingest", that is, ingesting everything without sampling, as a product feature, and AlwaysOn continuous profiling is also included in the APM unit price. Datadog's APM measures ingested spans in GB (an allotment of 150 GB per APM host per month) and is designed to index the spans to retain using retention filters, so for the use case of "keeping everything for a long time", the Splunk side's design is more straightforward. Third, price predictability: the monthly amount is almost entirely determined by host count x package unit price, and the pricing page puts the absence of overage charges front and center. Datadog's volume-proportional portion has the aspect of moving the bill significantly depending on usage (which is why usage monitoring becomes essential), and on this point Splunk's design is easier to explain to executives. In addition, having the Splunk Enterprise product family for hybrid environments including on-premises means a wider range of options for organizations that cannot send data outside.

Where Datadog Pays Off: Starting with Only the SKUs You Need at Published Prices

Datadog's strength lies not so much in the line-up in the table above as in the structure that produces a difference in that line-up. First is the freedom to "buy only what you need". In an environment where only 20 out of 200 hosts need APM, Datadog lets you add the APM SKU for just those 20 hosts, and the remaining 180 stay on Infrastructure Monitoring Pro as they are. With the package type, the unit at which you move up to a tier that includes APM becomes the issue, and as the "Starts at" wording on the pricing page indicates, the detailed conditions are left to individual quotes. Second is price transparency. Datadog publishes 3 prices, annual contract / monthly contract / on-demand, and you can start with credit card payment (as of September 2026, Source: Credit Card Billing) or try the free plan (up to 5 hosts). Splunk's pricing FAQ explicitly states that, as of September 2026, the availability of per-host Entity Pricing is limited to "commercial organizations in the Americas", so for organizations in Japan the premise is an inquiry-based quote (Source: Splunk Pricing FAQs). It is the Datadog side that makes it easier for an organization in Japan to proceed by "first trying 10 hosts for a month and taking measurements". Third, Infrastructure Monitoring, APM, and Log Management share the same tags and the same screens within a single product from the start. The correlation that the Splunk side achieves by connecting two products, Observability Cloud and Splunk Platform, is completed in Datadog within one invoice and one UI. For organizations that can decide fresh where their logs live, that is, organizations without an existing Splunk license, this unity translates directly into lower operational cost.

Log-Centric or APM-Centric - The Four Variables That Decide the Cost Advantage

With the material so far, we organize the conditions for the flip into variables. Written as a formula, the monthly amount on the Splunk side is "number of APM target hosts x App & Infrastructure unit price + number of remaining hosts x Infrastructure unit price", and on the Datadog side it is "total host count x Infrastructure Monitoring Pro unit price + number of APM target hosts x APM unit price + ingested GB x ingestion unit price + number of indexed events x indexing unit price" (put in the annual contract values from each vendor's pricing page; the Splunk Platform log license is not included in the formula). Looking at the formulas, the variables that move which side comes out lower narrow down to four.

The fork the variables show is clear. If the log volume is small, or if the design places logs somewhere other than Datadog (such as an S3 archive), Datadog's way of stacking, which lets you narrow the APM targets, takes effect and Datadog tends to come out lower. Conversely, for an organization whose logs reach several TB per month and which already has those logs in Splunk Platform, log costs arise anew only on the side moving to Datadog, so the total can come in lower on the Splunk side. What matters here is that in a log-centric environment, what pushes up the Datadog bill is the indexing cost rather than ingestion. Because Datadog is designed to bill ingestion and indexing separately, you can narrow the proportion of ingested logs that get indexed. Lower the indexing rate, and even in a log-centric environment the Datadog total falls by that much. In other words, "Splunk if log-centric" is a conclusion that holds under the assumption of indexing all logs in Datadog, and once index design is factored in, the break-even point moves substantially. To get the answer for your own environment, it is enough to put the measured values of the four variables and the unit prices from each vendor's pricing page into the formulas above. How to read the pricing as a whole is covered in How to Decode the Pricing Structure.

Migrate or Run Both - The Practical Answer of the Splunk Integration and OpenTelemetry

When an organization using Splunk considers Datadog, there is no need to choose replacement right away. There are three realistic stages. The first stage is running both: Datadog provides a Splunk integration that sends reports (alerts) created on the Splunk side to Datadog as events, where they can be correlated with other metrics and shared with the team. The setup takes the form of installing the datadog Python library on the Splunk server (as of September 2026, Source: Splunk Integration). This makes a division of labor of "log search in Splunk, metrics and APM in Datadog, notifications consolidated in Datadog" work. The second stage is standardizing instrumentation: both promote OpenTelemetry data ingestion (Splunk-side source: Splunk Observability). If you write your application instrumentation in OpenTelemetry, the cost of switching destinations becomes small, and comparative verification (sending the same traces to both and comparing the screens) also becomes realistic. Datadog's ingestion path is covered in OpenTelemetry Support. The third stage is replacement, and the conditions for the decision can be condensed into the following 4 points.

If conditions 1 and 2 both lean toward Datadog, it is worth proceeding to consider replacement. Conversely, if 1 leans toward Splunk, staying at the first stage of running both and gaining only correlation is the cost-effective choice.