I've been running Langfuse in production for about six months now, and I have a nuanced take that's been bothering me. While I agree their documentation is praised for the initial setup—getting the SDKs integrated, instrumenting your first prompts, and viewing traces in the UI is a breeze—I find it falls off a cliff when you start thinking about real production workloads.
My main pain points come from scaling the data layer and managing the observability overhead itself. The docs are very much "here's how to get data in," but not "here's how to keep the system performant when you're ingesting 50k trace events per minute." For instance:
* **Database indexing strategies:** The Postgres schema is created automatically, but there's zero guidance on which indexes to add beyond the primary keys. When our `traces` table hit 10M rows, simple queries from the Langfuse UI started timing out. I had to manually analyze query patterns and add composite indexes on `(project_id, created_at)` and `(project_id, user_id)`.
* **Cost-effective retention policies:** The docs mention you can delete data via the API, but no discussion of strategies. We implemented a scheduled job to archive old traces to cold storage and delete them from the primary DB, but figuring out the relationships and constraints between `traces`, `observations`, `scores` etc. was a reverse-engineering effort.
* **Observability load on your app:** The async batch ingestion is well-documented. However, there's little discussion on what happens if the Langfuse ingestion endpoint is slow or down. We had to implement a circuit breaker and a more aggressive queue drop strategy to prevent the observability tail from wagging the application dog.
```go
// Example: Our custom index additions to the Langfuse schema
CREATE INDEX CONCURRENTLY idx_traces_project_created ON traces(project_id, created_at DESC);
CREATE INDEX CONCURRENTLY idx_observations_trace_id ON observations(trace_id);
CREATE INDEX CONCURRENTLY idx_scores_trace_id ON scores(trace_id);
```
The product is powerful, but it feels like the documentation is written from the perspective of the *provider* of the service, not the *operator* of it at scale. I'd love to see a dedicated "Production & Scaling" guide covering recommended hardware specs for self-hosting, advanced database tuning, managing cardinality in tags/scores, and patterns for keeping the client SDKs from becoming a source of latency themselves.
Am I alone in this? Has anyone else hit scaling walls and developed strategies or patches they're willing to share?
-- latency
sub-100ms or bust
You've nailed the exact inflection point where developer docs turn into ops docs, and most teams just stop writing. I've seen this same pattern with a half dozen observability and analytics platforms. They're brilliant at the happy path.
The database indexing gap is a classic one. When our traces table ballooned, we found the `scores` table was the real hidden killer for us, specifically queries joining on `observation_id` without an index. Had to add that manually after a dashboard timed out for five minutes.
Your point about retention policies is key. The "delete via API" cop-out means every team ends up reinventing the same lifecycle management wheel. We ended up implementing a two tier strategy: hot data in Postgres for the UI, anything older than 30 days gets pruned and key aggregates pushed to a columnar store for long term trend analysis. It's a lot of custom middleware for what should be a documented scaling concern.
APIs are not magic.