Managed vs self-hosted LLM observability
The Currai team, Product — Mar 30, 2026
Every team that gets serious about LLM observability hits the same fork: run the storage and ingestion yourself, or let someone else operate it. The honest answer isn't "managed always wins" — it's that the trade-off is about where you want to spend your engineering time.
What self-hosting actually means
Observability data is high-volume, append-heavy, and queried in wide analytical scans — the workload columnar stores like ClickHouse are built for. Self-hosting means you own:
- An ingestion tier that absorbs bursty trace traffic without dropping spans.
- A columnar store tuned, sharded, and backed up for trace and span queries.
- The dashboards and search layer on top, plus the on-call rotation when the cluster falls behind at 3am.
None of that is exotic, but all of it is real, ongoing work that has nothing to do with your actual product.
The case for self-hosting
It's a legitimate choice when:
- Data residency is a hard requirement and the data physically cannot leave your environment.
- You have a platform team that already runs this class of infrastructure, so the marginal cost of one more cluster is low.
- Your volume is enormous and at some scale operating it yourself is cheaper than paying per byte.
The case for managed
For most teams shipping an LLM feature, the storage layer is undifferentiated heavy lifting. A managed backend means you write the instrumentation and watch the data — ingestion, columnar storage, and dashboards are someone else's pager.
Keep the exit door open
The strongest position is portability regardless of which side you pick. Instrument against an open standard — the Langfuse SDK and OpenTelemetry — so your trace code isn't welded to one backend. Then "managed vs self-hosted" stops being a one-way door and becomes a decision you can revisit as your volume, your team, and your compliance needs change.
currai