Langfuse oder Phoenix: Self-Hosting und Infrastruktur

Für selbst gehostetes Tracing und Evaluation ist Phoenix der schlankere Einstieg auf einem Laptop. Langfuse setzt bereits lokal auf einen mehrteiligen Stack: Die Langfuse-Dokumentation zum Self-Hosting nennt Web- und Worker-Container sowie PostgreSQL, ClickHouse, Redis oder Valkey und Objektspeicher. Wer Langfuse betreibt, übernimmt damit auch die Wartung dieser Komponenten.

Phoenix beginnt mit einer Anwendung und SQLite als voreingestelltem Speicher. Die Phoenix-Architektur empfiehlt PostgreSQL für den produktiven Mehrnutzerbetrieb und beschreibt zusätzliche Instanzen für höhere Last oder getrennte Teams. Die Wahl hängt deshalb vom geplanten Einsatz ab: Soll vor allem ein einzelner Lauf untersucht werden, oder braucht ein Team dauerhaft gemeinsame Daten, Analysen und klare Zugriffsgrenzen?

Welche Dienste tatsächlich betrieben werden

Bei Langfuse bedient der Web-Container Oberfläche und API, während ein Worker Ereignisse im Hintergrund verarbeitet. PostgreSQL speichert transaktionale Daten; ClickHouse hält Traces, Beobachtungen und Bewertungen für analytische Abfragen. Redis oder Valkey unterstützt Warteschlangen und Caches. Der Objektspeicher nimmt eingehende Ereignisse und größere Inhalte auf.

Diese Aufteilung hat einen konkreten Zweck: Eingehende Traces müssen nicht unmittelbar als fertige Analyseabfrage in ClickHouse landen. Langfuse kann Ereignisse zunächst im Objektspeicher sichern und ihre Verarbeitung über die Warteschlange an den Worker übergeben. Für den Betrieb bedeutet das allerdings, dass ein erreichbarer Webdienst allein noch keine funktionierende Ereignisverarbeitung belegt. Sicherungen, Zugangsdaten, Aktualisierungen und Wiederherstellung betreffen den gesamten Verbund.

Phoenix bündelt Oberfläche und Trace-Empfang in einer Anwendung. Mit SQLite liegt die Datenhaltung zunächst lokal; bei einer gemeinsamen produktiven Installation kommt PostgreSQL als eigener Dienst hinzu. Damit wächst der Betriebsaufwand, aber nicht sprunghaft um eine zusätzliche analytische Datenbank, eine Warteschlange und einen Objektspeicher. Auch bei dieser einfacheren Architektur brauchen dauerhaft gespeicherte Traces Sicherungen und eine Regel für ihre Aufbewahrung.

Laptop: kurze Wege für die Fehlersuche

Für eine einzelne Person ist Phoenix mit SQLite die naheliegende Wahl. Die lokale Installation eignet sich, um einen Agentenlauf, abgerufene Dokumente oder Evaluationsergebnisse während der Entwicklung zu untersuchen. Eine separate PostgreSQL-Installation ist für diesen Einstieg nicht erforderlich; die Persistenz hängt dann an der lokalen Datenablage.

Langfuse lässt sich ebenfalls lokal mit Docker Compose starten. Dieser Weg bildet jedoch schon die mehrteilige Architektur ab, die später betrieben werden soll. Das kann nützlich sein, wenn Entwicklung und Produktion dieselben Verarbeitungswege nutzen sollen. Wer lediglich einen einzelnen Trace verstehen möchte, muss dafür bei Langfuse mehr Dienste starten und funktionsfähig halten.

Ein Produktionsteam: Speicher und Analysevolumen

Für ein gemeinsames System ist Phoenix mit PostgreSQL ein plausibler Ausgangspunkt. Die Datenbank unterstützt gleichzeitigen Zugriff und bringt etablierte Werkzeuge für Sicherung und Replikation mit. Steigt die Last auf der Anwendung, können mehrere Phoenix-Instanzen hinter einem Lastverteiler dieselbe Datenbank nutzen. Die Datenbank bleibt dabei der gemeinsame Speicher und muss für die tatsächliche Schreib- und Abfragelast ausgelegt werden.

