Die Entscheidung, eine bestehende Datenbank-Infrastruktur zu migrieren, ist niemals einfach und mit vielen Überlegungen verbunden. Für viele Unternehmen war CockroachDB lange Zeit eine vielversprechende Lösung, insbesondere wegen seiner horizontalen Skalierbarkeit, der Multi-Region-Unterstützung und der SQL-Kompatibilität. Doch mit zunehmendem Wachstum und steigenden Kosten zeichnen sich zunehmend Herausforderungen ab. Ein Beispiel hierfür ist das Unternehmen Motion, das in den letzten Jahren eine bewusste Entscheidung traf, seine Datenbank von CockroachDB zu PostgreSQL zu migrieren und dabei wertvolle Erkenntnisse sammelte, von denen andere Organisationen profitieren können. CockroachDB wurde bei Motion seit Anfang 2022 genutzt. Die Vorteile lagen vor allem im einfachen horizontalen Skalieren und der hohen Verfügbarkeit. Besonders bei geplanten Multi-Region-Setups, die etwa durch Datenschutzanforderungen wie die DSGVO erforderlich werden, schien die Technologie bestens geeignet.
Die Befürchtung, dass eine traditionelle Postgres-Datenbank standortübergreifend schwer skalierbar sei, führte dazu, dass CockroachDB zunächst klar favorisiert wurde. Mit dem Wachstum des Unternehmens stiegen jedoch sowohl die Datenmengen als auch die damit verbundenen Kosten signifikant an. Bis zum Jahr 2024 sind die Ausgaben für CockroachDB bei Motion auf ein Fünffaches angewachsen und erreichten mittlere sechsstellige Beträge. Zudem stellte sich heraus, dass die Multi-Region-Anforderungen noch nicht akut waren und die meisten Datenbankabfragen relativ einfache, transaktionale Operationen betrafen. Unter diesen Umständen stellte sich die Frage, ob die hohen Kosten für ein verteiltes Datenbanksystem wie CockroachDB wirklich gerechtfertigt seien. Ein weiterer technischer Stolperstein ergab sich bei der Handhabung von Datenbank-Migrationen.
Mit wachsendem Datenvolumen kam es immer häufiger vor, dass die Migrationsprozesse, die über Prisma als ORM durchgeführt wurden, aufgrund von Zeitüberschreitungen (Timeouts) blockiert wurden. Dies führte dazu, dass Migrationen manuell direkt auf CockroachDB angewandt werden mussten, was den Deploy-Prozess erheblich verlangsamte und operative Risiken erhöhte. Ein Test mit einer identischen Migration in PostgreSQL zeigte, dass dieselbe Aktion innerhalb von zehn Sekunden abgeschlossen war, wobei die Datenbank-Größe kontrolliert und vergleichbar gehalten wurde. Die daraus resultierenden Timeouts zwangen die Entwickler zu operativen Kompromissen. In manchen Fällen wurden Datenbankaktionen bewusst außerhalb der Datenbank oder mit suboptimalen Workarounds durchgeführt, nur um Systemausfälle oder Blockaden zu verhindern. Das hat nicht nur die Effizienz gebremst, sondern auch zu einer gefährlichen Situation geführt, in der das System in kritischen Momenten instabil war.
Neben den Migrationsproblemen stellte sich auch die ETL (Extract, Transform, Load)-Prozesse als Schwachstelle heraus. CockroachDB wurde mit Airbyte als einziger Connector-Lösung unterstützt, welche jedoch noch im Alpha-Stadium war und Gedächtnisleck-Probleme zeigte. Die Performance von ETL-Jobs war insgesamt schlecht und führte zu wiederholten Ausfällen und Verzögerungen. Im Gegensatz dazu bietet der PostgreSQL-Ökosystem deutlich mehr ausgereifte und zuverlässige ETL-Tools, die ebenfalls den industriellen Anforderungen genügen. Auch die Abfragegeschwindigkeit spielte bei der Entscheidung zugunsten von PostgreSQL eine entscheidende Rolle. Während manche einzelne Abfragen tatsächlich von der CockroachDB-Optimierung profitierten und schneller abgearbeitet wurden, zeigte eine Mehrheit der realen Abfragen deutlich bessere Performance auf PostgreSQL.
Besonders die teils komplexen und von Prisma generierten SQL-Anfragen führten bei CockroachDB aufgrund fehlender Optimierung zu erheblichen Verzögerungen. Eine exemplarische Abfrage war in PostgreSQL bis zu zwanzigmal schneller als in Cockroach. Neben technischen Aspekten gab es verschiedene Usability-Probleme innerhalb der CockroachDB-Umgebung. Die Anzeige von Indizes, die angeblich ungenutzt seien, führte beispielsweise zu Verwirrung und potenziellen Fehlentscheidungen beim Index-Management. Auch die Möglichkeiten, laufende Abfragen abzubrechen, waren auf CockroachDB deutlich komplizierter und risikoreicher im Vergleich zu PostgreSQL, wo komfortable Funktionen in vielen Datenbank-Clients zur Verfügung stehen. Darüber hinaus erschwerten Support-Hürden den Alltag. Die CockroachDB-Supportportale waren getrennt vom Hauptportal, die Kommunikation dauerte häufig mehrere Tage, was vor allem bei kritischen Systemausfällen belastend war.
In Kombination mit technisch bedingten Problemen, wie unregelmäßig auftretenden Verbindungsstörungen in verschiedenen Umgebungen, verschlechterte sich die Situation weiter. Solche Probleme blieben bei PostgreSQL bisher aus. Angesichts dieser Herausforderungen begann Motion mit der Planung einer eigenen Migration. Die Besonderheit lag dabei darin, dass die hauseigene Lösung auf Bun basierte, einer schnell wachsenden JavaScript-Laufzeitumgebung. Die Strategie war, die Datenbank-Schemata auszulesen, Daten in Dateien zu speichern und anschließend mit mehreren parallelen Prozessen die Daten in PostgreSQL einzuspeisen. Dabei zeigte sich eine komplexe technische Hürde: Die Unterschiede in der Datenkodierung, insbesondere bei JSON- und Array-Typen, mussten im ETL-Prozess sorgfältig angepasst werden, um Datenkonsistenz zu gewährleisten. Am Ende stand eine durchdachte und kontrollierte Migration, bei der der Betrieb wohldosiert heruntergefahren wurde, um einen Datenverlust auszuschließen.
Die gesamte Migration erfolgte innerhalb einer Stunde, was im Kontext der Datenmenge von etwa 100 Millionen Zeilen in der größten Tabelle eine beachtliche Leistung darstellt. Schon unmittelbar nach der Migration verbesserten sich die Gesamtlatenzen der Datenbankabfragen um rund 33 Prozent. Weiterhin konnten dank der Analyse-Tools für PostgreSQL zahlreiche Optimierungspotenziale bei Abfragen herausgearbeitet und mit minimalem Aufwand verbessert werden. Ein wirtschaftlicher Nebeneffekt der Migration war ebenfalls signifikant: Trotz konservativer Überdimensionierung des neuen PostgreSQL-Clusters ergab sich eine jährliche Kosteneinsparung von über 110. 000 US-Dollar. Diese Summe dürfte mit weiter steigendem Daten- und Anfragevolumen im Laufe der Zeit noch wachsen.
Die Migration ist ein eindrucksvolles Beispiel dafür, dass technische Entscheidung nicht nur von den Features einer Lösung abhängig sein sollten, sondern auch von Preis-Leistungs-Verhältnis, Support, Ökosystem und langfristiger Betriebssicherheit. PostgreSQL bietet durch seine weite Verbreitung, umfangreiche Tools und aktive Community viele Vorteile, die auch in komplexen Anwendungsfällen überzeugen. Für Unternehmen, die ähnliche Projekte planen, ist die frühzeitige Analyse des Datenvolumens, der zu erwartenden Lastprofile und der vorhandenen ORMs essenziell. Außerdem lohnt es sich, die Migrationsstrategie im Detail zu planen und Probeläufe zu nutzen, um versteckte Inkompatibilitäten, wie sie bei Datenformat-Unterschieden auftreten können, frühzeitig zu erkennen. Zusammenfassend zeigt der Fall Motion, wie eine wohlüberlegte Migration von einem hochverfügbaren, verteilten System zu einem bewährten relationalen System gewinnbringend sein kann.
Neben technischen Verbesserungen führen solche Änderungen häufig auch zu erheblichen Kostenvorteilen und einer besseren Entwicklererfahrung. Die Wahl der richtigen Datenbank hängt dabei immer vom individuellen Use-Case ab, doch die Erfahrungen aus der Praxis liefern wertvolle Hinweise für eine informierte Entscheidung.
