Die Wahl der richtigen Datenbanklösung ist für viele Unternehmen entscheidend, um Skalierbarkeit, Performance und Kosten im Gleichgewicht zu halten. Ein Beispiel, das viele Entwickler und Unternehmen beschäftigt, ist die Migration von CockroachDB zu PostgreSQL – zwei sehr unterschiedliche Systeme mit jeweils eigenen Stärken und Schwächen. Seit 2022 nutzte das Unternehmen Motion CockroachDB – eine verteilte SQL-Datenbank, die insbesondere durch ihre einfache horizontale Skalierbarkeit und hohe Verfügbarkeit punktet. Diese Eigenschaften waren besonders durch geplante Multi-Region-Setups aufgrund von Datenschutzbestimmungen wie der DSGVO interessant. Die anfänglichen Hoffnungen lagen auf einer umfassenden Skalierbarkeit über Regionen hinweg, verbunden mit einer SQL-kompatiblen Oberfläche, die Entwicklern vertraut war.
Im Laufe der Zeit, speziell bis 2024, stiegen jedoch die Kosten für CockroachDB massiv an. Die jährlichen Rechnungen vervielfachten sich auf einen mittleren sechsstelligen Betrag. Dabei war das System noch in einem einzelnen Rechenzentrum ohne Multi-Region-Setup im Einsatz, und die Datenbankabfragen blieben für einfache transaktionale Operationen relativ unkompliziert. Ein Großteil der Kunden verlangte keine Datenlokalisierung, sodass die komplexe und teure verteilte Architektur von CockroachDB nicht ausgeschöpft wurde. Die Frage war, ob sich die hohen Investitionen für diesen speziellen Anwendungsfall lohnten.
Die technische Infrastruktur von Motion setzte auf Prisma als ORM (Object-Relational Mapping), was den Vergleich von Datenbankoperationen zwischen CockroachDB und PostgreSQL erleichterte. Erste signifikante Probleme traten bei Migrationen auf. Mit der zunehmenden Datenbankgröße kam es häufig zu Zeitüberschreitungen bei automatisierten Migrationen. Entwickler mussten Migrationen teilweise manuell und sequentiell in CockroachDB ausführen, was den Deploy-Prozess deutlich verzögerte. Eines der größten Probleme war, dass diese Zeitüberschreitungen die Weiterentwicklung der Datenbankplattform behinderte – selbst dringend notwendige Updates auf neuere CockroachDB-Versionen konnten nicht reibungslos durchgeführt werden.
Diese Zwickmühle führte letzten Endes zum Entschluss, auf PostgreSQL zu migrieren und obwohl CockroachDB zu der Zeit noch auf einer veralteten Version betrieben wurde, blieb es dies bis zur Migration. Ein weiteres zentrales Problem lag in der Unterstützung von ETL-Prozessen (Extract, Transform, Load). Die Implementierung zuverlässiger ETL-Pipelines scheiterte aufgrund mangelnder Integration moderner Tools mit CockroachDB. Die einzige damals verfügbare Airbyte-Connector-Lösung war noch im Alpha-Status, verursachte Speicherlecks und führte regelmäßig zu Systemausfällen oder Verzögerungen. Die Performance bei Datenextraktionen und -übertragungen empfanden die Entwickler als äußerst unbefriedigend, was die Zuverlässigkeit und Geschwindigkeit der Datentransfers beeinträchtigte.
Im Gegensatz dazu zeigte die Migration nach PostgreSQL enorme Vorteile, insbesondere bei der Performance von Migrationen und Abfragen. Tests mit identischen Migrationsskripten zeigten, dass eine einfache Änderung an einer Tabelle in CockroachDB mehrere Minuten dauern konnte, während PostgreSQL dieselbe Operation in wenigen Sekunden ausführte. Diese Geschwindigkeitseffekte waren besonders bei sehr großen Tabellen mit mehreren Millionen Datensätzen besonders relevant. Die operative Arbeit erleichterte sich dadurch deutlich, da Entwickler weniger Zeit mit Workarounds verbrachten und das Risiko minimiert wurde, das System durch lange Sperren zu blockieren. Auch bei Abfragen zeigte sich ein differenziertes Bild.
Einige spezielle Abfragen liefen in CockroachDB aufgrund eines robusteren Query-Optimierers schneller als in PostgreSQL. Dort agierte CockroachDB anders und führte Aggregationen effizienter durch. Allerdings trat dieser Vorteil nur bei sehr einfachen oder speziell optimierten Abfragen zutage. Die Mehrheit der realen Anwendungsfälle, insbesondere mit komplexen ORM-generierten SQL-Statements, litt in CockroachDB unter langen Antwortzeiten. Dies lag unter anderem an der Art, wie Prisma sehr komplexe und weit verzweigte SQL-Statements erzeugt, die für CockroachDBs Optimierer problematisch waren und oft zu vollständigen Tabellenscans führten.
PostgreSQL hingegen bewältigte diese komplexen Abfragen mit deutlich geringerer Latenz. Die Unterschiede zwischen den beiden Systemen erschöpften sich aber nicht nur in Performance und Support. Auch in der täglichen Verwaltung und Wartung von Datenbankoperationen traten wesentliche Differenzen auf. Während bei PostgreSQL das Abbrechen von laufenden, langen Abfragen problemlos über SQL-Clients möglich ist, gestaltete sich dies in der verteilten CockroachDB-Architektur deutlich komplizierter und riskanter. Das Handling von Indexnutzung und -pflege war ebenfalls problematisch, da CockroachDB teilweise falsche oder verwirrende Hinweise bezüglich tatsächlich genutzter Indizes gab.
Solche Diskrepanzen führten zu Verwirrungen bei Entwicklern und erschwerten die Optimierung. Auch die Infrastrukturumgebung spielte eine Rolle: Verbindungsprobleme durch die eingesetzte VPN-Lösung Tailscale führten immer wieder zu Ausfällen und Verbindungsabbrüchen in allen Entwicklungs- und Produktionsumgebungen. Diese Netzwerkprobleme waren sporadisch und unvorhersehbar, konnten aber nicht dauerhaft gelöst werden. Mit PostgreSQL tauchten diese Probleme in der Folge nicht mehr auf, was die Stabilität des Systems auf ein wesentlich höheres Niveau hob. Der eigentliche Migrationsprozess stellte die Ingenieure vor mehrere Herausforderungen.
Die größte Tabelle umfasste bereits über 100 Millionen Zeilen. Aufgrund fehlender stabiler und unterstützter Tools zur Datenmigration wurde eine individuelle ETL-Lösung in Bun entwickelt, einem gerade populären JavaScript-Runtime-Umfeld. Der Prozess bestand darin, Daten tabellenweise zu exportieren und sequenziell nach PostgreSQL zu importieren. Dabei stellte sich heraus, dass bestimmte Datenformate, insbesondere JSON- und Array-Typen, in CockroachDB anders kodiert sind als in PostgreSQL. Umfangreiche Anpassungen der Datenkonvertierung waren nötig, um die Daten konsistent und unverändert umzuziehen.
An dem geplanten Migrationsabend wurde ein leistungsstarker Cloud-Server mit 128 CPU-Kernen von Google Cloud Platform verwendet. Die Anwendung wurde provisorisch in einen Wartungsmodus versetzt, um Datenänderungen während der Migration zu verhindern. Der komplette Übertragungsprozess war nach ungefähr 15 Minuten abgeschlossen, eine beeindruckende Leistung angesichts der Datenmenge und Komplexität. Die Ausfallzeit lag unter einer Stunde, der Übergang verlief ohne Datenverlust. Selbst bei einer aggressiveren Planung hätte sich die Downtime auf etwa 15 Minuten reduzieren lassen.
Die Vorteile zeigten sich unmittelbar nach der Migration. Die durchschnittliche Antwortzeit bei Datenbankanfragen sank um ein Drittel, was sowohl die Benutzererfahrung als auch die Systemeffizienz spürbar verbesserte. Außerdem profitierte das Team von einem reichhaltigen Ökosystem an Tools für PostgreSQL, etwa PGAnalyze, mit dem bestehende Anfragen schnell und effizient optimiert werden konnten. Bereits wenige Stunden nach der Migration konnten mehrere schlecht performende Abfragen identifiziert und angepasst werden. Zusätzlich zu den Performance-Verbesserungen führte der Wechsel auch zu erheblichen Kosteneinsparungen.
Trotz der konservativen Konfiguration des neuen PostgreSQL-Clusters waren die jährlichen Betriebskosten um über 110.000 US-Dollar reduziert. Mit dem steigenden Traffic und zukünftigen Wachstumspotenzial würden sich die Ersparnisse weiter verstärken. Die Erfahrungen bei Motion zeigen exemplarisch, dass der Umstieg von einer verteilten, hochverfügbaren Lösung wie CockroachDB zu einem klassischen relationalen System wie PostgreSQL nicht nur technologisch durchführbar ist, sondern sich in vielen Anwendungsszenarien deutlich lohnt. Gerade in Setups ohne zwingenden Bedarf an Multi-Region-Verteilung oder extrem hoher Ausfallsicherheit sprechen geringe Latenzen, einfache Wartbarkeit, ein umfassendes Tooling und wirtschaftliche Aspekte stark für PostgreSQL.
