Axiom vs Datadog for Log Management: Ingestion, Retention, and DX Compared

You ship a feature, traffic spikes, and a week later your Datadog invoice is three times what you budgeted. Log management pricing is notoriously opaque, and Datadog's model — charging per ingested gigabyte, per indexed gigabyte, and then again for retention beyond a few days — catches teams off guard constantly. Axiom pitches itself as a simpler, cheaper alternative built for developers who want to query logs without watching a cost meter tick up.

This article is a direct comparison. Not a sales pitch for either product — just an honest breakdown of how each platform handles ingestion, storage, pricing, and the daily experience of actually using it.

What you'll learn

• How Datadog and Axiom structure their log ingestion and retention pricing
• Where each platform's free tier and limits actually sit
• What the query and alerting experience looks like on both sides
• Which workloads each tool handles better
• What to watch out for before you commit

Prerequisites

This comparison assumes you've shipped at least one production service and have some familiarity with structured logging. You don't need to be a Datadog power user, but knowing what log ingestion and indexing mean in the context of observability will help you follow the pricing logic.

How Datadog Prices Logs

Datadog splits log management into two separate charges: ingestion and indexing. Every log that enters the platform counts toward ingestion. Only the logs you choose to index — and therefore make searchable — count toward the second charge.

On top of that, indexed logs are retained for a limited window (often 15 days on standard plans). If you need longer retention, you pay again to extend it. If you want to rehydrate archived logs from cold storage for a query, that's another charge. The total cost of a single log can pass through three or four billing events before you're done with it.

There is a free tier, but it is genuinely small — enough to evaluate the product, not run a production service. At scale, Datadog log costs for a moderately busy application can run into hundreds of dollars per month without much effort.

How Axiom Prices Logs

Axiom's model is simpler by design. The free tier allows a meaningful daily ingestion limit and retains data for 30 days — numbers that are generous enough to run a real side project or small production service without paying anything.

Paid plans charge primarily on data ingested per month. There is no separate indexing charge. Everything you send in is queryable. Retention can be extended, and the cost per GB stored is generally lower than Datadog's equivalent because you're not also paying for indexing on top of storage.

The tradeoff is that Axiom is a younger product. The ecosystem of integrations, third-party alerting connectors, and adjacent features (APM, infrastructure metrics, synthetics) is much smaller than Datadog's. You are paying less, but you are also getting less surface area.

Ingestion Limits Side by Side

The exact numbers shift with plan changes, so always verify against each vendor's current pricing page before committing. The shape of the comparison — Axiom simpler and cheaper per GB, Datadog more expensive but more feature-rich — has been stable for a while.

Sending Logs: The Developer Experience

Getting logs into both platforms is straightforward if you're already using a log shipper like Fluent Bit, Vector, or the OpenTelemetry Collector. Both accept HTTP endpoints and have decent documentation for the common shippers.

Axiom

Axiom exposes a clean REST API. You send a JSON array of log events to a dataset endpoint with an API key in the header. That's it. There's no agent to install unless you want one. For a Node.js service, sending a batch of logs looks roughly like this:

const logs = [
  { level: "info", message: "User signed in", userId: "u_123", ts: new Date().toISOString() },
  { level: "error", message: "Payment failed", userId: "u_456", ts: new Date().toISOString() }
];

await fetch("https://api.axiom.co/v1/datasets/my-app-logs/ingest", {
  method: "POST",
  headers: {
    "Authorization": "Bearer YOUR_API_TOKEN",
    "Content-Type": "application/json"
  },
  body: JSON.stringify(logs)
});

In practice you'd batch these and use a proper logger (Winston, Pino, etc.) with a transport rather than raw fetch calls, but the point is that the API surface is minimal and predictable.

Datadog

Datadog's log ingestion endpoint works similarly, but the Datadog Agent is often the recommended path because it handles log tailing, tagging, and enrichment automatically. The agent is mature and handles high-volume shipping reliably, but it's another process to deploy, configure, and maintain. For containerized workloads, Datadog's Kubernetes integration is thorough — arguably the most polished of any observability vendor — which is a real point in its favor for teams running complex infrastructure.

Querying Logs

This is where the two products feel most different day to day.

Axiom's APL Query Language

