In der Welt moderner Datenbanken sind Skalierbarkeit, Verfügbarkeit und Performance entscheidende Kriterien für Unternehmen jeder Größe. Seit Anfang 2022 setzte das Unternehmen Motion auf CockroachDB – eine verteilte SQL-Datenbank, die vor allem durch ihre einfache horizontale Skalierung und hohe Ausfallsicherheit besticht. Insbesondere für Multi-Region Setups, die z. B. durch Datenschutzbestimmungen wie die DSGVO vorgeschrieben sind, war CockroachDB eine verlockende Option.
Doch im Laufe der Nutzung traten zunehmend Herausforderungen auf, die letztlich den Wechsel zu PostgreSQL notwendig machten. Der Ursprung der Migration lag vor allem in den steigenden Kosten und der zunehmenden Komplexität im Betrieb der Datenbank. Obwohl Motion zunächst nur in einer Region und mit relativ einfachen transaktionalen Abfragen arbeitete, stiegen die Gebühren für CockroachDB bis Mitte 2024 auf fünfstellige, sogar höhere Beträge. Dies war angesichts der eigentlich nicht genutzten Multi-Region-Funktionalitäten ein bedeutender Faktor, die Notwendigkeit einer kostenintensiven verteilten Datenbank zu hinterfragen. Neben den finanziellen Aspekten zeigten sich technische Schwachstellen: Besonders die Migrationen im Schema Management stellten das Team vor große Probleme.
Mit Prisma als ORM wurde immer wieder festgestellt, dass Migrationen häufig zeitlich aus dem Ruder liefen und Server-Timeouts provozierten. Die Folge war ein langwieriger und fehleranfälliger Prozess, der teils manuelle Eingriffe in CockroachDB erforderte und zu unvorhergesehenen Verzögerungen in Deployments führte. Das führte zusehends zu Unsicherheiten bei Entwicklern, die aus Angst vor Sperrungen und Komplettausfällen auf Workarounds außerhalb der Datenbank zurückgriffen. Interessanterweise zeigten Vergleiche zwischen PostgreSQL und CockroachDB bei der Ausführung ähnlicher Migrationen einen eklatanten Unterschied: Während CockroachDB auf großen Datenmengen mitunter Stunden zum Einspielen von Änderungen benötigte, erledigte PostgreSQL denselben Vorgang in wenigen Sekunden, selbst unter Berücksichtigung identischer Ausgangsbedingungen. Diese Erkenntnis war wegweisend für die weitere Datenbankstrategie.
Datenextraktions- und Ladevorgänge (ETL) litten ebenfalls erheblich unter den Limitierungen von CockroachDB. Die vorhandenen Tools, allen voran Airbyte, standen noch in der Alphaphase der CockroachDB-Anbindung. Das führte zu Instabilitäten, etwa durch Speicherlecks, die dazu beitrugen, dass geplante Datenübertragungen regelmäßig abbrachen oder massive Performance-Einbußen auftraten. Ein stabiler Datenfluss konnte so nicht zuverlässig gewährleistet werden, was insbesondere für ein schnell wachsendes Unternehmen kritisch ist. Was die Abfrageperformance betrifft, zeigte CockroachDB in bestimmten, eher spezialisierten Fällen Vorteile.
Komplexe Aggregationsabfragen konnten durch den Cockroach-Query-Optimizer effizienter bearbeitet werden als vergleichbare Abfragen in PostgreSQL. Allerdings waren diese Fälle eher die Ausnahme. Im Regelfall punktete PostgreSQL mit deutlich schnelleren Antwortzeiten, insbesondere bei den realitätsnahen Anwendungsfällen, die das Unternehmen täglich bewältigen musste. Die Ursache lag oft bei der von Prisma generierten SQL-Abfragen, die mitunter sehr komplex und ineffizient waren, was zu vollem Scannen großer Tabellen führte – ein Problem, das bei CockroachDB teils noch verstärkt auftrat. PostgreSQL hingegen verarbeitet selbst solche komplexen Joins und Filterbedingungen routiniert und signifikant performanter, was nach der Migration sofort spürbar war.
Tatsächlich konnten viele Abfragen nach der Umstellung auf PostgreSQL um ein Vielfaches schneller ausgeführt werden, was die Nutzererfahrung deutlich verbesserte. Neben der reinen Performance spielten auch Nutzererfahrungen eine Rolle bei der Entscheidung. CockroachDB zeigte immer wieder technische Kinderkrankheiten: Fehlmeldungen zu angeblich ungenutzten Indizes sorgten für Verwirrung im Entwicklerteam. Das Management laufender Abfragen gestaltete sich umständlich, da ein Abbrechen von teuren oder hängen gebliebenen Queries nicht über einfach zugängliche Tools möglich war, sondern in der administrativen Cockroach-Konsole erfolgen musste. Die Verzögerungen und Unsicherheiten bei der Stornierung konnten gravierende Folgen für die Systemverfügbarkeit haben.
Auch der Support bot wenig Komfort. Ein eigenständiges Portal, mangelnde Integration mit dem Hauptaccount und lange Antwortzeiten von bis zu einer Woche erschwerten den professionellen Betrieb und die schnelle Problemlösung in Kritiksituationen. Ein solcher Supportaufwand ist in schnelllebigen Entwicklungsumgebungen wenig praktikabel und stellt eine weitere Belastung für das Team dar. Des Weiteren führten wiederkehrende Netzwerkausfälle und Verbindungsprobleme, zum Beispiel beim Zugriff über Tailscale, zu erheblichen Betriebsstörungen. Diese Fehler entstanden scheinbar ohne klare Ursache, traten unregelmäßig in verschiedenen Umgebungen auf und konnten trotz intensiver Fehlersuche über einen Zeitraum von mehr als zwei Jahren nicht zufriedenstellend behoben werden.
Im Gegensatz dazu verliefen Verbindungen zu PostgreSQL-Datenbanken über die gleiche Infrastruktur stabil und zuverlässig. Vor dem finalen Umstieg stand die gefährliche und logistisch anspruchsvolle Aufgabe der Datenmigration. Motion verfügte zu diesem Zeitpunkt über Datensätze mit mehr als 100 Millionen Einträgen. Mit standardmäßigen ETL-Lösungen ließ sich der Transfer aufgrund von Instabilitäten und Performanceproblemen nicht realisieren. Daher entwickelte der Autor eigenhändig eine maßgeschneiderte Lösung basierend auf dem aufkommenden JavaScript-Laufzeitumgebung Bun.
Die Vorgehensweise war clever und pragmatisch: Zunächst wurde das Datenbankschema eingelesen, anschließend alle Tabellendaten in Dateien exportiert und danach in parallelisierten Prozessen zeilenweise via CSV-Streams in die PostgreSQL-Datenbank importiert. Ein unerwartetes Problem traten jedoch bei der Datenkonvertierung auf. CockroachDB hatte eine leicht andere Bytekodierung bei JSON- und Array-Spalten als PostgreSQL. Dies erforderte zusätzliche, individuell entwickelte Transformationen, um die Daten korrekt und konsistent in das neue System zu übertragen. Die Feinarbeit in dieser Phase war entscheidend, um Datenverlust oder inkonsistente Zustände zu verhindern.
Die eigentliche Migration fand an einem geplanten Wartungsfenster statt. Mit einer leistungsfähigen 128-Kern VM in der Google Cloud Platform wurde der Umzug innerhalb von 15 Minuten für die gesamte Datenbank abgeschlossen. Die Bediener schalteten die Anwendung in den Wartungsmodus und erlaubten nur kontrolliert den Traffic wieder zurückzukehren, um eventuelle Probleme frühzeitig zu erkennen und zu beheben. Die Gesamt-Ausfallzeit belief sich auf unter einer Stunde und verlief störungsfrei sowie ohne Datenverlust. Nach der Migration zeigte sich schnell der Erfolg.
Die durchschnittlichen Antwortzeiten der Anwendung sanken um ein Drittel – eine enorme Verbesserung, die für Endnutzer unmittelbar spürbar war. Darüber hinaus ermöglichte das reiche Ökosystem von PostgreSQL mit Tools wie PGAnalyze eine schnelle Optimierung von bis dahin unentdeckten Flaschenhälsen bei Abfragen. Diese Feineinstellungen konnten innerhalb von Stunden umgesetzt werden und steigerten die Effizienz zusätzlich. Ein ebenfalls wichtiger Faktor war die Kostenersparnis. Trotz konservativer Überdimensionierung des PostgreSQL-Clusters konnte das Unternehmen jährlich mehr als 110.
000 Dollar einsparen. Diese Summe wird in den kommenden Jahren mit steigendem Datenvolumen und Benutzeraufkommen voraussichtlich noch wachsen. Darüber hinaus bietet PostgreSQL mehr Flexibilität und Stabilität, was die Betriebssicherheit und zukünftige Skalierbarkeit erleichtert. Insgesamt zeigt die Reise von Motion einen beispielhaften Weg moderner Technologieentscheidungen. Die anfängliche Begeisterung für ausgeklügelte verteilte Systeme weicht einer pragmatischen Haltung, die auf Zuverlässigkeit, Performance und Kostenkontrolle setzt.
PostgreSQL beweist sich als robuste und bewährte Datenbanklösung, die nicht nur mit komplexen Strukturen umgehen kann, sondern durch ein umfangreiches Ökosystem die Entwicklung und den Betrieb langfristig unterstützt. Für Unternehmen, die vor der Entscheidung stehen, ihre Datenbankstrategie zu überdenken, liefert dieser Erfahrungsbericht wertvolle Einblicke. Ein detailliertes Abwägen zwischen Innovation und Stabilität, die Berücksichtigung technischer Details und der Fokus auf reale Nutzungsszenarien sind unverzichtbar, um am Ende eine Entscheidung mit nachhaltigem Mehrwert zu treffen. Die Vorteile von PostgreSQL liegen klar auf der Hand: geringere Kosten, bessere Performance, einfachere Wartung und ein freundliches Entwicklererlebnis, das sich in einer modernen IT-Landschaft bezahlt macht.
![Plugin to export from Blender to HTML [video]](/images/E98715D0-22C0-4103-8A2D-363A2A18AC4E)
