Die Wahl der richtigen Datenbank ist für jedes technologiegetriebene Unternehmen eine entscheidende Weiche. Besonders wenn das Datenvolumen wächst und gleichzeitig hohe Verfügbarkeit sowie rechtliche Anforderungen wie Datenlokalisierung zu berücksichtigen sind, steht die Frage nach Skalierbarkeit und Kosten im Vordergrund. Ein Praxisbeispiel, das zunehmend an Relevanz gewinnt, ist die Migration von CockroachDB zu PostgreSQL – zwei mächtige, aber grundverschiedene Systeme, die beide ihre Stärken und Schwächen haben. Dieser Beitrag beleuchtet die die Gründe, Herausforderungen und Erkenntnisse eines solchen Umstiegs anhand realer Erfahrungen eines Startup-Unternehmens, das diesen Wechsel vollzogen hat. Anfangs setzte das Unternehmen auf CockroachDB aufgrund seiner verteilten Architektur und der Fähigkeit für müheloses horizontales Skalieren, vor allem bei Multi-Region Setups, die durch Datenschutzbestimmungen wie GDPR relevant werden.
Die SQL-Kompatibilität und extrem hohe Verfügbarkeit machten die Datenbank zudem attraktiv. Doch mit wachsendem Datenvolumen und steigender Nutzung stiegen auch die Kosten signifikant an – bis zu einem Punkt, an dem die jährliche CockroachDB-Rechnung in den mittleren sechsstelligen Bereich wuchs. Gleichzeitig war der Betrieb noch auf eine einzelne Region beschränkt, mit relativ einfachen transaktionalen Abfragen. Dies war ein sensibles Alarmsignal: Warum weiterhin den relativ teuren Overhead einer verteilten Datenbank tragen, wenn eine traditionelle Postgres-Instanz die Anforderungen erfüllen könnte? Einer der ersten praktischen Stolpersteine im Alltag mit CockroachDB waren die Schwierigkeiten bei Datenbank-Migrationen. Die eingesetzte Objekt-Relationale Abbildung (ORM) „Prisma“ kämpfte immer häufiger mit Timeouts beim Anwenden von Schemaänderungen.
Dies führte zu manuellen Eingriffen direkt auf der Datenbank, was den Deploy-Prozess blockierte und operative Risiken erhöhte. Die latenten Timeouts trieben die Entwickler dazu, aus Sorge vor Sperren und Ausfällen geheime Workarounds und Operationen außerhalb der Datenbankoberfläche anzuwenden. Zudem war es nicht mehr möglich, CockroachDB auf aktuelle Softwareversionen zu upgraden, da Migrationen nicht zuverlässig durchführbar waren – ein weiterer Faktor für den Wechselwunsch. Neben Migrationen beeinträchtigten Timeouts auch externe Prozesse wie ETL-Jobs, die über Werkzeuge wie Airbyte durchgeführt wurden. Mit begrenzter und teils noch instabiler Unterstützung für CockroachDB-Replicationsquellen entstanden immer wieder Fehler, Verzögerungen und ineffiziente Durchläufe mit schwerwiegenden Auswirkungen auf die Datenpipeline.
Die Performance von Abfragen war ein weiteres unternehmensrelevantes Thema. Während CockroachDB in einigen Spezialfällen dank seines optimierten Query Planners schneller agierte, zeigte sich in der Mehrzahl der realen Anwendungsfälle ein gegenteiliger Trend. Komplexe SQL-Statements, die durch Prisma generiert wurden, führten zu ineffizienten Volltabellenscans auf CockroachDB. Im Gegensatz dazu war PostgreSQL bei diesen Abfragen teilweise um ein Vielfaches schneller. Beispiele konkreter SQL-Queries bestätigen diesen Unterschied eindrücklich, sodass der Performance-Vorteil von CockroachDB im Unternehmensalltag an Bedeutung verlor.
Auch aus Anwendersicht traten Nachteile der CockroachDB klar zutage. Die Benutzeroberfläche lieferte teils irreführende Empfehlungen zu Indexnutzung, was Entwickler verunsicherte. Das Abbrechen von laufenden, ressourcenintensiven Abfragen gestaltete sich extrem kompliziert, da CockroachDB ein verteiltes Cluster benötigt, bei dem eine einzelne Abbruchaktion nicht immer zuverlässig über alle Knoten hinweg umgesetzt wurde. Der Support war speziell in kritischen Situationen langsam und unpraktisch, da er über eine separate Plattform mit aufwändigen Authentifizierungsprozessen lief. Nicht zuletzt führten wiederkehrende Verbindungsprobleme, verursacht durch Netzwerksoftware wie Tailscale, zu spontanen, plötzlich auftretenden und wieder verschwindenden Fehlern, die sich trotz umfangreicher Bemühungen nicht dauerhaft beheben ließen.
Für das Unternehmen war klar, dass eine Migration zu PostgreSQL langfristig sowohl technische Vorteile als auch Kosteneinsparungen bieten würde. Die größte Tabelle zählte etwa 100 Millionen Datensätze, was eine herkömmliche Migration vor große Herausforderungen stellte. Da es kaum ausgereifte ETL-Lösungen für CockroachDB gab, entwickelte der verantwortliche Ingenieur eine maßgeschneiderte ETL-Pipeline. Mithilfe des damals aufkommenden Frameworks Bun wurde ein Verfahren implementiert, das zunächst das gesamte Datenbankschema ausliest, anschließend alle Tabelleninhalte in CSV-Dateien auslagert und dann für jede Tabelle einen separaten Streaming-Prozess startet, der die Daten in die PostgreSQL-Datenbank importiert. Dabei galt es, eine nicht zu unterschätzende technische Hürde zu meistern: Unterschiede in der internen Kodierung von JSON- und Array-Datentypen zwischen CockroachDB und PostgreSQL erforderten eine spezielle Vorverarbeitung und Transformation der Daten, um die Kompatibilität bei gleichzeitigem Erhalt der Datenintegrität sicherzustellen.
Nach intensiven Testläufen erfolgte schließlich die produktive Migration. Unter Verwendung einer leistungsstarken Cloud-VM mit 128 Kerne wurde die Migration über Nacht durchgeführt. Insgesamt dauerte der Prozess inklusive Wartungsmodus, Datenübertragung und Systemtests etwa 15 Minuten. Ein beachtlicher Erfolg bei minimaler Ausfallzeit und ohne Datenverlust. Die unmittelbaren Auswirkungen auf den Betrieb waren deutlich messbar.
Die aggregierten Anfrage-Latenzen sanken um etwa ein Drittel. Durch den Zugriff auf das reiche Ökosystem und die verschiedenen Optimierungs-Tools von PostgreSQL konnten mehrere ineffiziente Abfragen innerhalb kurzer Zeit verbessert werden. Zusätzlich sparte das Unternehmen durch den Umstieg mehr als 110.000 US-Dollar jährlich an reinen Datenbankkosten ein – eine Summe, die mit weiterem Wachstum des Systems sukzessive steigen wird. Zusammenfassend zeigt diese Migration exemplarisch, wie wichtig es ist, technische Entscheidungen stets dem realen Anwendungsfall und den wirtschaftlichen Rahmenbedingungen anzupassen.
