Seit Anfang 2022 nutzte das Unternehmen Motion CockroachDB als zentrale Datenbanklösung. CockroachDB überzeugte mit Eigenschaften wie nahtloser horizontaler Skalierung, hoher Verfügbarkeit und einer SQL-kompatiblen Schnittstelle. Besonders im Hinblick auf Multiregion-Szenarien, die aufgrund von Datenschutzanforderungen wie der DSGVO wichtig werden würden, schien CockroachDB eine zukunftssichere Wahl zu sein. Doch mit zunehmendem Wachstum der Plattform traten immer mehr Herausforderungen auf, die letztlich den Entschluss zur Migration auf PostgreSQL prägten. Eine der Hauptursachen für den Wechsel waren die stark steigenden Kosten. Bis 2024 hatte sich die Rechnung für CockroachDB auf einen mittleren sechsstelligen Betrag verfünffacht, obwohl das System zu diesem Zeitpunkt noch in einer einzigen Region operierte und lediglich einfache transaktionale Abfragen ausführte. Die Frage stellte sich, ob die teure Infrastruktur eines verteilten Systems unter diesen Umständen gerechtfertigt war.
Gleichzeitig gab es keine Kunden, die eine Datenlokalisierung verlangten, was eine der ursprünglichen Rechtfertigungen für CockroachDB war. Ein weiterer bedeutender Schmerzpunkt waren die Migrationsprozesse. Mit wachsender Datenbankgröße führte das Anwenden von Migrationen via Prisma immer häufiger zu Timeouts. Diese Verzögerungen führten nicht nur zu erheblichen Ausfallzeiten während der Deployments, sondern zwangen Entwickler oft zu manuellen Eingriffen, um Migrationen direkt in CockroachDB einzuspielen. Solche operativen Umwege behinderten den Entwicklungsfluss massiv und sorgten für Unsicherheit hinsichtlich der Stabilität in kritischen Momenten. Im Vergleich dazu zeigte PostgreSQL erhebliche Performance-Vorteile bei denselben Migrationstests. Ein einfaches Beispiel war das Hinzufügen einer neuen Spalte in einer großen Tabelle, das auf einem zurückdatierten Datenstand in CockroachDB noch Minuten dauerte, während PostgreSQL den Vorgang in Sekunden abschloss.
Die fehlenden Timeouts und die geringe Latenz bei Migrationen ermöglichten nicht nur schnellere Releases, sondern auch mehr Vertrauen in den Änderungsprozess. Die Probleme mit Timeouts beschränkten sich jedoch nicht nur auf Migrationen. Auch bei ETL-Prozessen (Extraktion, Transformation und Laden von Daten) führten sie zu ständigen Fehlermeldungen und Abbrüchen. Die Nutzung von Airbyte, einem der wenigen verfügbaren Tools für CockroachDB-Replikation, erwies sich als suboptimal, da es sich bis 2024 noch im Alpha-Stadium befand und unter anderem einen Memory-Leak aufwies. Die Instabilität führte zu verzögerten Datenströmen, die die gesamte Datenverarbeitung beeinträchtigten. Interessant war der direkte Vergleich der Abfragegeschwindigkeiten zwischen CockroachDB und PostgreSQL. Einige komplexe Abfragen konnte CockroachDB dank seines Optimierers schneller lösen, da der Query Planner Aggregationen effizienter durchführte.
Allerdings zeigten sich im Alltag der Entwickler häufiger Fälle, in denen sophisticated SQL-Generierungen, vor allem durch das ORM Prisma, CockroachDB zuwendeten, ineffiziente Volltabellenscans auszuführen – was zu teils bis zu zwanzigmal langsameren Abfragen im Vergleich zu PostgreSQL führte. Die komplexen SQL-Abfragen, die Prisma generierte, umfassten oft viele Joins, eingeschachtelte LATERAL Joins und zahlreiche Filter, die für CockroachDB wegen seiner Optimierungsstrategie suboptimal umgesetzt wurden. PostgreSQL dagegen schaffte es in vielen Fällen, diese Anfragen effizienter und schneller auszuführen, was sich direkt in einer besseren User Experience sowie geringeren Wartezeiten ausdrückte. Neben Performancefragen mussten auch diverse UX-Probleme in CockroachDB bewältigt werden.
Das Management-Interface zeigte Unstimmigkeiten bei der Anzeige von nicht genutzten Indizes – teilweise wurden noch aktive Indizes als ungenutzt angezeigt, was Entwickler verwirrte und zu Fehlentscheidungen bei der Indexpflege führte. Darüber hinaus war das Abbrechen von laufenden Abfragen kompliziert: Im Gegensatz zu PostgreSQL, wo Nutzer direkt in beliebten SQL-Clients auf “Abbrechen” klicken können, musste man bei CockroachDB in der Konsole manuell jeden Knotenpunkt adressieren und hoffen, dass die Abbruchbefehle wirklich ausgeführt wurden. Einmal führte das Scheitern sogar zu Stresssituationen im Betrieb. Auch die Support-Struktur von CockroachDB empfanden die Anwender als hinderlich. Der Support erfolgte über eine separate Plattform, was Doppelarbeiten beim Einloggen und der Problembeschreibung nach sich zog. Die Reaktionszeiten verzögerten sich teilweise auf eine Woche, eine Zeitspanne, die insbesondere bei kritischen Bugs nicht akzeptabel war.
Ein solcher Vorfall führte sogar zu einem Systemausfall, bei dem die Trennung der Portale zusätzlichen Frust brachte. Nicht zuletzt kam es durch die VPC-Kommunikation und das Netzwerk immer wieder zu unerklärlichen Ausfällen und Verbindungsproblemen. Der Einsatz von Tailscale Half-VPNs führte zu sporadischen DNS-Fehlern und Nichterreichbarkeit von Datenbankknoten, was in keiner Weise reproduzierbar war und auch bei PostgreSQL nicht auftrat. Diese Instabilität war ein nicht zu vernachlässigender Faktor für die Entscheidung zur Migration. Die eigentliche Migration war komplex aufgrund der großen Datenbasis – die größte Tabelle wies zu jener Zeit etwa 100 Millionen Datensätze auf. Standard-ETL-Tools waren kaum verfügbar, weshalb ein maßgeschneidertes Skript entwickelt wurde. Interessanterweise wurde hierfür die noch junge Technologie Bun verwendet, da sie das Streamen und parallele Verarbeiten von Daten gut unterstützte.
Die Strategie bestand darin, zunächst die gesamte Datenbank schematisch zu erfassen, dann Tabellendaten auf Disk auszugeben und schließlich für jede Tabelle einen Bun-Prozess zu starten, der diese CSV-Daten in PostgreSQL einspielte. Im Verlauf der Tests zeigte sich, dass CockroachDB bestimmte Spaltentypen in JSON und Arrays leicht anders codierte als PostgreSQL. Daraufhin musste die ETL-Pipeline um eine intelligente Kreuzkonvertierung ergänzt werden, um die Daten konsistent und unverfälscht in das neue System zu übertragen. Am Abend der Migration wurde eine leistungsstarke virtuelle Maschine mit 128 CPU-Kernen in Google Cloud gestartet und die Anwendung in den Wartungsmodus versetzt. Die Datenmigration dauerte etwa 15 Minuten, inklusive aller Schritte vom Dumpen bis zum Einspielen in PostgreSQL. Die gesamte Downtime blieb unter einer Stunde, was für eine Migration dieser Größenordnung außergewöhnlich war. Nach der Migration besserten sich die Betriebsparameter signifikant.
Aggregierte Anfrageverzögerungen sanken um etwa ein Drittel, und dank des Ökosystems rund um PostgreSQL, etwa Tools wie PGAnalyze, konnten schnell mehrere ineffiziente Abfragen erkannt und optimiert werden. Dabei steigerte sich nicht nur die Performance, sondern auch die Stabilität im Produktivbetrieb. Aus wirtschaftlicher Sicht lohnte sich die Migration ebenfalls: Trotz großzügiger Ressourcenplanung für das PostgreSQL-Cluster konnte das Unternehmen jährlich über 110. 000 US-Dollar einsparen. Mit zunehmendem Traffic wäre diese Ersparnis wahrscheinlich noch größer gewesen. Zusammenfassend zeigt der Wechsel von CockroachDB zu PostgreSQL exemplarisch, wie selbst technologisch fortgeschrittene Lösungen in bestimmten Anwendungsszenarien ihre Grenzen haben. Während CockroachDB bei Multi-Region-Setups und hochverteilten Architekturen glänzt, ist PostgreSQL für viele typische Transaktionslasten effizienter, kostengünstiger und im täglichen Betrieb einfacher zu handhaben.
Die Migration stellte zunächst eine Herausforderung dar, eröffnete aber danach neue Möglichkeiten in der Performanceoptimierung und der betrieblichen Stabilität. Für Unternehmen, die ähnliche Plattformen betreiben und über eine Migration nachdenken, ist es wichtig, die langfristigen Kosten, das betriebliche Risiko und die Verfügbarkeit von Werkzeugen für ETL und Wartung gegeneinander abzuwägen. Die Erfahrungen von Motion unterstreichen, dass eine gut durchdachte Migration mit entsprechender Vorbereitung und Automatisierung eine nachhaltige Optimierung ermöglichen kann, die sich letztendlich auf alle Bereiche – von Entwicklerproduktivität bis hin zu Betriebskosten – positiv auswirkt. Wer sich für tiefgehende technische Problemstellungen interessiert und großen Einfluss auf Systemarchitekturen nehmen möchte, findet in solchen Projekten spannende Herausforderungen und Chancen.
Das Ökosystem rund um PostgreSQL bietet dank eines breit gefächerten Toolsets und einer aktiven Community beste Voraussetzungen, um moderne Anwendungen effizient und skalierbar zu betreiben.
