Every "which LLM observability tool?" comparison eventually turns into a feature-checklist beauty contest — this dashboard vs that one, this integration count vs that one. That framing hides the only distinction that changes your decision: what unit the tool was built around. Langfuse grew up around the LLM call. Laminar was built around the agent run. If you know which of those describes your product, you already know most of the answer.

The dividing line#

A single LLM feature is a straight line: prompt in, completion out. Log it, grade it, done — and Langfuse does that beautifully, with the most mature tooling in the category.

An agent is a tree: it plans, calls a tool, reads the result, retries, maybe spawns a sub-agent, then answers. Its worst failures don't live inside a call — they live between the calls. The agent loops. It picks the wrong tool. It silently retries four times. Every individual call returns 200 OK, and a completion-shaped tracer shows you four tidy green rows and no problem. Laminar is built for that tree, and it adds two things a generic tracer doesn't frame the same way.

An agent's worst failures don't live inside a call. They live between the calls — and that's exactly where a completion-shaped tracer stops looking.

What Laminar adds#

Plain-English signals. You describe the bad behavior in a sentence — "the agent is stuck in a loop," "it called the same tool five times" — and Laminar watches for it and pings you, e.g. in Slack, when it fires. Compare that to the usual path: notice latency is up, design a metric, build a chart, set a threshold. Signals collapse that into one written sentence.

SQL over your traces — including via MCP. You can query traces, spans, metrics, and events with SQL from the CLI, or expose that query surface through an MCP server so your coding agent investigates a production incident by writing queries against your telemetry. That closes a loop the tracing-MCP-tool-calls crowd will recognize: the agent that generated the traces can now read them.

The rest is table stakes done well: OpenTelemetry-native auto-instrumentation of the OpenAI/Anthropic/Gemini SDKs, LangChain, the Vercel AI SDK, and browser agents; an evals SDK/CLI; Rust under the hood for fast full-text search. It's Apache-2.0 — no enterprise-folder carve-out — and it's the newest tool here (YC S24).

What Langfuse keeps#

Maturity is a feature, and Langfuse has the most of it: the biggest ecosystem, the widest adoption, first-class prompt management (versioned prompts, datasets, experiments — genuinely stronger than Laminar's lighter take), and one of the most generous free tiers in the category. It's MIT-licensed except its ee/ folders, and it was acquired by ClickHouse in January 2026, which so far has kept the license and pricing intact. If your pain is "I need to version a prompt without a deploy and prove a change helped," Langfuse is the more finished answer.

The pricing shape (verify the numbers)#

The structural difference matters more than the exact dollars, which move every quarter — check each pricing page before you commit. Langfuse prices on usage units with a large free Hobby tier. Laminar prices on data volume rather than per seat, so adding a teammate doesn't raise the bill. Both self-host for free. Treat specific figures as "as listed today," not gospel.

The reversibility clause#

Here's the part that lowers the stakes: both are OpenTelemetry-native. If you instrument your app with OTel rather than a vendor SDK, you can re-point your telemetry from one to the other later without touching application code. The switching cost is real — dashboards, saved queries, and signals don't migrate — but it isn't a rewrite. So this is a bet you can revise, not a marriage.

The call#

For the broader field — including LangSmith's LangChain-native path and Phoenix's eval-first design — see Langfuse vs LangSmith vs Phoenix.