OpenObserve vs. Datadog Logs: indexing, archives, and the cost of self-hosting

A high Datadog logging bill does not necessarily mean the next step is migration. First check how much routine traffic enters Standard Indexing, how often anyone searches logs older than a week, and whether archives are being used. Changing those choices can materially change the current bill. Compare OpenObserve with that optimized configuration to estimate what a migration could actually save.

If a large volume must remain readily searchable after those changes, and the team can operate its own backend, OpenObserve deserves a closer look. If logs are tightly integrated with Datadog APM and monitors, moving storage alone creates another cost: cross-platform investigation and rule migration. The storage savings need to cover that work.

This comparison separates metering, access patterns, and operating effort. It does not use a customer's savings percentage or assume one universal price. Average event size, retention, and query frequency can lead to different decisions.

The source analysis was reviewed on October 9, 2026. The figures below are reproducible capacity examples, not customer bills, vendor quotes, or promised savings. No Datadog performance benchmark was run.

Published by Guance. Product documentation was checked again on October 13, 2026; prices must still be scoped to the selected offering and contract.

Overview

Convert bytes into the meters on the bill

Assume 500 GB of uncompressed logs enters the processing path each day and the average event is 1 KB. These are decimal units: 1 GB is 10⁹ bytes and 1 KB is 10³ bytes. The workload therefore contains approximately 500 million events per day.

If 20% enters seven-day Standard Indexing, that is 100 million newly indexed events per day, or 3 billion during a 30-day billing month.

If the same 500 GB/day consists of 10 KB events, the event count falls to one-tenth of the example. That changes an event-based charge substantially without necessarily changing a byte-based ingestion charge. Average event size and multiline aggregation therefore belong in the comparison.

Datadog's published pricing separates ingestion and Standard Indexing. Let Pg be the ingestion price per GB and P7 the price per million events in the seven-day tier. The example's base calculation is:

15,000 × Pg + 3,000 × P7

P7 already represents the seven-day tier. Do not multiply it by seven again. Commitments, overages, discounts, and other features may change the actual bill; the formula only aligns the underlying meters. See Datadog pricing and log billing documentation.

Use the same source sample to derive the other candidates' quantities. Ingested bytes, event count, compressed transmitted bytes, and physical storage describe different stages. Even two rates labeled “per GB” may apply to different representations or subsets of the data.

Optimize Standard Indexing before pricing a migration

Datadog's index exclusion rules operate after ingestion. Excluded logs do not enter the relevant index, but can remain available to configured paths such as Live Tail, log-based metrics, and archives. Reducing the indexed proportion from 100% to 20% therefore does not imply an 80% reduction in the complete log bill. See indexes and exclusion filters.

Separate three kinds of data:

• Unneeded debug events can be removed at collection, reducing subsequent transmission and ingestion.
• Records needed as evidence but rarely searched can be candidates for an archive or another suitable retention tier.
• Events used in daily investigation and alerting need the access capabilities those workflows require.

An indexing quota is another control, with a different consequence. Once the quota is reached, new logs stop entering that index, although other configured destinations may still receive them. That can cap indexed usage while preventing an evening incident from using the usual indexed search and monitor workflow. If the expected daily volume is 100 million indexed events and the quota is 80 million, the remaining 20 million do not remain available in the same tier at no charge.

Credit these optimizations to the current platform before comparing alternatives. Apply an equivalent retention strategy to OpenObserve. Otherwise, the comparison rewards a carefully designed new deployment for work that could also improve the existing one.

Price historical access according to how often it is used

Datadog offers Flex Logs and archive access in addition to Standard Indexing. Flex Logs separates longer-term storage considerations from query compute; availability and configuration depend on the relevant site and offering. See the Flex Logs documentation.

Occasionally retrieving a few records from last week is different from running month-long aggregations throughout every investigation. The former may tolerate a delay. The latter repeatedly consumes query resources. Choosing the least expensive storage tier for that workload can simply move spending into the query portion of the bill.

Datadog's archive workflows also have distinct access models. Archive Search can return results without reindexing, while rehydration makes selected archived data available through a rehydrated index. Check the available mode, scan charges, index charges, and retention requirements for the intended workflow. Historical access does not always require a full reimport. Archive Search does not provide the aggregations and analytics of indexed logs, so a historical record lookup and a historical dashboard require different access plans. See Archive Search and rehydration.

For rehydration, the query filter is applied after files for the selected interval are downloaded. Scan volume is based on retrieved data, not just matching results. Selecting a day and filtering for service:A may still retrieve files containing other services. Narrowing the time range can have a more direct effect on that scan. Cloud archive storage and transfer charges also need their own line items.

OpenObserve is not exempt from historical-query costs. A first read of an older object can require remote retrieval, decompression, and compute. Repeating a query against a warm cache measures a different path. Long retention with rare access may permit modest query capacity; frequent, concurrent analysis across long periods requires a different budget.

Include the resources around OpenObserve's object storage

A self-hosted OpenObserve budget has several parts:

1. Ingestion and processing: capacity for peaks, transformations, and invalid-event handling.
2. Retained objects and metadata: the long-term data footprint and the information needed to locate it.
3. Indexes, caches, and temporary space: resources that support search and processing.
4. Query compute: capacity for concurrent investigations, historical scans, and periods when ingestion is also catching up.

These costs do not necessarily grow at the same rate. Retained objects may grow approximately with the retention window, while a compute tier expands in steps. A cold-query workload may hit network throughput, object requests, or decompression capacity before storage becomes the limiting factor. Applying one compression ratio to the whole deployment misses those differences. See OpenObserve storage management.

OpenObserve already provides queries, dashboards, alerts, and tracing capabilities. The migration is not a project to implement all of those features from scratch. It is a project to move the team's existing queries, monitors, field conventions, and investigation habits. A feature existing in the destination does not mean the source configuration has been migrated. See the OpenObserve tracing guide.

If only logs move and APM stays in Datadog, other contract charges may remain. Investigation may also span two systems. Moving both expands the project's scope. Count the charges that can actually be stopped, rather than treating the entire existing bill as a saving.

Model three years of usage and engineering work

Separate recurring costs from one-time work:

Managed service, three years = sum of monthly usage charges
                             + integration and migration
                             + internal configuration maintenance
                             + transition costs

Self-hosted, three years = sum of monthly infrastructure and required software/support costs
                        + implementation and migration
                        + ongoing operation
                        + transition costs

Both approaches need collection, field governance, and business alert maintenance. Charging all of that shared work only to self-hosting would distort the comparison. Conversely, capacity planning, upgrades, recovery, and storage operation cannot disappear into an “existing staff” category. A salaried engineer still has limited time for other projects.

If usage in the first year is the baseline and increases 30% in each subsequent year, the three-year variable-usage factor is:

12 × (1 + 1.3 + 1.69) = 47.88 baseline months

That is different from 36 months at constant usage. Apply the factor only to approximately linear usage charges. Fixed costs and capacity steps need separate treatment.

A simple break-even model can also help. For equivalent functionality, define:

• R: monthly self-hosted infrastructure and support cost.
• H: the monthly cost of additional operating effort relative to the managed option.
• S: the complete monthly managed-service charge.
• A: the additional one-time implementation cost of self-hosting relative to the managed option.

Ignoring growth and differences in transition costs, the managed option costs less in the first year when:

S < R + H + A / 12

A mature platform team with spare capacity may have a small H and A. A team borrowing engineers from product work may not. The one-time investment also should not be charged again in year two, so the first-year and steady-state decisions can differ.

When a migration is worth the work

When Datadog's logging, APM, and monitors are already part of one well-used workflow, optimize indexing and retention first. Moving the log store can save an index charge while increasing the time spent reconstructing context across systems.

OpenObserve has more room to offer a cost advantage when log volume is high, access patterns are understood, operators are available, and the important queries translate well. Include rule migration, dual delivery, overlap with the old contract, and operational support. If the remaining saving pays back the migration within an acceptable period, there is a defensible reason to proceed.

If engineering capacity and delivery time are the tightest constraints, include managed alternatives in the shortlist. Saving infrastructure charges does not help if the additional platform work costs more than it removes.

Include Guance on the same cost basis

Guance provides log processing, indexing, querying, and related investigation capabilities. In a managed deployment, backend operation belongs to the service provider, while the customer still owns collection choices, field conventions, and business rules. That can remove cluster maintenance planned for a self-hosted design; it does not eliminate all logging work.

Guance Enterprise Plan charges follow the applicable usage items. Storage policy, query range, index conditions, and required compute can also affect the choice. Use the Enterprise Plan billing documentation and data storage policy for the actual deployment and plan.

Estimate the optimized Datadog configuration, the complete self-hosted OpenObserve deployment, and Guance using the same bytes, events, retention, and frequent queries. A service charge can exceed the machine bill and still cost less than machines plus implementation and operation. A team with a mature platform may reach the opposite result. The useful difference is the spending and work the team can actually avoid.

The metering examples and calculations include Chinese explanatory notes. They distinguish GB from GiB and do not insert hypothetical vendor prices. Recalculate when contract terms, usage, or product behavior changes.