Sutrace vs Datadog

TL;DR. Datadog is the most feature-complete observability product on the market. Sutrace is the predictable one. If you're paying Datadog more than $30k/year and the bill is climbing without a clear reason, the migration is worth a two-week parallel-write evaluation. If your budget isn't constrained and the integrations catalog matters more than the cost curve, stay on Datadog. We mean both halves of that sentence. Below is the side-by-side, the migration playbook, and the cases where Datadog should win the evaluation. The longer version of the cost-driver analysis is on the Datadog alternatives page.

Side-by-side

Pricing — the real shape

Datadog's pricing has three structural multipliers that catch teams off guard. We covered each in detail elsewhere; here's the summary.

Custom metrics. Datadog defines a custom metric as a unique combination of metric name + tag values. SigNoz's pricing teardown and OneUptime's analysis put the marginal cost at roughly $0.05 per custom metric per month above tier limits. One PR adding customer_id to a widely-emitted metric in a 5,000-customer SaaS multiplies your bill — this is the dynamic the HN $83K renewal thread is about. The full math is in cardinality explained with examples.

Log retention tiers. Indexed logs cost dramatically more than archived logs. The tooling makes it easy to over-index. The pricing rewards over-retention; the alternative architecture is described in our OTel + ClickHouse quickstart.

Synthetics. $12 per 1,000 browser checks, $5 per 10,000 API checks sounds cheap. Then Checkly's calculator-as-prose does the math: 16 routes × 4 regions × every 4 minutes is $8,509/month. Plausible config, real pricing.

Sutrace bills on ingest you can predict — GB of metrics + logs + traces, plus synthetic checks bundled with regional caps. Cardinality is tracked and shown on every metric's page, with auto-warn when a deploy spikes it. We don't bill for it; we enforce a budget on it.

The full pricing model is on the pricing page.

When Datadog wins

We will not pretend this is a one-sided comparison. Datadog is the right answer when:

1. Integrations breadth matters more than cost. Datadog has 700+ integrations. We have around 80 — the ones most teams actually use. If you depend on one of the long-tail integrations (specific SaaS connectors, niche cloud services), Datadog will save you the time of building a custom OTel receiver.

2. APM auto-instrumentation breadth. Datadog's auto-instrumentation works on more language runtime versions than the upstream OTel SDKs. If your stack includes legacy runtimes (older PHP, older .NET Framework, weird Java versions), Datadog will instrument them with less effort.

3. You have a procurement team that values "single throat to choke." Datadog is a $50B+ company. They have audit reports, certifications, support SLAs, and customer-success org structure that Sutrace doesn't yet match.

4. Your existing investment is large. Migrating off a year of Datadog dashboards-as-code, custom dashboards, alerts, and synthetic monitors is two weeks of focused work for a small team. If your team can't afford the focus, the right answer is to optimise inside Datadog (cardinality reduction, log tier audit, synthetic frequency tuning) before considering a switch.

The HN cheaper-Datadog thread and the What instead of Datadog thread both contain serious arguments on both sides. The honest read is that Datadog is good at what it does; it's also expensive at scale, and the cost is structural rather than fixable inside the product.

When Sutrace wins

The mirror conditions:

1. Cardinality is the cost driver. If your Datadog bill grew faster than your headcount and the line item is custom metrics, the architectural fix is upstream of the bill. Sutrace's cardinality cost attribution before ingest is the wedge.

2. EU data residency is mandatory. Frankfurt-default storage and EU-bounded support staff access. Datadog supports EU sites but requires explicit site selection per workspace and the staff-access model is global by default.

3. OpenTelemetry purity matters. We covered this in the OTel use-case page. Resource attribute names survive ingest. Migration in or out is symmetric.

4. Alerting defaults that don't burn the on-call rotation. We ship five tuned-by-default rules; Datadog ships a kitchen-sink starter. The tuned-by-default post covers the difference. The on-call rotation health argument is in the alert-fatigue pillar.

5. Mixed-signal-type observability. Hardware (PLC/SCADA), software, web/APIs, AI agents — one dashboard. Datadog can do most of this with add-ons; we do it natively without add-on SKUs.

The migration playbook

Most teams that switch use this sequence:

Week 0 — model the bill. Pull the last 12 months of Datadog invoices. Categorise by SKU (metrics, logs, APM, synthetics, RUM). Identify the line items that are growing fastest. This is the work product you take to your CFO.

Week 1 — parallel-write configuration. Configure the OTel Collector to fan out OTLP to both Datadog and Sutrace. Validate that the same data lands in both. The OTel Collector's forward exporter pattern is documented in our OTel + ClickHouse quickstart — same pattern, different second exporter.

Week 2 — dashboard parity. Recreate the top 10 dashboards your team actually uses. Most teams discover that 30 of the 60 dashboards they had on Datadog were unused.

Week 3 — alert parity. Recreate the alerts you actually rely on. Use the migration as an opportunity to delete the ones you should have deleted last year. The audit checklist in the alert-fatigue pillar is the right sequence.

Week 4 — flip on-call. Cut on-call routing to Sutrace. Keep parallel-write to Datadog for two more weeks as a safety net. Then remove the Datadog exporter and let the contract expire.

We've done this with teams of 10–200. The blocker is rarely technical; it's the procurement-cycle conversation about an annual commit you've already paid for.

What we won't do

A few things we want to be honest about:

• We will not match Datadog feature-for-feature. We're focused. The product is intentionally smaller.
• We are not open-source. If self-host is a hard requirement, SigNoz is the better answer; our SigNoz comparison covers that case honestly.
• We will not undercut Datadog on every line item. We undercut on cardinality and synthetics. Some workloads — high log volume with short retention — are a wash.

What to do next

If you're seriously evaluating, three concrete actions:

1. Read the Datadog alternatives page. It's the long version of this comparison.
2. Run a parallel-write evaluation for two weeks. Free tier is enough — see pricing.
3. If your shape is "EU + cardinality-heavy + small team," schedule a 30-minute call. We will tell you honestly if your shape is a fit.

If your shape is "$1M+/yr Datadog, 100+ engineers, integrations breadth is essential," the honest answer is probably stay on Datadog and optimise. We won't waste your time and we won't waste ours.

Closing

Datadog is a great product that has a structural cost curve. Sutrace is a smaller product with a flatter cost curve and a different opinion about what should ship in the box. Pick the one whose curve matches your trajectory.

The Grafana Cloud comparison, the SigNoz comparison, and the Better Stack comparison cover the other directions you might be looking. The pricing page is the third tab to open.