Langfuse legt den Schwerpunkt anders: ClickHouse ist ausdrücklich für analytische Abfragen über Traces, Beobachtungen und Bewertungen vorgesehen, während Web und Worker Annahme und Verarbeitung trennen. Das ist für dauerhaftes Monitoring und umfangreiche Auswertungen ein nachvollziehbarer Architekturvorteil. Er rechtfertigt den zusätzlichen Betrieb aber nur, wenn das Team diese Arbeitsabläufe benötigt. Eine allgemeine Grenze nach Trace-Anzahl lässt sich daraus nicht ableiten; Datenumfang, Aufbewahrungsdauer, Aufnahmespitzen und Abfragehäufigkeit wirken zusammen.

Auch die Art der erfassten Inhalte zählt. Prompts, Antworten und abgerufene Dokumente können sensible Daten enthalten und den Speicherbedarf deutlich stärker prägen als die bloße Zahl der Läufe. Self-Hosting bestimmt, wo die eigene Tracing-Plattform betrieben wird. Welche Inhalte die Instrumentierung überträgt und ob Evaluationen externe Modellanbieter aufrufen, sind zusätzliche Entscheidungen der Anwendung.

Getrennte Teams: Lastverteilung ist keine Mandantentrennung

Bei Phoenix entspricht eine Instanz einem Mandanten. Projekte, Traces, Datensätze und Experimente innerhalb dieser Instanz sind für Nutzer entsprechend ihren Rollen zugänglich. Sollen Teams voneinander getrennt arbeiten, sieht die Architektur eigene Instanzen vor. Für vollständige Datentrennung können diese unabhängige Datenbanken erhalten; alternativ lassen sich Instanzen über getrennte PostgreSQL-Schemas in einer Datenbank isolieren.

Mehrere Phoenix-Instanzen mit derselben Datenbank erfüllen dagegen vor allem einen anderen Zweck: Sie verteilen Anfragen auf mehrere Anwendungen. Sie schaffen dadurch keine eigene Datengrenze für jedes Team. Bei getrennten Installationen wachsen wiederum Konfiguration, Aktualisierung und Sicherung pro Instanz mit. Diese Unterscheidung ist wichtiger als die reine Zahl gestarteter Container.

Bei Langfuse stellt sich die Frage auf der Ebene des gesamten Stacks. Eine gemeinsam betriebene Umgebung erspart doppelte Speicher- und Verarbeitungsdienste, verlangt aber passende Zugriffsrechte für die beteiligten Teams. Erfordern organisatorische Vorgaben vollständig getrennte Deployments, muss der mehrteilige Unterbau ebenfalls getrennt betrieben werden. Das kann die Wartung stärker prägen als der Funktionsvergleich der Oberflächen.

Welche Analyse den Aufwand trägt

Eine externe Gegenüberstellung beschreibt Phoenix als lokal orientiertes Werkzeug für Debugging und Evaluation mit enger Bindung an OpenTelemetry und OpenInference; Langfuse ordnet sie als breitere Plattform für Tracing, Prompt-Verwaltung, Datensätze und laufende Auswertungen ein. Das sind Schwerpunkte, keine Ausschließlichkeiten: Beide Produkte können Traces und Evaluationen verarbeiten und als selbst gehosteter Dienst laufen.

Für ein Team, das vor allem Retrieval-Schritte und einzelne Agentenläufe untersucht, wiegt der einfache Phoenix-Start schwer. Sollen Traces über längere Zeit gemeinsam für operative Analysen und integrierte Arbeitsabläufe dienen, kann Langfuse den zusätzlichen Stack rechtfertigen. Phoenix kann zwar durch weitere Anwendungsinstanzen wachsen, seine dokumentierten Speicheroptionen bleiben SQLite und PostgreSQL. Für analytische Lasten jenseits dieser Datenbanken verweist die Phoenix-Architektur auf Arize AX, ein anderes Produkt. Diese Grenze gehört zur Infrastrukturentscheidung, bevor aus einer lokalen Installation ein dauerhaftes System wird.

Lesen Sie auch: