ClickHouse acquired Langfuse in January. Nothing has broken, prices have not jumped, and nobody has been forced onto a new plan. That is exactly why it is worth thinking about now, while a decision is still cheap. Honest about every option, including staying.
ClickHouse acquired Langfuse in January 2026. It was one of three acquisitions in the LLM observability layer inside about five months: Mintlify acquired Helicone in March, and Cisco acquired Galileo in May and folded it into Splunk Observability.
The pattern is not that LLM observability is a bad business. It is that it is turning out to be a feature of a larger platform rather than a standalone one. Storage companies want the workload. Documentation companies want the developer surface. Observability giants want the category before it becomes a gap in their offering.
For Langfuse specifically the fit is unusually tight, because it already ran on ClickHouse. This is less an acquisition of a competitor than a company buying the most prominent application built on its own engine. That tends to be a good sign for continuity of the core and a mixed one for everything around the edges.
The honest read: this is one of the better positions an acquired product can be in. Langfuse is not on a glidepath, and anyone telling you otherwise is selling something.
Rarely the thing people worry about. The product does not get switched off, and prices do not usually double the following quarter. Three subtler things happen instead.
None of that is a reason to leave. It is a reason to know which parts of the product you depend on.
Which features you actually use. Not which features you evaluated on. If you use tracing, storage and the UI, you are in the part of Langfuse most aligned with ClickHouse's interests, and the case for staying is strong. If your workflow leans on prompt management, dataset curation or annotation queues, those are further from the acquirer's core business and worth watching for pace.
Whether your data has anywhere else to go. Observability data has a short useful life, which is good news. Check that you can export what you would need for reporting, and be honest about whether you would ever read traces older than a month. Most teams would not.
What your instrumentation is coupled to. If your application calls a vendor SDK directly at every call site, you have a migration project. If it emits to an internal wrapper or an OpenTelemetry-compatible layer, you have a configuration change. This is the single biggest determinant of switching cost and the one most within your control, regardless of what you decide.
Whether self-hosting solves your actual objection. Langfuse is open source. If what bothers you is vendor risk rather than product fit, self-hosting removes most of that risk without a migration at all. The catch is that you inherit running a ClickHouse-backed system, which is real work at volume. Plenty of teams should take that trade and do not consider it.
Langfuse is good, and the acquisition arguably makes its core stronger rather than weaker. Being owned by the company that makes your storage engine is a better position than being owned by a company with no natural interest in your workload.
It is open source, which puts a floor under the downside that most commercial alternatives cannot offer, ours included. And if your usage is tracing-shaped, you are aligned with exactly the part of the product that has an internal champion at the new parent.
Switching costs are real and the benefits of switching are speculative. "Wait and watch the release cadence for the features you depend on" is a legitimate answer, and it is the right one for a lot of teams reading this.
We would rather you stayed on Langfuse and were right than moved to us and were wrong. A migration made for the wrong reason gets reversed.
Where we would think harder is if your problem was never really tracing.
A lot of teams adopted a tracing tool because it was what existed, and then discovered their recurring questions were economic rather than diagnostic: which customers are unprofitable, what drove the increase, did the nightly agent run at all. Those questions want cost attribution and freshness monitoring, and a tracing tool answers them awkwardly at best, because it is organised around steps rather than runs and business dimensions.
If that describes you, the acquisition is not the reason to move. It is a convenient moment to notice that you have been paying for step-level detail you rarely read while lacking the per-run economics you ask about weekly.
The architectural difference in one line: Langfuse records steps, AgentPing records runs. Step-level recording answers "what happened inside this specific run", which a summary cannot. Summary recording produces one or two orders of magnitude less data, which changes what it costs to leave on permanently across every agent you operate. Neither is better. They answer different questions.
If you do move, do not try to bring the history.
Run both in parallel for a few weeks, with the new tool wired in alongside the old rather than replacing it. Export whatever you need for long-term reporting into your own storage, which is usually a small aggregate table rather than raw traces. Then let the old data age out. Backfilling between tools with different data models costs more than the history is worth, and the history is read far less than anyone expects.
Do the decoupling work regardless of what you decide. An internal wrapper around your instrumentation calls is an afternoon, and it turns the next one of these decisions, and there will be a next one, from a project into a config change.
If the per-run economics angle in this guide matches your problem, running AgentPing alongside for a fortnight costs nothing and settles the question with your own data rather than anybody's blog post.
The shorter version of this guide → AgentPing vs Langfuse → Moving off Helicone →