--- icon: material/scale-balance title: "Comparisons" --- How 10x uses Datadog Flex Logs and what a move costs, how it compares with Archive Search and Log Rehydration, with index daily quotas, exclusion filters and Log Optimizer, with Observability Pipelines, what holding Standard indexing at a monthly number with Datadog tools alone takes, and where CloudPrem fits. ### :material-scale-balance: Comparisons ??? tenx-compare "How 10x uses Datadog Flex Logs" **10x routes the excess over each cap to Flex.** The Receiver caps each pattern and marks the excess `@routeState:tier_down`; an index filter on that attribute, on a Flex Logs index listed before the Standard one, lands it in Flex. Those events stay searchable in Log Explorer with no rehydration, log-based metrics and Live Tail still see them, and they pay ingestion. The action is set per service and applies to every pattern over its cap in that service. Datadog sells Flex itself; 10x chooses which excess, per pattern, goes there. **Flex pricing** - **$0.10 per GB ingestion:** paid once on every event that reaches Datadog, unchanged by a Flex move - **Standard indexing:** $1.70 per million events at 15-day retention and $2.50 at 30-day, annual ($2.55 and $3.75 on demand); the charge a Flex move avoids - **Flex Starter:** storage and compute together at $0.60 per million stored a month, annual ($0.90 on demand), for at least 3 months, with compute bundled for volumes below 2 billion events a month and 10 billion stored ([Datadog pricing](https://www.datadoghq.com/pricing/?product=log-management){target="_blank"}); an event held 3 months costs at least $1.80 per million over its life - **Scalable tiers above Starter, XS to L:** storage at $0.05 per million stored a month, annual ($0.075 on demand), held at least 30 days, plus a flat compute tier Datadog prices on request - **No monitors on [Flex Logs](https://docs.datadoghq.com/logs/log_configuration/flex_logs/){target="_blank"}:** keep every pattern a monitor reads in Standard On the public OpenTelemetry capture every target the benchmark runs falls in Flex Starter, and a Flex move costs more than the 15-day Standard indexing it avoids and less than the 30-day; the month-by-month table is in [benchmarks/datadog-flex-accounting](https://github.com/log-10x/benchmarks/tree/main/datadog-flex-accounting){target="_blank"}. **What a plan reports for a Flex move:** Flex is the first action the [MCP server](https://github.com/log-10x/log10x-mcp){target="_blank"} plans on Datadog, ahead of offload, because the moved events stay searchable in Datadog. The plan states the events and GB moved out of the Standard index, the Standard indexing that move avoids at list, and the Flex line it adds at list, and names compute above Starter as unpriced and excluded. Every figure is an event count, a GB total or a list-price amount, never a percentage of the Datadog bill. Flex Logs must be enabled on the account first: pick a compute size on the Flex Logs page, or Datadog rejects the index. Start on Flex Starter; the larger tiers add a compute charge quoted on request. **For patterns that should leave Datadog entirely:** the offload action writes them to an S3 bucket the team owns, at $0.023 per GB-month, and the [Retriever](https://doc.log10x.com/apps/retriever/) queries them in place through Bloom filter indexes and streams a time range and pattern back on demand, paying Datadog ingestion only on what comes back. Repetitive S3 events can also be aggregated into data points on Datadog's time-series API, for dashboards at metric pricing. *[Datadog pricing](https://www.datadoghq.com/pricing/){target="_blank"} as read on 2026-10-13* ??? tenx-compare "How 10x compares with Datadog Archive Search and Log Rehydration" **Datadog reads its archive two ways.** [Archive Search](https://docs.datadoghq.com/logs/explorer/archive_search/){target="_blank"} queries the archive in the team's own bucket (S3, Azure Storage or Google Cloud Storage) without re-indexing: it bills the scan by the total size of the files read, skips blocks by up to two partition and two lookup attributes per archive, and returns up to 100,000 logs kept for 24 hours. [Rehydration](https://docs.datadoghq.com/logs/log_configuration/rehydrating/){target="_blank"} scans the archive at $0.10 per compressed GB scanned and then bills indexing at the contracted per-million-event rate on what it indexes. Both cover only what was archived, and both select by time range and query. The [Retriever](https://doc.log10x.com/apps/retriever/) reads the offloaded slice in the team's S3 through Bloom filter indexes and fetches the byte ranges that hold the matching events, by pattern and time range. | | Archive Search | Rehydration | Retriever | |---|---|---|---| | **Cost** | The bytes of the files the query reads | $0.10 per compressed GB scanned, plus per-million-event indexing | S3 storage at $0.023 per GB-month, and the byte ranges each query reads | | **Data scope** | What was archived from Datadog | What was archived from Datadog | Every offloaded event, in full | | **What it reads** | The time range, less the blocks the partition and lookup attributes rule out | The time range | The objects whose Bloom filters match the pattern and time range | | **Output** | Up to 100,000 logs, kept 24 hours | Re-indexed into Datadog | Streamed to Datadog, or aggregated into metrics | | **Selection** | A time range and a query | A time range and a query | A pattern and a time range | Logs excluded from an index can still be archived, since ingestion is decoupled from indexing, so both Datadog paths reach them; only what was never ingested is out of reach. The Datadog archive and the offloaded slice both sit in storage the team owns. The contrast left is how much each query reads to find an incident's lines: the files of a time range, narrowed by attributes, against the byte ranges a pattern's Bloom filters point to. *[Datadog pricing](https://www.datadoghq.com/pricing/){target="_blank"} as read on 2026-10-13* ### :material-scale-balance: Decision Guide ??? tenx-compare "Index quotas, exclusion filters, Log Optimizer, or a monthly number" **The first cut is native.** On the public OpenTelemetry capture, `service:` index filters with `-status:(error OR warn)` move every event the per-pattern plan moves at 30% and more besides, and at 50% move more events in all but leave 23,161 of the plan's in Standard ([benchmarks/datadog-flex-accounting](https://github.com/log-10x/benchmarks/tree/main/datadog-flex-accounting){target="_blank"}). Inside one service on unchanged code, eight logger-class filters equal one cap row on events, and a cap moves about a hundred lifecycle lines that a filter set written on one capture leaves in Standard on the next ([benchmarks/datadog-service-control](https://github.com/log-10x/benchmarks/tree/main/datadog-service-control){target="_blank"}). **Datadog's own tools:** - **[Index daily quota](https://docs.datadoghq.com/logs/log_configuration/indexes/){target="_blank"}:** a ceiling per index; once reached, the index stops indexing every log until the quota resets, errors included. - **[Exclusion filters](https://docs.datadoghq.com/logs/log_configuration/indexes/#exclusion-filters){target="_blank"}:** a query per index, sampled at 0 to 100%; the excluded logs are still ingested. - **[Log Optimizer](https://docs.datadoghq.com/logs/log_configuration/log_optimizer/){target="_blank"}:** daily recommendations on indexed logs, with monitor usage checked before each one, applied one click at a time; it recommends no Flex move. - **[Watchdog Insights](https://docs.datadoghq.com/watchdog/insights/){target="_blank"}:** flags emergence or spikes of WARN and ERROR logs. **What the monthly number adds:** one monthly number for Standard indexing sets a cap for every source statement, the logging call in the code a pattern comes from, so the statements it moves need no rule of their own. Each statement over its cap takes its service's action, so the noisiest statements move first and small ones keep passing. Each error statement keeps up to 50 lines over its limit in Standard in each 4-minute window on each node, released in four slices across the window, and a service passes at most 500 of them in a window once its total is spent. A statement new in a deploy is held from its first line, and the excess is kept, in Flex or in S3. The [rate regulator](https://doc.log10x.com/run/receive/rate/) page states the 10x rules; Datadog's index and Quota pages state Datadog's. | | Index daily quota | Exclusion filter | 10x monthly number | |---|---|---|---| | Rule | A daily event count per index | A query per index, 0 to 100% sampling | A monthly number, divided per service and per statement, one action per service | | At the limit | Every log in the index stops indexing, errors included | Matching logs leave the index, whatever the volume | The noisiest statements move first; each error statement keeps up to 50 lines over the limit in each window on each node in Standard, released across the window, at most 500 for a service past its total | | Effect | Not indexed until reset; still ingested | Leaves the index; still ingested | Leaves the Standard index for Flex or S3; still ingested on Flex | | Recoverable | From the archive, by Archive Search or rehydration | From the archive, by Archive Search or rehydration | In Flex, by search; in S3, by the Retriever | | Where it runs | In Datadog | In Datadog | On the forwarder, before Datadog | **Fit.** A team with a few dozen services and stable code writes the filters itself, and should. The cap is for a fleet whose services and code change faster than a filter set is maintained. ??? tenx-compare "How does 10x differ from Datadog Observability Pipelines" [Observability Pipelines](https://docs.datadoghq.com/observability_pipelines/){target="_blank"} runs a Worker in the team's infrastructure that processes logs before they reach Datadog or another destination. Its [Quota](https://docs.datadoghq.com/observability_pipelines/processors/quota/){target="_blank"} processor measures events or bytes over a fixed 24-hour window that resets at midnight UTC, partitions by any field (1,000 buckets, more through support), and keeps, drops or sends the overflow to S3, Azure Blob or Google Cloud Storage. Its [Throttle](https://docs.datadoghq.com/observability_pipelines/processors/throttle/){target="_blank"} processor limits the number of logs in a configurable window, grouped by a field, and drops the excess. Both key on a parsed field. 10x keys on the pattern: each line is named by its most likely source statement, from a symbol library compiled from the code, the same on every pod and present before any parsing. On Datadog that key drives: - **tier_down:** the excess over a cap goes to a Flex Logs index, searchable in Datadog - **offload:** the excess goes to S3 the team owns, and the [Retriever](https://doc.log10x.com/apps/retriever/) fetches back what a query asks for - **sample and drop:** the lossy actions, set per service like the others The Quota processor counts per partition on fields the logs already carry, such as service and status, so inside one partition the noisiest statement and a rare one share one count. The cap is enforced continuously, so a burst cannot spend a day's allowance at once, and an hourly budget run against Datadog's usage metric holds the month to the number. Compact, the lossless volume reduction, applies to the S3, Splunk and Elasticsearch paths; events sent to Datadog keep their original structure. ??? tenx-compare "Holding the number with Datadog tools alone" **Datadog supplies the parts; the loop is the team's to build.** A budget set on day one meets three things: a benign statement that starts firing 50 to 500x its rate, with no deploy of the team's own code, because an input shape, an external API or a retry loop changed; a few statement types each growing 5 to 10% a month until the month-end count passes the number; and coding agents adding statements and services weekly. Holding Standard indexing at a monthly number through that, with the excess kept in Flex rather than dropped, takes five pieces, each documented by Datadog. 1. **Statement identity: an [Observability Pipelines](https://docs.datadoghq.com/observability_pipelines/){target="_blank"} Worker in the path of every log**, beside the sources or in a regional or central pool, with a [custom processor](https://docs.datadoghq.com/observability_pipelines/processors/custom_processor/){target="_blank"} that strips digits, hex, UUIDs and quoted values from the message by regex and writes the result as a signature attribute, plus a random integer per line for sampling. Datadog's own [Patterns](https://docs.datadoghq.com/logs/explorer/analytics/patterns/){target="_blank"} view groups 10,000 sampled logs for the screen; a filter keys on the text query copied from a pattern, not on the pattern. The signature is as good as the regex: a message with variable words splits into many, and two statements with one shape merge. Observability Pipelines is priced per GB the Worker processes, from $0.095 per GB annual ($0.12 on demand), on every log, alongside the $0.10 per GB Datadog ingestion. 2. **A count per statement: a [log-based metric](https://docs.datadoghq.com/logs/log_configuration/logs_to_metrics/){target="_blank"}** grouped by the signature, computed on ingested logs whether indexed or not, billed as custom metrics, one series per statement, so the metric bill grows with every statement the agents add. 3. **Route and sample in one step: a Flex index listed first**, whose [index filter](https://docs.datadoghq.com/logs/log_configuration/indexes/){target="_blank"} names the demoted signatures together with the random attribute (`@sig:A AND @r:>=5`), so 5% of a demoted statement stays in Standard and the rest lands in Flex. Logs enter the first index whose filter they match, and an index filter has no sampling rate; an [exclusion filter](https://docs.datadoghq.com/logs/log_configuration/indexes/#exclusion-filters){target="_blank"} samples at 0 to 100% but removes the sampled-out logs from the index rather than passing them on. Nothing native sends overflow to Flex: a reached [daily quota](https://docs.datadoghq.com/logs/log_configuration/indexes/){target="_blank"} stops indexing every log in the index until the reset, errors included, and the Observability Pipelines [Quota](https://docs.datadoghq.com/observability_pipelines/processors/quota/){target="_blank"} processor keeps, drops or sends its overflow to S3, Azure Blob or Google Cloud Storage over a 24-hour window that resets at midnight UTC, while [Throttle](https://docs.datadoghq.com/observability_pipelines/processors/throttle/){target="_blank"} and [Sample](https://docs.datadoghq.com/observability_pipelines/processors/sample/){target="_blank"} drop what they hold back. 4. **The controller: a [Workflow Automation](https://docs.datadoghq.com/service_management/workflows/){target="_blank"} job**, hourly and on monitor fire, that reads `datadog.estimated_usage.logs.ingested_events` for the Standard index month to date, reads each signature's metric against its baseline, projects month end, and rewrites the Flex index filter through the [Logs Indexes API](https://docs.datadoghq.com/api/latest/logs-indexes/){target="_blank"}. The team writes the allowance arithmetic, the demotion order, the hysteresis that stops a statement flapping between indexes, the retry on 429, and the truce with Terraform over who owns the index. The usage metric differs from [billable usage](https://docs.datadoghq.com/account_management/billing/usage_metrics/){target="_blank"} by 10 to 20% on average, so the controller aims below the number. Workflow executions are priced from $10 per 100 annual ($14 on demand), about $72 a month at one an hour. 5. **Monitors rebuilt:** a [log monitor](https://docs.datadoghq.com/monitors/types/log/){target="_blank"} evaluates indexed logs only and [Flex Logs](https://docs.datadoghq.com/logs/log_configuration/flex_logs/){target="_blank"} support no monitors, so every monitor that counts a sampled statement is wrong by the sample rate until it is rebuilt as a metric monitor on the log-based metric from step 2. [Log Optimizer](https://docs.datadoghq.com/logs/log_configuration/log_optimizer/){target="_blank"} advises rather than controls: it analyzes indexed logs once a day, each recommendation is applied by hand as an exclusion filter or a metric, and it does not account for the exclusion filters already in place. Built that way, the loop holds: a spiking statement is demoted within minutes by a change monitor on its signature, creep is caught by the hourly projection, and a new statement gets a signature with no list to maintain, provided every new service ships through the Worker. What the Receiver changes is where the five pieces sit: identity comes from a symbol library compiled from the code, the same on every node, in place of the regex and the Worker; the cap, the sample and the route are decided once on the forwarder, before ingestion, in place of the random attribute, the filter rewrite and the second per-GB charge; and the hourly run against the usage metric comes with the Receiver, with up to 50 over-limit error lines of each statement kept in Standard in every window on every node, released across the window, so a log monitor on a storming error statement sees its lines in every window. The [rate regulator](https://doc.log10x.com/run/receive/rate/) page states those rules. *[Datadog pricing](https://www.datadoghq.com/pricing/){target="_blank"} and the linked docs as read on 2026-10-20* ??? tenx-compare "Where Datadog CloudPrem fits" **CloudPrem is about where Datadog processes logs; 10x is about how many reach the Standard index.** CloudPrem runs Datadog's log processing on the customer's own infrastructure. 10x acts on the forwarder before Datadog's SaaS or CloudPrem, so the cap and the offload path work the same wherever Datadog indexes.