Axiom uses APL (Axiom Processing Language), which is derived from Kusto Query Language (KQL). If you've used Azure Monitor or Microsoft Sentinel, it will feel familiar. If you haven't, there's a learning curve. A basic query filtering errors and counting them by service looks like this:

['my-app-logs']
| where level == "error"
| summarize count() by service
| order by count_ desc

APL is genuinely powerful for analytical queries — aggregations, time-series operations, joining datasets. The web UI renders results quickly even across large time ranges, which is one of the more impressive things about Axiom's columnar storage architecture.

Datadog's Log Explorer

Datadog uses a search syntax closer to Lucene/Elasticsearch. It's more approachable for developers who've used tools like Kibana. Faceted filtering, saved views, and live-tail streaming are polished and work well. Datadog also integrates logs tightly with traces and metrics — clicking from a slow trace into the associated logs is seamless in a way Axiom can't yet match because Axiom doesn't do APM.

Alerting and Notifications

Datadog's alerting is comprehensive. Log-based monitors, anomaly detection, composite alerts, and integrations with PagerDuty, Opsgenie, Slack, and dozens of other tools are all first-class features. If your team relies on complex alert routing, Datadog's monitor system is hard to beat.

Axiom's alerting is functional but simpler. You can create monitors that fire on query results and send notifications to Slack, PagerDuty, or a webhook. For most teams shipping a single application, this covers the common cases. For platform engineering teams managing alerting across dozens of services with complex routing rules, you'll notice the gaps quickly.

Common Pitfalls to Avoid

• Underestimating Datadog's indexing bill: It's easy to set up Datadog, ship all your logs, and discover that indexing everything is extremely expensive. Use exclusion filters aggressively from day one — only index logs you intend to query.
• APL learning curve with Axiom: If your team isn't familiar with KQL-style syntax, budget time for onboarding. The Axiom docs and community are helpful, but it's not as intuitive as a Lucene search bar for new users.
• Assuming Axiom replaces Datadog entirely: If you need APM, infrastructure metrics, synthetic monitoring, and logs in one place, Axiom doesn't cover that. It's a logs and events platform, not a full observability suite.
• Retention defaults catching you off guard: Both platforms have default retention windows that may be shorter than you expect for compliance or debugging purposes. Set your retention policy explicitly when you first configure the platform.
• High-cardinality fields in Datadog: Tagging logs with high-cardinality values like user IDs or request IDs can significantly inflate your indexing costs. Keep indexed tags low-cardinality.

Which One Should You Choose?

If you are running a small-to-medium application, care about keeping your observability bill predictable, and don't need APM or infrastructure metrics in the same platform, Axiom is the stronger choice. The ingestion model is simpler, the free tier is genuinely usable, and the query performance on large datasets is impressive.

If you are running a complex infrastructure — multiple services, Kubernetes clusters, and a team that needs correlated traces, metrics, and logs in one place — Datadog's ecosystem advantage is real. You'll pay more, but the time saved by having everything integrated often justifies the cost for larger teams.

A middle path worth considering: use Axiom for application logs (where the volume is high and the cost sensitivity is real) and a lighter Datadog configuration for infrastructure metrics and APM only. Plenty of teams run this kind of split setup to get the best cost profile from each tool.

Wrapping Up

The core takeaway is that these tools optimize for different things. Axiom optimizes for low cost per log and a clean developer experience for log-heavy workloads. Datadog optimizes for breadth — one platform for all your observability signals, with a mature ecosystem built over many years.

Here are concrete next steps before you make a decision:

1. Run a two-week pilot with your actual log volume. Both platforms offer free tiers — send real production logs and measure the bill on Datadog and the query experience on Axiom before committing.
2. Audit your current Datadog usage if you're already a customer. Identify how much of your bill is indexing versus ingestion, and check whether exclusion filters could cut it significantly.
3. Define your retention requirements explicitly. If you need 90-day or longer retention for compliance, price that out on both platforms before assuming either is cheaper.
4. Evaluate whether you actually need APM. If your traces live in a separate tool already (Jaeger, Tempo, Honeycomb), Axiom's lack of APM is not a dealbreaker.
5. Check your team's query fluency. If everyone on your team uses Kibana-style search daily, factor in the APL learning curve as a real switching cost for Axiom.