Jason Lee

Posted on Aug 15

ClickHouse Owns Langfuse Now. It Was Already Running Helicone's Analytics, Too.

#llm #observability #opensource #devtools

On January 16, 2026, ClickHouse — the analytical database company — announced it had acquired Langfuse, the most widely self-hosted open-source LLM observability platform, as part of a $400M Series D that tripled ClickHouse's valuation to $15B. That's a big number on its own. The detail that should actually change how you evaluate this market is quieter: Langfuse's core data layer had already been running on ClickHouse since its v3 rewrite, because Postgres couldn't keep up with the combined write-heavy ingestion and read-heavy analytics that trace data demands. And if you go check Helicone's own architecture — a completely separate, competing observability product — its analytics layer runs on ClickHouse too.

So as of this year, if you're picking an LLM observability or eval platform, you're not just picking a dashboard and an SDK. You're picking who owns the storage engine underneath your trace data, and in at least one case, that owner is now also a direct competitor's parent company. That's a strange enough fact to be worth building a comparison around, so this piece looks at four platforms developers are actually choosing between right now — Langfuse, Helicone, Braintrust, and Arize Phoenix — through the lens of how they're actually built, not just their feature checklists.

Why this decision matters more than it used to

Eighteen months ago, "LLM observability" mostly meant wrapping your OpenAI calls in a logger and shipping the output to whatever APM tool you already had. That's no longer true. The market is now large enough to support dedicated vendors with real funding rounds, opinionated architectures, and (as of January) acquisitions — one market estimate puts LLM observability at roughly $2.69B in 2026, heading toward $9.26B by 2030. Two things forced the shift: agentic systems produce multi-step, multi-tool traces that a single request/response log line can't capture, and teams got burned often enough by silent quality regressions that "add an eval gate to CI" moved from nice-to-have to release-blocking requirement at a lot of shops.

That second shift is the more consequential one for how these products are built. A logging tool and an evaluation tool solve adjacent but genuinely different problems, and the four platforms below split cleanly along that line — plus a second line, proxy-based interception versus SDK/OpenTelemetry instrumentation, that has real consequences for latency, lock-in, and what happens when the vendor has a bad day.

What each one actually does

Langfuse is an open-source (MIT-licensed) LLM engineering platform for tracing, evaluating, and debugging LLM apps in production. It ships as both a managed cloud product and a self-hosted deployment, and per its own numbers it's genuinely widely deployed: more than 2,000 paying customers, 26M+ SDK installs a month, 6M+ Docker pulls, and usage inside 19 of the Fortune 50. Its strength is full-fidelity tracing with genuine data ownership if you self-host; its evaluation layer is more of a framework you assemble than a turnkey scoring product — you bring your own eval logic and wire it into Langfuse's pipeline rather than picking from a deep library of pre-built scorers.

Helicone takes the opposite approach to integration. Instead of an SDK you instrument through your code, Helicone is a proxy: you swap your API base URL, and every call to OpenAI, Anthropic, or one of 100+ other models routes through Helicone's gateway (built on Cloudflare Workers) before hitting the provider. That gets you logging, cost tracking, caching, and rate limiting with a one-line change and no code-level instrumentation. The tradeoff is architectural: Helicone now sits in the request path of every single model call your app makes, not just observing it after the fact.

Braintrust starts from the opposite end of the pipeline entirely — it's an eval-first platform where tracing is the secondary feature. You define datasets, write scoring functions, run comparison reports across model or prompt versions, and — the feature that most clearly explains its design center — wire evals into CI/CD so a regression can block a merge before it ships. Tracing exists to feed that eval loop, not as the primary product.

Arize Phoenix is the open-source (Elastic License 2.0) half of Arize AI's observability business. It's built natively on OpenTelemetry, runs as a single Python process for local/notebook use, and scales to Docker or Kubernetes for production. It ships 50+ pre-built LLM-as-judge evaluators (hallucination, relevance, toxicity, QA correctness, faithfulness) that you can run ad hoc in its UI or as part of a CI pipeline via its Python eval API, plus dataset management and a prompt playground. Storage defaults to SQLite — genuinely zero external dependencies for dev use, handling millions of spans — and you swap in Postgres for production workloads north of 10M spans/day.

