☰ Menu

03.10.2026 · Signal Titans Editorial

Skalierung bei Plaud: Datenarchitektur von KI-Hardware übersteigt 300 Millionen Zeilen

Plaud hat seine Datenbankinfrastruktur überarbeitet und die Metadaten auf TiDB migriert, um Schema-Sperren zu lösen und den Abfragedurchsatz zu steigern.

Eine moderne, minimalistische konzeptionelle Illustration, die eine digitale Sanduhr aus leuchtenden Datenknoten vor einem dunklen Hintergrund darstellt.

Der Hersteller von KI-Hardware Plaud hat seine Backend-Datenarchitektur umstrukturiert, nachdem die ursprüngliche relationale Lösung bei etwa 300 Millionen Zeilen an ihre Skalierungsgrenzen stieß. Durch die Migration der strukturierten Metadatenschicht auf TiDB konnte das Team Einschränkungen bei Schema-Änderungen aufheben und die Abfragekapazitäten erweitern, während die P95-Latenz unter 10 Millisekunden blieb.

Der Engpass durch die Transkript-Sidecar-Struktur

Ursprünglich nutzte Plaud ein weit verbreitetes zweistufiges Speicher-Muster: Strukturierte Metadaten wurden in MySQL verwaltet, während rohe Audio- und Transkriptdateien in Amazon S3 abgelegt wurden. Obwohl dieses Modell in der Anfangsphase funktionierte, brachte die Trennung von Metadaten und Inhalten architektonische Herausforderungen mit sich. Ohne gemeinsame Transaktionsgrenze zwischen beiden Speichern musste die Datenkonsistenz über eine Abstimmungslogik in der Anwendungsebene sichergestellt werden.

Mit steigenden Nutzerzahlen führte die Verwendung des Objektspeichers als primärer Pfad für mehrere Megabyte große Datenmengen zu schwankenden Zugriffszeiten. Zudem bargen Latenzspitzen und Replikationsverzögerungen das Risiko temporärer Konsistenzlücken, sodass Metadaten ein Transkript bereits als verfügbar markierten, bevor das entsprechende S3-Objekt tatsächlich erreichbar war.

Schema-Grenzen bei 300 Millionen Zeilen

Als der Single-Instance-MySQL-Speicher für Metadaten rund 300 Millionen Zeilen erreichte, wurden Schema-Anpassungen zunehmend risikobehaftet. Data Definition Language (DDL)-Operationen erforderten Sperren der Tabellen und erzeugten hohe Replikationslast, weshalb das Entwicklerteam Updates in dedizierte Wartungsfenster verlegen musste.

Diese Obergrenze der Datenbank beeinträchtigte die Produktbereitstellung. Routineänderungen wie das Hinzufügen von Spalten oder das Ändern von Indizes hingen damit an betrieblichen Wartungszyklen statt an flexiblen Zeitplänen für Software-Releases.

Migration der Metadaten auf Distributed SQL

Um die Skalierungsgrenze aufzuheben, migrierte Plaud die strukturierte Metadatenschicht auf die verteilte SQL-Datenbank TiDB, während große Audiodatei-Inhalte weiterhin im Objektspeicher verblieben. Die neue Architektur ermöglichte Online-DDL-Ausführungen, sodass Schema-Updates ohne Ausfallzeiten durchgeführt werden konnten.

Durch die Migration konnte Plaud seine Abfragen pro Sekunde etwa um das Zehnfache steigern und gleichzeitig die Tail-Latenz unter 10 Millisekunden halten, wodurch Verzögerungen beim Datenabruf die Benutzeroberfläche nicht mehr beeinträchtigen.

KI-generierte redaktionelle Illustration; kein Dokumentarfoto.

Quelle: The Database Is the Product: What Breaks When Memory Devices Scale