Langfuse v4 ist kein kosmetisches Observability-Release. Die heute veröffentlichte Major-Version ersetzt bei Self-Hosted-Installationen den Kern des Lese- und Ingestion-Modells. Neue Suche, Alerts und schnellere APIs sind attraktiv; der eigentliche Betriebsauftrag ist jedoch die kontrollierte Migration auf OpenTelemetry und die neuen Read-APIs.
Was v4 technisch verändert
Langfuse v4 führt zwei ClickHouse-Tabellen ein: events_full als immutable Event-Speicher und events_core als query-optimierte Projektion. Traces bleiben als Konzept erhalten, werden aber als Root-Spans in diesem einheitlichen Observations-Modell abgebildet. Das ist ein sinnvoller Schritt: LLM-Calls, Tool-Ausführungen und Agent-Schritte lassen sich damit in einem Datenmodell lesen und filtern, statt zwischen Trace- und Observation-Sichten zu wechseln.
Die unmittelbaren Produktmerkmale sind Volltextsuche über Inputs, Outputs und Metadaten, eine Filter-Search-Bar, Monitore und Alerts sowie Observations API v2 und Metrics API v2. Für Teams mit langen Retention-Zeiträumen oder sehr vielen Agent-Events ist die Architekturänderung relevanter als die UI: events_core begrenzt große Payloads für Tabellen- und Chart-Abfragen, während die vollständigen Daten in events_full erhalten bleiben.
Der Cutover bricht alte Pfade bewusst
Im Standard-Schreibmodus events_only fallen alte Schnittstellen nicht nur aus der Empfehlung, sondern konkret aus dem Betrieb. Betroffen sind unter anderem Python SDK v2 und älter, JS/TS SDK v3 und älter, die Legacy-Batch-Ingestion sowie alte Read-Endpunkte für Traces, Observations, Sessions, Scores und Metriken. Viele dieser Endpunkte antworten nach dem Cutover mit 404; klassische Trace-, Span-, Generation- und Event-Ingestion wird durch OpenTelemetry-basierte Ingestion ersetzt.
Die Infrastruktur bleibt gleich – Web/Worker, PostgreSQL, ClickHouse, Redis und Blob Storage. Der Bruch liegt im Datenmodell und an den API-Grenzen.
Was Betreiber jetzt prüfen sollten
- SDK-Inventar: Welche Services senden noch mit Python ≤2 oder JS/TS ≤3?
- API-Verbraucher: Dashboards, ETL-Jobs und interne Tools auf Legacy-Reads prüfen; besonders
/api/public/traces,/observationsund/metrics. - Evaluierungen: Trace-basierte und Legacy-Dataset-LLM-as-a-Judge-Workflows vor dem Cutover auf Observation-Level-Evaluators umstellen.
- Exporte: Blob Storage-, PostHog- und Mixpanel-Integrationen vom Export-Source Traces and observations (legacy) auf Enriched observations umstellen.
- Migration planen: Legacy- und Dual-Write-Mode erlauben eine gestufte Umstellung. Erst nach beobachteter Parität sollte
events_onlyder Default werden.
Ein Upgrade mit echter operativer Konsequenz
Für neue Installationen ist v4 eine deutlich modernere Basis. Für bestehende Self-Hosted-Deployments ist es ein Migrationsprojekt, nicht ein Versionsbump. Genau das macht das Release bemerkenswert: Langfuse räumt sein Observability-Datenmodell auf, ohne neue Infrastrukturkomponenten einzuführen – verlangt im Gegenzug aber, dass SDKs, Reader, Evaluatoren und Exporte als zusammenhängende Produktionskette behandelt werden.
Quellen
- Langfuse v4.0.0 Release – veröffentlicht am 29. Juli 2026, 14:52 UTC.
- Offizieller Upgrade-Guide: v3 → v4.
Leave a Reply