Datadog vs. Coralogix: historical logs, storage tiers, and query costs

Two weeks after a payment incident, an engineer needs the log from one particular retry. The alert was resolved on the day, but the searchable log tier kept only seven days of data. The question is now whether the record still exists, how to retrieve it, and what the organization pays to support this occasional investigation.

If Datadog already gives the team a useful path from an error log to the request, I would sort out retention before moving to another platform. Coralogix becomes more interesting when logs dominate the workload and a large share is expensive to keep searchable but rarely used. The choice turns on what happens to those records after ingestion: which queries can still use them, which alerts stop working, and who runs the archive. Both products can store archives in the customer's cloud account.

Guance Editorial Team · Reviewed October 21, 2026. This guide compares documented cloud-service workflows. We did not benchmark performance or measure either platform's bill.

Where a log goes after ingestion

Coralogix processes incoming data and applies TCO Optimizer policies to select its priority. High, or Frequent Search, uses hot storage backed by OpenSearch. Medium, or Monitoring, and Low, or Compliance, retain raw data in customer storage while keeping it queryable through DataPrime. Streaming analysis reduces the need to index data for some operations; it does not mean the entire product has no indexes. TCO priorities

The priorities change available workflows as well as storage. Custom dashboards query Frequent Search by default and can be configured to include Monitoring data. They do not query Compliance data in the same way. A record appearing in Explore therefore does not establish that a dashboard using the same conditions will include it. Dashboard tier support

Before lowering the priority of health-check logs, establish whether they feed a dashboard or alert. Keeping a record and continuing to use it for monitoring are separate requirements. Policy order matters too: the first matching policy applies, and unmatched data defaults to High.

Datadog also offers more than standard indexing. Standard Indexing serves frequently investigated logs; Flex Logs offers scalable compute billed separately from storage, while Starter bundles the two; archives address less frequent historical access. Flex supports historical search and dashboards, but currently does not support Monitors or Watchdog. Moving data there changes what it can do. Flex Logs

Finding the request two weeks later

With a Coralogix archive configured, the relevant dataset can expose historical data without first restoring everything into a hot index. Direct archive access still has permissions, scanning limits, result limits, and performance considerations. A broad historical query may take longer than a hot-storage query. A result cap is not the number of matching records. Archive queries

Datadog can forward ingested logs to customer-owned S3, Azure, or Google Cloud storage whether or not the records were indexed. Its current documentation includes Archive Search for direct archive access, alongside Search & Rehydration when the investigation needs the corresponding platform features and retention. It is no longer accurate to assume every historical Datadog investigation requires restoring all matching data to an index. Archives, log configuration

An actual investigation usually starts with a service, date, and request identifier. Carrying those constraints into the query reduces unnecessary reading and makes the result easier to interpret. Neither archive can recover an identifier the application never logged, or a record discarded before it reached storage.

Backend semantics can also change the result. Coralogix documents that Frequent Search, backed by OpenSearch, does not index empty-array fields in the same way as archive storage represents them. A null comparison may therefore behave differently across the two paths. Its guidance is to check array length explicitly when the intended condition is an empty array. DataPrime limitations

An application release that changes a missing field to an empty array can therefore change a historical report without changing business volume. The same query text is now meeting different field representations and different search backends. Checking the array length makes the intended meaning explicit. This is a documented query-semantic difference; it says nothing about which backend is faster.

A customer-owned bucket still needs an owner

Coralogix writes archived logs and traces to Parquet in a configured S3 bucket. Its region and permissions must match the service configuration; metrics archives are configured separately. Retention can follow the organization's needs, but capacity, requests, lifecycle rules, encryption, and access remain operational responsibilities. Customer storage does not move the entire Coralogix analysis backend into the customer's environment. S3 archive configuration

Having readable files preserves options. It does not transfer DataPrime queries, dashboards, alert behavior, or access policies to a replacement platform. Datadog archives have a similar distinction: compressed JSON files do not contain a ready-to-run copy of the investigation environment.

A permissions change can interrupt delivery; a lifecycle rule can delete records earlier than intended. Detecting those failures and assigning responsibility for them matters more than describing retention as unlimited.

Daily gigabytes do not describe the entire bill

Datadog ingestion, indexing, Flex storage and compute, archives, and historical query paths need their own accounting. Excluding a record from standard indexing does not undo ingestion that already occurred. Datadog pricing

Coralogix uses consumption units whose conversion depends on the entity and pipeline. Its current log rates are 0.75 units per GB for High, 0.32 for Medium, 0.12 for Low, and 0.08 for Blocked. Blocked logs are dropped at ingestion but still incur processing consumption; they are not a free storage tier. Usage measurement

Consider 100 GB per day: 20 GB searched frequently, 60 GB used for monitoring, and 20 GB retained for occasional historical investigation. At those published ratios:

20 × 0.75 + 60 × 0.32 + 20 × 0.12 = 36.6 units/day
All High: 100 × 0.75 = 75 units/day

The saving in this example comes entirely from routing the same daily volume differently. It is not a total-cost comparison: customer storage, other signals, and contract terms sit outside the calculation, and moving a log to a cheaper tier may remove a dashboard or alert the team still uses. The unit ratios describe consumption; account quotas and the price paid per unit determine what that consumption costs.

The same retention work is possible in Guance. Ordinary log indexes can use different retention periods, so routine application logs need not inherit the retention required for audit records. After multi-index access is enabled, logs enter the first matching ordinary index. A broad production rule placed ahead of a narrower audit rule can send those audit records into the wrong retention policy. Getting that routing right is a concrete way to control storage costs before considering a platform change. Guance log indexes

Continuing from a log to the request

A payment error log may identify a failed call without explaining which dependency consumed the time. Datadog log-to-trace correlation requires identifiers, parsing, service tags, and retained data. Correlation requirements

Coralogix also provides related-data navigation from spans. The selected log datasets determine whether it queries Frequent Search or archive data, so archive configuration and tier selection affect what appears beside the request. An APM checkbox does not describe that entire workflow. Span-related data

Guance addresses the same handoff between a log and the rest of the request. Its log details expose related resources through the fields on the record; Trace details can bring together logs sharing a trace_id and the metrics of a related host or Pod. For the engineer investigating the payment retry, the useful part is continuing from the error to the surrounding execution and resource data without reconstructing that context by hand. The fields must match and the data must have been collected.

Retention has to cover that whole investigation. A log kept for thirty days can still contain a trace ID whose seven-day Trace has expired. A correlation link cannot restore it. That applies whether the team stays with Datadog, uses Coralogix, or brings the relevant data into Guance. Guance trace details

When a platform change is worthwhile

If Datadog already supports the critical request investigation and historical logs are the main problem, first clarify the jobs of Standard, Flex, and archives. Moving rarely accessed data out of a costly frequent-query path may resolve the issue without a migration.

Coralogix is a stronger candidate when logs dominate the workload, access patterns differ substantially, and the team can maintain routing and customer storage. The benefit comes from matching data to its use—not from a promise that an allegedly index-free system is always cheaper.

Incident response deserves a current assessment too. Datadog offers On-Call; it is incorrect to claim that both products necessarily require a separate third-party rotation product. Entitlements and the existing response process still determine the right arrangement. Datadog On-Call

A second platform also adds a service bill and may leave the old storage bill in place during a transition. Guance is worth including when the team needs logs, traces, and resource data to support the same investigation; that does not require copying every historical record into it. The useful comparison is what it takes to keep that investigation available over time, including collection, duplicate delivery, retention, and the systems somebody still has to operate.