In der heutigen digitalen Landschaft sind Datenbanken das Rückgrat fast jeder Anwendung – sie speichern, verwalten und sichern die Datenflüsse, die Unternehmen benötigen, um effektiv zu arbeiten. Aufgrund der steigenden Anforderungen an Skalierbarkeit, Performance und Kostenkontrolle suchen viele Unternehmen nach der idealen Lösung für ihr Datenmanagement. Besonders die Wahl zwischen verteilten Datenbanklösungen wie CockroachDB und klassischen relationalen Systemen wie PostgreSQL stellt viele vor schwierige Entscheidungen. Die Geschichte von Motion, einem Unternehmen, das den Schritt von CockroachDB zu Postgres gewagt hat, bietet wertvolle Einblicke in die Herausforderungen, Risiken und Chancen einer solchen Migration. Die vorliegende Abhandlung beleuchtet die wichtigsten Aspekte, die bei der Migration zu PostgreSQL eine Rolle spielen, und liefert praxisnahe Erkenntnisse für Unternehmen, die vor einem ähnlichen Wechsel stehen.
Motion startete seine Reise im Jahr 2022 mit CockroachDB, einer verteilten Datenbanklösung, die vor allem durch mühelose horizontale Skalierung und hohe Verfügbarkeit überzeugt. Gerade in Bezug auf Multi-Region-Setups erfüllt CockroachDB vielfältige Anforderungen, insbesondere im Hinblick auf Datenschutzregelungen wie die DSGVO. Die SQL-Kompatibilität erleichtert zudem die Datenbankintegration. Dennoch zeigten sich mit zunehmender Unternehmensgröße und steigendem Datenvolumen deutliche Schwachstellen, vor allem wenn Transaktionsvolumen und Kosten berücksichtigt wurden. Der prestigeträchtige Vorteil der verteilten Architektur wurde durch explodierende Betriebskosten konterkariert – bis 2024 zahlte Motion fünfmal so viel wie ursprünglich angenommen, mit einer Rechnung im mittleren sechsstelligen Bereich.
Ein weiterer kritischer Punkt war die Performance bei migrationstechnischen Prozessen. Migrationen wurden durch Prisma, das eingesetzte ORM, zunehmend zur Herausforderung. Zeitüberschreitungen beim Anwenden von Datenbankänderungen führten zu blockierten Deployments und zeitintensiven manuellen Eingriffen durch die Entwickler. Dies erzeugte einen zusätzlichen Druck auf das Entwicklerteam, welches sich schließlich gezwungen sah, aus Angst vor Datenbank-Locks, Veränderungen außerhalb der Datenbank durchzuführen – ein Ansatz, der nicht nur riskant, sondern auch ineffizient ist. Die Migration auf PostgreSQL hingegen offenbarte eine deutliche Verbesserung: Datenbankschemaänderungen konnten dort dank der robusteren Unterstützung in wenigen Sekunden durchgeführt werden, was enorme betriebliche Vorteile mit sich brachte.
Auch abseits der Migrationen waren die Auswirkungen spürbar. ETL-Prozesse, vor allem jene zur Datenreplikation, litten unter den Einschränkungen von CockroachDB. Der Mangel an stabilen ETL-Tools führte zu häufigen Fehlern und Leistungseinbußen. Airbyte bot zwar eine mögliche Lösung an, diese war jedoch noch in der Alpha-Phase, enthielt Bugs wie Memory Leaks und war infolgedessen schwer einzusetzen. Der Mangel an zuverlässiger Infrastruktur für Datentransfer und Replikation macht die tägliche Datenverwaltung komplizierter und behindert damit auch die schnelle Produktentwicklung und das Reporting.
Die Performance von Abfragen zeigte sich ebenfalls zwiespältig. In bestimmten Szenarien war CockroachDB dank seines optimierten Query Planners schneller. Komplexe Aggregationen oder spezifische Join-Operationen wurden hier oft clever verarbeitet. Dennoch dominierte der Großteil der realen Anwendungsszenarien, in denen Postgres sich als deutlich überlegen erwies. Besonders bei den von Prisma generierten, oft stark verschachtelten und umfangreichen SQL-Statements, konnte Postgres durch bessere Indizierung und effizientere Abfrageausführung punkten.
Ein Beispiel aus der Praxis zeigte einen Traum von Abfrage, der auf Postgres zwanzigmal schneller lief als auf CockroachDB. Neben der reinen Performance und Stabilität war auch die Entwicklererfahrung ein wesentlicher Faktor. Das Handling von Indizes, die Cancelation von Abfragen und die allgemeine Benutzerfreundlichkeit der Datenbankverwaltungsoberflächen waren bei CockroachDB oft frustrierend. Insbesondere das Problem, laufende langwierige Abfragen abzubrechen, stellte die Entwickler vor große Herausforderungen. Während man bei PostgreSQL einfach einen Befehl in gängigen SQL-Clients ausführen kann, ist CockroachDB hier umständlicher und weniger zuverlässig.
Die Support-Erfahrungen bei CockroachDB trugen ebenfalls zur Unzufriedenheit bei. Divergierende Login-Portale, lange Antwortzeiten und die Notwendigkeit, wiederholt Cluster-Informationen bereitzustellen, verkomplizierten das Handling von kritischen Problemen zusätzlich. Dies wirkt sich gerade in Situationen mit hoher Dringlichkeit negativ aus und erhöht die Ausfallzeiten. Netzwerkprobleme bildeten ein weiteres Ärgernis. Über zwei Jahre trat bei CockroachDB immer wieder eine instabile Erreichbarkeit der Datenbankcluster auf, was sich durch Fehlermeldungen wie „getaddrinfo ENOTFOUND“ offenbarte.
Trotz intensiver Recherche und Analyse blieb die Ursache ungelöst, was dem Betrieb strenge Grenzen setzte. Postgres zeigte sich in dieser Hinsicht deutlich robuster und störungsfreier. Die technische Herausforderung der eigentlichen Datenmigration stellte Motion vor vielfältige Herausforderungen. Mit einer Datenbasis von rund 100 Millionen Datensätzen wurde die Migration zur Mammutaufgabe. Da keine ausgereiften ETL-Tools verfügbar waren, entwickelte das Team ein eigenes Verfahren mit dem aufkommenden JavaScript-Laufzeitsystem Bun.
Die Daten wurden zunächst tabellenweise exportiert, dann parallelisiert und als CSV-Streams in PostgreSQL importiert. Die Anpassung war jedoch aufwändig, da CockroachDB und PostgreSQL unterschiedliche Formate bei JSON- und Array-Datentypen verwendeten. Erst durch individuelle Datenkonvertierungen konnte eine nahezu verlustfreie Datenübernahme erreicht werden. Am bemerkenswertesten war die kurze Downtime beim Wechsel selbst: Nur etwa 45 Minutensgesamtverfügbarkeit gingen durch die Umstellung verloren. Dabei ließ sich dank der stabilen Planung die Ausfallzeit bei Bedarf noch weiter reduzieren.
Die positive Auswirkung ließ nicht lange auf sich warten: Die Gesamtlatenz der Datenbankanfragen fiel um ein Drittel, was zu einer spürbaren Verbesserung der Systemreaktionszeiten und Nutzerzufriedenheit führte. Nicht zu vernachlässigen sind die finanziellen Vorteile. Bereits kurz nach der Migration konnte Motion mehrere Hunderttausend Euro im Jahr einsparen – auf lange Sicht ein entscheidender Wettbewerbsvorteil. Die Kostenreduktion setzt sich insbesondere durch geringere Infrastrukturkosten und reduzierte Betriebsaufwände fort. Durch das breite Ökosystem von PostgreSQL ergeben sich zusätzlich Vorteile bei der Wartung und Weiterentwicklung der Datenbankumgebung.
Werkzeuge wie PGAnalyze ermöglichen es, ineffiziente Abfragen rasch zu identifizieren und zu optimieren. In den ersten Stunden nach der Migration konnten alleine so mehrere Performanceflaschenhälse beseitigt werden, die den Betrieb vorher bremsten. Die Erfahrungen von Motion zeigen, dass verteilte Datenbanksysteme wie CockroachDB zwar hervorragende Eigenschaften für bestimmte Anwendungen besitzen, aber auch erhebliche Einschnitte und Risiken bergen. Vor allem wenn die Anwendung keine Multi-Region-Fähigkeiten benötigt und keine extrem verteilten Datenmengen verwaltet, kann ein klassisches relationales System wie PostgreSQL die bessere Wahl darstellen. Die Migration erfordert zwar eine sorgfältige Planung und Implementierung, zahlt sich jedoch durch Performancegewinn, Stabilität, Kosteneffizienz und bessere Entwicklererfahrung aus.