How each is actually built — and why the architecture matters more than the feature list

The proxy-versus-SDK split is the single most consequential design decision in this space, and it's usually buried three paragraphs into a features page instead of being the headline it should be.

Helicone's proxy model is the most operationally invasive of the four, by design. Every model call your app makes travels through Helicone's Cloudflare Worker before it reaches OpenAI or Anthropic. The upside is real: you get observability, caching, and a unified multi-provider gateway without touching your instrumentation code, and Helicone claims under 5ms P95 latency overhead for the added hop. The downside is just as real and rarely gets equal billing — Helicone is now a dependency in the critical path of every inference call. If its proxy has an outage, you don't just lose observability, you lose the ability to reach your model provider at all, unless you've built a fallback path that bypasses the gateway. SDK-based tools fail open by comparison: if Langfuse, Braintrust, or Phoenix's ingestion endpoint goes down, your traces stop arriving, but your app keeps calling the model provider directly and keeps working.

Langfuse, Braintrust, and Phoenix all instrument at the SDK or OpenTelemetry layer, but they diverge on portability. Phoenix is OTel-native from the ground up, which means the traces it captures are standards-compliant spans you can route to any OTel-compatible backend — Jaeger, Honeycomb, Grafana Tempo, Datadog — without rewriting instrumentation if you migrate off Phoenix later. Langfuse and Braintrust use their own SDKs with OTel integrations available, but the deeper you build (prompt versioning in Langfuse, scoring functions and datasets in Braintrust), the more of that logic lives in a format specific to that vendor's API, not a portable open standard. That's not necessarily the wrong tradeoff — vendor-specific APIs are usually how you get vendor-specific depth — but it's a real cost that "just add a decorator" onboarding pitches don't surface.

