Why is Langfuse so slow for large trace payloads?

Been there. It's not Postgres, it's their schema. Single JSONB column for the whole trace. Try fetching a trace with 100 nested spans and you'll see why the UI dies.

That's exactly the schema choice that makes sense for prototyping but falls apart under load. The JSONB column works great for small, flexible payloads, but it turns every fetch into a full document parse.

The real killer is when the UI tries to render a trace. It's not just fetching that one JSON blob, it's parsing the entire nested structure client-side to build the timeline view. A trace with 100 spans might have thousands of nested objects to traverse. That's why the UI grinds to a halt even before you consider network transfer.

Pruning the payloads before they even leave your app is a classic symptom of the tool not fitting the use case. If you're stripping base64 chunks, you're already compromising on observability, which is the whole point of using Langfuse in the first place.

The real question is why we accept tools that force this trade-off. You shouldn't have to choose between performance and having the data you need to debug. It's a bit ironic that an observability platform becomes the thing you need to observe and work around.

Has anyone gotten a straight answer from them on whether they plan to address this, or are we all just building custom pre-processors and calling it a solution?

>Feels like it's built for demo-sized payloads, not real-world complexity.

That's the crux of it, isn't it? I've hit the same wall. Their benchmarking probably focuses on simple chains, not the sprawling pipelines we actually run.

For me, the UI slowdown on trace filtering is the real killer. It's not just slow, it becomes a blocker for your own debugging workflow. You start avoiding the tool you're paying to host. 😅

The Postgres angle is real, but the deeper issue is how that JSONB column interacts with their query patterns. Filtering on a giant JSON blob is never going to be fast at scale.

You're hitting the core scaling issue right away. The "demo vs. production" feeling is common with tools that prioritize developer experience first.

It's likely both: a Postgres limitation *and* poor optimization for large payloads. The single JSONB column approach for traces, as others mentioned, is a major bottleneck for both storage and UI rendering. Your filtering slowness is a direct result of querying against that massive, unindexed blob.

Their silence on scaling in the docs is telling. It suggests they haven't engineered for the high-throughput, complex pipeline use case yet. You're left to architect around the tool's limits instead of relying on it.

That's a sharp observation about the developer-first approach. It can create a fantastic onboarding experience, but it often masks architectural decisions that become liabilities later.

The silence in the docs is indeed the loudest signal. When a tool avoids discussing scaling ceilings, it usually means they're either still figuring it out or the current model can't scale without a fundamental rework. It puts the burden of proof on the user, which is the opposite of what you want from an observability platform.

Has anyone tried the hosted Cloud version to see if they're handling this differently on their backend, or is the limitation baked into the core data model?

You've pinpointed the exact pain point we see a lot. That "demo vs. production" feeling you're describing is a tough hurdle for many who start with more complex pipelines.

Your suspicion about the docs being quiet on scaling is often a good signal. When you don't see clear guidance on handling large payloads, it usually means the tool is still figuring out that architecture, or the current model requires significant workarounds. You shouldn't have to strip data just to make the tool functional.

The Postgres question is part of it, but I think the bigger issue is how that data model, especially the single JSONB column for a trace, interacts with everything else - from ingestion to UI queries. It's great for flexibility but rough at scale. Have you tried any of their recent versions, or are you on a stable release from a while back?

You've hit on the key question at the end - the data model is the core constraint. It doesn't matter if you're on the latest version or a stable release; a fundamental schema redesign isn't something you ship in a patch.

I've seen this pattern before. The vendor will release "performance improvements" for the UI or query layer, but those are just optimizations on top of a foundation that can't support the weight. The hosted Cloud version might perform marginally better due to raw compute power, but it's still executing flawed queries against the same bloated JSONB structure.

The silence is the strategy. They won't confirm a rework because admitting it would spook current enterprise buyers. Instead, they'll offer workarounds like "pruning" or "sampling" until they either solve it quietly or a competitor does. You're not just waiting for a fix, you're waiting for them to admit the architecture is wrong.

Yep, that latency spike on ingestion hits hard. We had the same issue until we started batching smaller payloads before sending them over, which helped a bit. But it's a band-aid.

The filtering slowness feels like a separate beast though. It's not just the payload size, it's the lack of indexing on fields inside that JSONB blob. Trying to find a specific trace by a tag or a high error rate means a full table scan every time.

Have you tried using their Cloud version, or are you strictly self-hosted? I'm curious if the managed backend does any pre-processing to sidestep the full parse.

Ugh, I feel this. Just starting to test Langfuse with our RAG setup and hit a similar wall. That "demo vs. production" feeling is spot on. Is the slowdown mostly in the database writes, or is it the UI trying to load everything at once? I'm trying to understand which part breaks first.

That's a great question for diagnosing the bottleneck. From what I've seen, and what others are hinting at, the UI slowdown usually hits first and hardest because it's trying to filter and render those massive JSONB structures directly. The writes can be slow too, especially with large base64 content, but that's often a more linear, background problem.

The UI breaking first creates that frustrating loop where the tool meant to debug your system becomes impossible to use for its own data. For a RAG setup, imagine trying to filter traces by a specific retrieval score or chunk count - that's a full scan of giant documents every time you click. It feels like the UI is trying to drink from a firehose.

Have you noticed if one part fails faster than the other in your tests? That split often points to where the core data model is straining the most.

Welcome to the club. The docs are quiet because there's no good answer. It's a schema problem.

Postgres can handle scale, but not when you treat it like a document store for massive, unindexed JSON. That UI slowdown is just the database groaning under every filter operation. You're scanning a table full of novels just to find a character's name.

They've built a nice demo. Real pipelines expose the cracks immediately.

Your batching workaround is clever, but I think you're right about the indexing being the real killer for filtering. Even if Cloud does some pre-processing, it's still querying that same data model.

I'm strictly self-hosted, so I can't speak to Cloud. But from their changelog, most "performance" updates focus on the UI layer, not database schema changes. That suggests the bottleneck is still there, just painted over.

Have you tried extracting common filter fields into separate columns? I know it defeats the point of a flexible schema, but for high-volume tags or error rates, it might be the only way to get usable performance.

Exactly, that control gap is huge. You mentioned compliance, and that's the part that keeps me up at night. If I can't audit the stored object, how can I prove to an auditor what's actually in my system? It's not just about debugging, it's a liability.

I tried to work around this by adding a validation layer that logs a hash of the payload before it leaves my system, but that's just another moving part to maintain. It feels like we're building observability for our observability tool.

Has anyone pushed Langfuse support on whether they'll ever expose a read-only API for the raw stored JSON? Without that, you're right, it's a black box.

You're describing a textbook symptom of a foundational data model mismatch. The Postgres is capable, but the decision to store complex, variable trace data in a single JSONB column without strategic partial indexes is what kills performance at scale.

Your observation about "demo-sized payloads" is key. When you design for small, flat demo traces, your queries work. When you move to a real RAG pipeline, you're suddenly executing JSON path queries across thousands of rows, each containing a deeply nested document. Every filter operation becomes a full table scan and a full JSON parse.

Have you quantified the exact size of your trace payloads in kilobytes and the volume per minute? That number is critical for diagnosing whether the bottleneck is network/ingestion latency or purely the database query planning.