compare
Sutrace vs Grafana Cloud — managed convenience vs composable depth
Honest comparison. Pricing model and DPM-rate sensitivity, ops effort, where Grafana Cloud's open-source posture wins, and where Sutrace's tighter integration wins.
Sutrace vs Grafana Cloud
TL;DR. Grafana Cloud is the managed version of the open-source LGTM stack — Loki, Grafana, Tempo, Mimir. It's the right answer for teams that value the open-source posture, the broader community, and the willingness to compose four products into one observability solution. Sutrace is tighter — fewer moving parts, fewer pricing dimensions, EU-default residency, and cardinality cost attribution as a first-class feature. Both are honest products; the right pick depends on whether you want composability or convenience. If you've already operationalised Prometheus and you want to keep the LGTM stack metaphor, Grafana Cloud is the natural managed step. If you're starting fresh on OTel, Sutrace is the simpler path.
Side-by-side
| Dimension | Grafana Cloud | Sutrace |
|---|---|---|
| Storage backends | Loki (logs), Tempo (traces), Mimir (metrics) | Single ClickHouse-backed store |
| Query interface | Grafana — best-in-class dashboarding | Bundled UI; Grafana datasource also works |
| Metrics pricing | DPM-rate sensitive (data points per minute) | Flat ingest tier, cardinality tracked |
| Logs pricing | Per-GB ingest, per-GB retention | Per-GB ingest, single tier 30d hot |
| Traces pricing | Per-GB ingest, per-GB retention | Bundled in ingest tier |
| EU residency | Available, requires EU instance selection | Default — europe-west3 (Frankfurt) |
| Open source posture | LGTM stack is OSS; SDKs are upstream | Not OSS; OTel SDKs are upstream |
| Self-host option | Yes (LGTM stack itself) | No |
| OpenTelemetry support | Native (OTel-native ingestion across LGTM) | OTel-native; OTLP is primary protocol |
| Industrial signals (PLC/SCADA) | Not native | Native |
| AI agent observability | Add-on / partner integrations | Native, included |
| Alerting defaults | Grafana-native, retune-heavy | Tuned-by-default |
The DPM-rate pricing surprise
Grafana Cloud's metrics pricing has caught teams off guard more than any single dimension of any commercial observability vendor. The pricing axis is DPM — data points per minute — and it is not the same as series count or sample count.
If you have a metric scraped at 15-second intervals, that's 4 DPM per series. If you have 100,000 active series at 15s scrape interval, that's 400,000 DPM. Grafana's pricing page and the active-series-vs-DPM clarification posts on their docs walk through the math, but it's a non-obvious axis the first time you encounter it.
Two consequences:
1. Scrape interval matters as much as series count. Halving your scrape interval (15s → 30s) halves your DPM and halves your bill, with negligible loss of resolution for most use cases. This is the biggest cost-control lever Grafana Cloud customers don't always pull.
2. Recording rules can multiply DPM. Each recording rule produces new metrics that are themselves billed. A rule that pre-aggregates 100 series into a single low-cardinality metric reduces DPM if you delete the originals; if you keep both, DPM goes up.
We're not arguing this pricing is wrong — it's a reasonable model. We're arguing it has a learning curve, and the learning happens during the second invoice.
Sutrace's metrics pricing is per-GB-of-ingested-OTLP-payload, which is a single axis. Cardinality is tracked separately and capped on a per-service budget; it's not a billed dimension. Whether this is "better" depends on your shape — if you have low-volume but high-DPM-per-series workloads (high scrape rate, low cardinality), Grafana's DPM model can be cheaper.
Ops effort
Grafana Cloud is managed, but the data model is the LGTM stack — four products that compose. The composition is mostly hidden behind the UI, but you'll notice it in a few places:
- Logs and traces use different query languages (LogQL vs TraceQL) than metrics (PromQL).
- Cross-signal correlation (logs ↔ traces ↔ metrics) requires explicit linking via trace IDs.
- Long-tail features (continuous profiling via Pyroscope, frontend monitoring via Faro) are separate products under the same umbrella.
This is the cost of composability. The benefit is that each component is best-in-class for its data type, and the underlying OSS posture means you can move data out at any time.
Sutrace is one product with one query interface, one storage layer (ClickHouse), and one set of conventions. The cost is that we don't have separate products you can swap in for sub-needs. The benefit is that the cross-signal correlation is automatic — every span includes its associated metric/log/event in the UI without you wiring trace IDs around.
EU residency — the regulatory case
Grafana Cloud offers EU-region instances. They have to be explicitly selected per stack at provisioning. Cross-stack queries can route through US infrastructure depending on configuration.
Sutrace is EU-default. Frankfurt (europe-west3). Backups stay in-region. Support staff access is region-restricted and logged. If your compliance posture requires "data and operations both in EU," our default is the lower-effort answer; Grafana's EU posture is achievable but requires deliberate configuration.
For DACH/Nordics teams in particular this is the most common reason teams choose us — not the price, not the features, but the residency-by-default story. The Sutrace OTel use-case page covers the residency commitment in detail.
When Grafana Cloud wins
1. Open-source posture is a hard requirement. The LGTM stack is OSS; the SDK ecosystem is OSS; the storage formats are OSS. If you're values-aligned with OSS-first observability, Grafana Cloud is the natural managed answer.
2. You're already deep in Prometheus. Migrating Prometheus to Mimir is a configuration change. Migrating Prometheus to anything else is a re-instrumentation. Grafana Cloud is the lowest-friction managed step from a self-hosted Prometheus team.
3. Dashboarding is your primary use case. Grafana is the gold standard for dashboards. Our UI is good; Grafana's is better. If your team lives in dashboards, the Grafana experience matters.
4. You have an SRE team that wants tunability. Grafana Cloud exposes more knobs, more tunable storage tiers, more recording-rule configuration. If your team enjoys this kind of work, you'll get more out of Grafana Cloud than a more-opinionated tool.
5. The community matters. The Grafana community is enormous. Plugins, dashboards from the marketplace, integrations contributed by other teams. Sutrace is a smaller community; we ship what we ship.
For the broader argument about composable LGTM stacks, see the OpenTelemetry protocol-war pillar — Grafana sits in category 3, vendor-neutral storage stacks, in that taxonomy.
When Sutrace wins
1. EU residency is the table stakes. Default-EU vs configured-EU is a meaningful difference for some compliance postures.
2. Cardinality is your cost concern. Cost attribution before ingest is our wedge. Grafana Cloud's DPM-rate model exposes you to a similar dynamic via a different axis; ours surfaces it earlier.
3. You want one product, not four. If you'd rather not learn LogQL, TraceQL, and PromQL, our single query layer over a unified store is simpler. The trade-off is fewer specialist features per signal type.
4. Mixed signal types — hardware + AI agents in addition to software. PLC/SCADA via OPC-UA, LLM cost/latency via OTel auto-instrumentation. Native, not bolted-on. See the OTel backend page for the architecture.
5. Tuned alerting defaults. Grafana's alert defaults are mostly empty (you write your own); ours are five-rules-shipping-as-defaults. If you don't have time to write alerts, our defaults are the head-start.
Pricing comparison — the directional answer
Without naming numbers (both vendors update pricing), the directional shape:
- Low DPM, high cardinality: Sutrace usually cheaper.
- High DPM, low cardinality: Grafana Cloud often cheaper at scale.
- Heavy log volume: roughly equal; depends on retention requirements.
- Heavy synthetic monitoring: Sutrace usually cheaper (we bundle).
- Mixed signal types (industrial + software + AI): Sutrace cheaper (no add-on SKUs).
- You already run Mimir/Tempo/Loki self-hosted: Grafana Cloud cheaper to migrate to.
The honest move is to model both with your actual workload. Both vendors have free tiers; a two-week parallel-write evaluation costs you a Friday afternoon of OTel Collector configuration.
What we won't do
- We will not match Grafana's dashboarding UX feature-for-feature. They have a 10-year head start.
- We will not pretend Grafana Cloud is more expensive than us across the board. Some workloads it's cheaper.
- We are not OSS. If self-host is mandatory, SigNoz is closer to Grafana's posture than we are.
What to do next
- Run both free tiers in parallel for two weeks. OTel Collector fan-out, same data into both. Compare dashboards, alerts, query latency.
- Model the bill on real workload. Take last month's metric/log/trace volume, plug it into both pricing calculators.
- Decide on your team's posture: composable or unified. This is the actual question. Pricing follows.
The protocol-war pillar and the OTel backend page are the related reads. The pricing page is the next tab.
Closing
Grafana Cloud and Sutrace are both legitimate answers to "we want OTel-native managed observability." Grafana wins on composability and OSS posture; Sutrace wins on EU residency, cardinality control, and unified-product simplicity. Pick the one whose shape matches yours. We'd rather you stay on Grafana Cloud than switch to us with the wrong reasons.