Storage backends tell a similar story about who's making the infrastructure bet for you. Langfuse migrated to ClickHouse specifically because Postgres couldn't handle simultaneous high-throughput ingestion and fast analytical reads at scale — a real, defensible engineering decision, and one Helicone independently arrived at for its own analytics layer (Helicone's stack layers Supabase for auth/relational data, ClickHouse for analytics, and Minio for object storage, behind a Node/Express collector they call Jawn). Phoenix, by contrast, defaults to SQLite specifically to avoid forcing an external database dependency on you until you actually need one, graduating to Postgres only at real production scale. That's a meaningfully different philosophy: Langfuse and Helicone assume you'll eventually need ClickHouse-grade analytics and build around that assumption from day one; Phoenix assumes you probably won't, until you demonstrably do.

What changed, concretely

Three things moved in the last year that make this comparison timely instead of evergreen.

First, evals moved from a UI you check manually into a CI gate that blocks deploys. Braintrust's whole pitch is built around this: run your eval suite against a new prompt or model version as part of your pipeline, and fail the build if scores regress, the same way you'd fail a build on a broken unit test. That's a meaningfully more mature posture than "look at a dashboard after you ship," and it's pulling the other platforms toward CI-native eval APIs too — Phoenix's phoenix.evals is explicitly designed to be called from a pipeline, not just a notebook.

Second, the proxy-gateway pattern consolidated around a few winners instead of staying a fragmented list of homegrown reverse proxies. Helicone's pitch of "swap your base URL, get logging, caching, and a 100+ model gateway" is a genuinely different value proposition than "instrument your code for traces," and it's captured a specific segment: teams who want cost visibility and multi-provider routing more than they want deep eval tooling.

Third — and this is the one most write-ups are missing — the acquisition wave has started. ClickHouse buying Langfuse is the first case of an infrastructure vendor buying an observability company built on top of its own product, and it won't be the last consolidation in a market this hot. That matters for a decision you're making today because the vendor's independence, roadmap incentives, and even its choice of default database are no longer static facts — they're now subject to whoever the acquirer's incentives are. It's also worth naming the elephant that isn't in this specific comparison: LangSmith, LangChain's own closed-source observability product, remains the dominant default for teams already standardized on the LangChain framework, precisely because it ships as part of the same vendor relationship. That's a fifth architectural camp — "bundled with your orchestration framework" — that trades independence for zero-integration-decision convenience, and it's the implicit alternative every one of these four is competing against for teams who haven't already picked a framework-agnostic stack.

Why the ClickHouse thread specifically matters

It's worth being precise about what actually changed for Langfuse users on January 16, because "an infrastructure vendor now owns an app-layer product built on its own database" has mechanical consequences beyond brand trust. ClickHouse Inc. now has three separate revenue motives sitting in the same building: selling ClickHouse Cloud to anyone who needs an analytical database, selling Langfuse Cloud to anyone who needs LLM observability, and — new as of this deal — an incentive to make sure Langfuse's own backend stays the flagship reference deployment for ClickHouse at scale. None of those motives are hostile to Langfuse's existing users, and the GitHub discussion thread announcing the deal is explicit that support channels, SLAs, and the self-hosted path are unchanged. But it does mean a future architectural decision — say, evidence that a different storage engine would serve some workload better — now has to clear a bar that includes "does this make the parent company's own product look worse," which is a bar that didn't exist for an independent Langfuse. Helicone's independent choice to also build its analytics layer on ClickHouse is a useful sanity check here: it suggests ClickHouse's fit for this exact workload is a real technical merit, not just a Langfuse house preference, which is the more charitable and probably more accurate reading of why this acquisition happened in the first place — ClickHouse buying a proven, high-volume reference customer rather than a database company buying a captive audience.

Cost, latency, lock-in, security, maintainability — the parts marketing pages gloss over

Cost. Langfuse's paid tier (Core) starts around $29/month with a real free tier below it, plus the option to self-host for the cost of your own infrastructure — genuinely the cheapest entry point of the four if you have anyone on staff who can run a ClickHouse-backed Docker/Kubernetes deployment. Braintrust's Pro tier runs about $249/month, positioned well above Langfuse but still transparent; enterprise pricing for both is opaque, as usual. Helicone is usage-based and, because it's proxying live traffic rather than metering trace ingestion, typically lands in the $300-600/month range at moderate scale — though its own caching can claw back 20-30% of that by cutting redundant model calls, which is a genuinely unusual case of an observability tool partially paying for itself. Phoenix is free and open source for the local/self-hosted path; the cost shows up later, when you outgrow the OSS feature set and get funneled toward Arize's commercial enterprise product (Arize AX) for org-wide RBAC, SSO, and alerting — a classic open-core funnel, just less obvious than Langfuse's because there's no external acquirer headline attached to it yet.

Latency. This is Helicone's real tradeoff, not just a footnote. A <5ms P95 proxy hop sounds negligible until you remember it's added to every single model call, including ones already taking several seconds — and unlike async SDK tracing, that hop is synchronous and in the request path, not a fire-and-forget log write. Langfuse, Braintrust, and Phoenix all report traces asynchronously; a slow or failing ingestion endpoint delays your dashboards, not your users.

Lock-in. Ranked from least to most locked-in based on what actually happens if you leave: Phoenix, because OTel-native spans port to other backends with minimal rework and the core tool is genuinely OSI-friendly-adjacent (Elastic License 2.0 is source-available, not a fully permissive OSI license, but the data format itself isn't proprietary). Langfuse next — MIT-licensed, self-hostable, and the acquisition announcement explicitly commits to "no licensing changes planned" — but the deeper your prompt management and eval pipelines go, the more vendor-specific API surface you're depending on. Helicone next, because while the SDK integration itself is trivial to remove, you've likely also routed live traffic through its gateway for caching and rate limiting, which is a bigger rip-and-replace than swapping a logging library. Braintrust is the most locked-in of the four by construction: the core platform is closed-source SaaS (only the client SDKs are Apache-2.0), there's no self-hosted path, and your regression-test logic — datasets, scoring functions, comparison baselines — lives entirely inside their platform. Leaving Braintrust later means rebuilding your eval suite somewhere else, not just changing where logs go.

Security. Helicone's gateway model means your API keys and every prompt/completion pass through a third party's infrastructure by default, which is a real conversation for any team with data residency or compliance constraints — it's a different risk profile than an SDK that ships trace data to a backend after the model call already completed directly with the provider. Langfuse and Phoenix's self-hosting options are the more straightforward answer for teams that need to keep raw prompt/completion data inside their own network entirely; Braintrust, being SaaS-only, sits closer to Helicone on this axis despite the very different architecture.

Maintainability. Self-hosting Langfuse or Phoenix at real production scale is not zero-ops. Langfuse's own positioning is candid about this: someone on your team needs to understand database performance and orchestration to run the ClickHouse-backed stack well, though post-acquisition that team can now presumably lean on ClickHouse's own operational playbooks — a genuine argument in favor of the deal, separate from the independence question. Phoenix's SQLite default keeps small deployments essentially maintenance-free, but that same simplicity means you're on your own for scaling guidance once you outgrow it and move to Postgres. Helicone and Braintrust, as managed SaaS-first products, take that operational burden off your plate entirely — which is the whole point of choosing a hosted product, but it's worth being honest that it's the same tradeoff as any other SaaS-versus-self-hosted decision, dressed up in LLM-specific vocabulary.

Practical use cases

Pick Langfuse when you're running a mid-to-large product with real compliance requirements — healthcare, finance, anything EU-adjacent — where prompt and completion data legally needs to stay inside your infrastructure, and you have the ops capacity to run a ClickHouse-backed stack. Its combination of genuine open source, real self-hosting maturity, and now a well-funded infrastructure parent makes it a defensible long-term bet for that profile specifically.

Pick Helicone when you're a smaller team, often single-provider (its pitch is strongest if you're mostly on OpenAI), and what you actually want is cost visibility, caching, and rate limiting more than deep evaluation tooling — and you're comfortable with a third party sitting in your inference path in exchange for a one-line integration.

Pick Braintrust when your team has already decided that eval-gated CI is non-negotiable and you want the deepest, most opinionated tooling for exactly that workflow — datasets, scorers, regression blocking — and you're fine being fully SaaS with no self-hosted exit ramp.

Pick Phoenix when you're already standardized on OpenTelemetry and want LLM traces to be first-class citizens alongside your existing infrastructure traces without adopting a second, incompatible tracing paradigm — or when you're doing local, notebook-driven experimentation before a product even has production traffic to observe.

Concretely: a three-person startup shipping a customer support bot on GPT models with no compliance obligations gets the fastest path to "we know what this is costing us and where the slow calls are" from Helicone, in an afternoon, without touching application code. A 40-person fintech team building an underwriting assistant that must keep prompt and completion data inside a VPC for audit reasons has essentially one honest answer among these four — self-hosted Langfuse — because Braintrust has no self-hosted path and Helicone's proxy model means routing sensitive data through a third party by construction. A platform team that's already invested in eval-gated deploys for their traditional ML models and wants the same discipline applied to prompts will get there fastest with Braintrust, because the CI-blocking workflow is the product, not a bolt-on. And a research-heavy team iterating on agent architectures in notebooks, well before there's a production SLA to defend, will get more signal per minute of setup from Phoenix's local-first, zero-external-dependency default than from any of the three hosted-first options.

An independent read

None of these four are lying in their marketing, but each is quiet about the part of the tradeoff that cuts against them. Langfuse's "no licensing changes planned" is true today and was stated in good faith by a team that's genuinely joining ClickHouse rather than being shut down — but it's a statement about intent, not a structural guarantee, and it's worth remembering that the same company now has a commercial incentive to keep Langfuse's default backend as ClickHouse specifically, not whatever turns out to be technically best in three years. Helicone's "5ms overhead" framing makes the proxy hop sound like a rounding error, without mentioning that a rounding error in the request path is a different risk class than a rounding error in an async log write. Braintrust's "eval-first" positioning is a genuine strength, but it undersells that you're building your regression-test suite's actual logic inside a platform you can't run yourself — that's a bigger commitment than picking a logging vendor. And Phoenix's "open source, runs locally" story is accurate for the exact use case it's demonstrated for — dev and small-scale — while quietly being the top of the same commercial funnel every open-core company runs, just without an acquisition headline making that structure visible yet.

The market-share and hype-cycle instinct is to ask "which of these wins." That's the wrong question for a tooling decision like this one. The right question is which failure mode you can live with: a synchronous dependency in your inference path, a closed-source eval suite you can't self-host, a database vendor with a new stake in keeping you on its own storage engine, or an open-source tool whose production-scale feature set nudges you toward its commercial sibling. All four are legitimate answers depending on your constraints — there isn't a universally correct one.

Comparison table

Dimension	Langfuse	Helicone	Braintrust	Arize Phoenix
Integration model	SDK / OTel tracing	Proxy (gateway swap)	SDK, eval-first	OpenTelemetry-native
License	MIT (open source)	Apache 2.0 (open source)	Apache 2.0 SDK only; core platform closed	Elastic License 2.0 (source-available)
Self-hostable	Yes, first-class	Yes (self-host option exists, less common path)	No — SaaS only	Yes, local to Kubernetes
Default storage	ClickHouse	Supabase (Postgres) + ClickHouse for analytics	Proprietary (closed)	SQLite (dev) → Postgres (production)
Eval maturity	Framework you assemble	Minimal — cost/logging focus	Deepest — datasets, scorers, CI regression gates	Strong — 50+ pre-built LLM-as-judge evaluators
Entry pricing	Free tier; Core ~$29/mo	Usage-based, ~$300-600/mo at scale	Free dev tier; Pro ~$249/mo	Free (OSS); paid via Arize AX enterprise tier
Latency profile	Async (fails open)	Synchronous proxy hop, <5ms P95 claimed	Async (fails open)	Async (fails open)
Ownership / backing	Owned by ClickHouse Inc. (Jan 2026)	Independent	Independent (VC-backed)	Arize AI (independent, own commercial tier)
Best fit	Compliance-heavy, self-hosting teams	Single-provider teams wanting zero-code cost/caching	Teams gating deploys on eval regressions	OTel shops, local/notebook-first workflows

Which reader should pick which option

If you're optimizing for data sovereignty and you have the ops budget to run infrastructure, Langfuse self-hosted is still the strongest case among the four, acquisition notwithstanding — the license commitment is real and the operational backing arguably just got stronger. If you're a small team on a single model provider who wants cost and cache visibility without touching your codebase, Helicone's proxy model gets you there fastest, provided you're comfortable with a gateway dependency in your request path. If eval-gated CI is the actual problem you're solving — not "can I see my traces" but "can I stop a bad prompt from shipping" — Braintrust is built around exactly that question more directly than the other three. And if you're already running an OpenTelemetry-based observability stack and don't want LLM traces to be a walled-off second system, or you're still in the experimentation phase before there's real production traffic to justify a hosted vendor, Phoenix is the natural default.

What none of these four fully solve yet, and what's worth watching over the next year: none of them give you an easy answer for what happens to your evaluation history and dataset lineage if you need to migrate between them later. That's the actual lock-in question underneath the license and pricing tables — not "can I export my traces" but "can I export my eval suite's judgment calls in a form the next tool can use."

If you've had to migrate observability or eval tooling for an LLM product in production — not a greenfield pick, an actual switch — what turned out to be the real cost: the SDK rewrite, or rebuilding the eval/scoring logic you'd already accumulated?

Sources:

DEV Community