At some point in almost every project, the question comes up whether a commercial APM or an open-source stack is the right choice. One part of the team wants to go with the open-source option because, after all, it’s free. A few meetings later, another team in the same company simply doesn’t want to run anything themselves and would rather buy something ready-made. Both believe they’re debating open source versus commercial, when in fact they’re debating something else entirely and don’t realize it.
Starting Point: Both Sides Seen From the Inside
We’ve spent the last few years on both sides. For years as a subcontractor around AppDynamics, at more than thirty companies across EMEA, often at a new site each week. In the projects that followed, increasingly in the LGTM stack — Loki, Grafana, Tempo, and Mimir — plus OpenTelemetry for instrumentation.
We know the glossy dashboards from the vendor demo, and we know the feeling of debugging an ingester at three in the morning that has stopped accepting data. From that dual perspective, the "open source versus commercial" axis is the wrong one. The real question is: run it yourself or buy the convenience.
What a Commercial APM Takes Off Your Plate — and What It Doesn’t
A commercial APM isn’t just "expensive but ready-made." It takes over running the backend, the scaling, the updates, support with a phone number, and — with the major vendors — an agent that makes Java or .NET applications visible down to the method level without configuration. What it does not take off your plate is understanding your own system.
We’ve seen enough projects where the expensive product delivered no value for months because no one knew which questions it was supposed to answer. A contract with Datadog or AppDynamics doesn’t replace an inventory, prioritization, or a naming convention. And it doesn’t answer the question of where the data lives and who can access it; that belongs at the start of the architecture, not in a review three months before go-live.
What’s Actually Free About a Self-Operated Stack
The "it’s free" decision is a story many teams tell themselves. Grafana costs no license. Operating it costs people. The ingester that falls over at night costs people. The retention policy no one configured eventually costs you a surprising storage bill — just not from the vendor, but in your own cloud.
The only thing that’s free about the stack is the software, nothing else. A self-operated LGTM stack needs people who understand the Prometheus data model, who know why cardinality is a problem — that is, the number of distinguishable time series that drives storage and query time — and who can scale a Loki cluster. With two such people on the team, it’s doable. With a team whose primary job is to ship product features, you create a second full-time job that nobody wanted.
For the LGTM stack, operating it concretely means: upgrades for four components, retention and compaction in object storage, capacity planning for ingesters and queriers, being on call in case ingestion stalls, and monitoring for the monitoring itself. Anyone who doesn’t plan for this hasn’t saved money — they’ve just deferred the bill.
How We Ground the Operating Decision
When a customer asks us what to choose, we don’t give a product recommendation until four things are clear. First, team and know-how: who will operate the stack in two years, not who is enthusiastically building it today. Second, compliance and data sovereignty — more on that shortly, because it’s often the deciding criterion.
Third, the criticality of the system. With an internal tool you can experiment; with a payment system on a 24/7 SLA you want support you can call, not a GitHub issue that’s been open for eight months. Fourth, team structure: with fifteen teams, the operating model matters more than the tool, because someone has to enforce standards and ensure comparable instrumentation.
What’s deliberately missing from this list is price as the first criterion. It comes last, and it rarely looks the way it appears on the first invoice. The license of a commercial product is one line in the quote; the staffing costs for self-operation are spread across three cost centers and show up in no comparison until someone adds them together.
Data Sovereignty Often Ends the Debate Before Features Even Matter
At one customer in a regulated environment with European data, features were discussed for weeks: which product correlates traces better, who has the nicer interface for distributed tracing. When the question came up of where the telemetry data physically resides and who theoretically has access, a whole range of SaaS offerings was out in one stroke.
Observability data isn’t harmless. Traces contain URLs, sometimes parameters, sometimes identifiers; with poor discipline, logs occasionally contain a token or an email address. Anyone who dumps that into a SaaS outside the EU is making a data-protection decision, whether they want to or not. This is exactly where the balance often tips toward self-operation in practice — not out of ideology, but because "in our own data center" is non-negotiable for some customers.
The filtering in the collector that limits this risk is described in the build-or-buy article in this series; here it’s enough to note that it works independently of the backend and therefore rules out neither option.
OpenTelemetry Makes the Backend Decision Reversible
In most discussions, OpenTelemetry gets filed under "the open-source thing," as if it belonged to the Grafana camp. That’s a mistake in thinking. OpenTelemetry isn’t a camp — it’s the standard that tears down the wall between camps: the application is instrumented once and doesn’t know where the data ends up. The collector decides that, via configuration.
How reversible this is becomes clear from a collector configuration that sends the same traces in parallel to a self-operated Tempo and to a commercial vendor. This lets you evaluate a product for weeks with real data without shutting down your own stack, and the way back is a deleted line. The configuration applies to OpenTelemetry Collector 0.128 and Grafana Tempo 2.8:
receivers:
otlp:
protocols:
grpc:
endpoint: ${env:MY_POD_IP}:4317
processors:
batch: {}
exporters:
otlp/tempo:
endpoint: tempo-distributor.observability:4317
tls:
insecure: true
otlphttp/anbieter:
endpoint: https://<OTLP-ENDPUNKT-DES-ANBIETERS>
headers:
Authorization: "Bearer <API-TOKEN>"
service:
pipelines:
traces:
receivers: [otlp]
processors: [batch]
exporters: [otlp/tempo, otlphttp/anbieter]The OTLP/HTTP exporter only needs the vendor’s base URL; the header with the access token comes from the collector’s shared HTTP client settings. The receiver binds to the pod IP from the environment variable MY_POD_IP, exactly as the collector’s official Helm chart prescribes. A pipeline may deliver to multiple exporters, each getting the same data. If the decision goes to the vendor, otlp/tempo disappears from the list; if it goes the other way, otlphttp/anbieter disappears. In both cases the application code remains untouched.
What Changes When Instrumentation Stays Neutral
We’ve seen customers with proprietary agents wired deep into the code, in every class. There, switching products meant re-instrumenting everything, over months. With OpenTelemetry as the instrumentation layer, the decision for a backend has become reversible: start small, change your mind later, even feed two backends in parallel — for example, keeping metrics cheaply in-house and traces with a vendor that does the interface better.
We won’t quote numbers for the effort of a switch, because they depend on the codebase and don’t transfer. Qualitatively, the separation is unambiguous: it turns a matter of faith into a sober operating decision that can be revised when team, budget, or oversight change. The parallel export turns product evaluation into a test run with your own data instead of a slide deck, and the rollback is a single line in the collector configuration.
Where OpenTelemetry Still Hits Its Limits
OpenTelemetry is still rough in places. Automatic instrumentation is at varying levels of maturity depending on the language, configuring the collector can get fiddly, and a highly optimized commercial agent still delivers deeper insight without configuration effort for certain languages and frameworks. Anyone who wants maximum automation is sometimes faster to the goal with a ready-made agent. This is a maturity issue that shrinks every year, but it’s still real today.
The parallel export also doubles the network traffic and the batch buffers in the collector, and it assumes the vendor accepts OTLP natively. Vendors with their own ingest format need a specific exporter from the contrib distribution, which doesn’t map every semantic one to one. Sampling decisions also have to apply equally to both destinations, otherwise you’re comparing two different data sets. And the reversibility applies to the data, not to the work built on top of it: dashboards, alert rules, and team habits don’t migrate automatically when you switch backends.
The Takeaway: The Question Is Operate or Buy
Operate it yourself or buy is the question that actually has real stakes: cost, responsibility, data sovereignty, night shifts. "Commercial APM or open-source stack" is just the packaging in which that question usually arrives. Anyone who instruments with OpenTelemetry separates the generation of data from its processing and can swap the packaging later.
We’ve seen good projects on both sides and total write-offs on both sides; the difference was never the logo on the dashboard, but the honest assessment of the operating model. It’s exactly that assessment we work out with customers before a product name is ever mentioned.