Viele Unternehmen stehen heutzutage vor der Herausforderung, die passende Datenbanklösung für ihre wachsenden Anforderungen zu finden. Besonders im Bereich datenintensiver Anwendungen, bei denen Skalierbarkeit, Verfügbarkeit und Performance essenziell sind, gewinnen relationale Datenbanksysteme immer mehr an Bedeutung. Im Laufe der Zeit zeigt sich jedoch, dass nicht jede Lösung dauerhaft optimal ist. Ein Beispiel dafür ist der Wechsel von CockroachDB zu PostgreSQL, der in den letzten Jahren eindrucksvoll verdeutlicht hat, wie wichtig es ist, die richtige Balance zwischen Skalierbarkeit und Kosten zu finden. Die Anfänge der Migration liegen bei Motion, einem Unternehmen, das seit Anfang 2022 auf CockroachDB setzte. CockroachDB punktete damals vor allem durch seine unkomplizierte horizontale Skalierbarkeit und die einfache Implementierung eines Multi-Region-Setups – ein Aspekt, der insbesondere aufgrund der DSGVO zunehmend bedeutender wurde.
Darüber hinaus bot die Datenbank eine hohe Verfügbarkeit und eine SQL-kompatible Schnittstelle, was die Integration in bestehende Systeme erleichterte. Trotz dieser Stärken führte das Wachstum des Unternehmens zu einem rapiden Anstieg der Datenbankkosten. Bis 2024 hatten sich die Ausgaben für CockroachDB verfielfacht und erreichten einen mittleren sechsstelligen Bereich. Zudem zeigten sich immer häufiger technische Einschränkungen und Engpässe, die mit dem Einsatz einer verteilten Datenbank einhergingen. Interessanterweise erforderte damals noch kein Kunde Datenlokalisierung, weshalb der Einsatz einer auf Multi-Region ausgelegten verteilten Datenbank nicht mehr die beste Option darstellte. Als Folge dieser Herausforderungen begann das Entwicklerteam, mithilfe eines Object-Relational Mappings (ORM) – in diesem Fall Prisma –, Vergleiche zwischen CockroachDB und PostgreSQL direkt im System durchzuführen. Eines der drängendsten Probleme waren zeitintensive Migrationen.
Bei CockroachDB kam es regelmäßig zu Timeout-Fehlern während der Migrationen, was bedeutete, dass Entwickler oft direkt auf der Datenbank manuell Migrationen ausführen mussten. Diese Vorgänge dauerten teilweise mehrere Stunden und behinderten damit den gesamten Deployment-Prozess. Im Vergleich dazu verlief dasselbe Migrationsexperiment mit PostgreSQL überraschend schnell. Ein einfacher Eingriff, wie das Hinzufügen einer neuen Spalte in einer großen Tabelle, dauerte im PostgreSQL-System nur wenige Sekunden. Die drastischen Unterschiede in der Geschwindigkeit führten dazu, dass sich das Team vermehrt von der CockroachDB abwandte, da die fortgeschrittenen Migrationsprobleme bereits zu einem Flaschenhals bei Updates und Wartungen geworden waren. Ein weiteres Hindernis zeigte sich bei den ETL-Prozessen (Extract, Transform, Load), die für das Datenmanagement essentiell sind. CockroachDB verfügte kaum über ausgereifte Unterstützung für ETL-Tools.
Das Unternehmen setzte die Alpha-Phase eines Airbyte-Connectors ein, doch dieser litt unter einer Speicherleckage, was zu ständigen Ausfällen führte. Solche wiederkehrenden Fehler bedeuteten für das Team nicht nur technischen Aufwand, sondern auch Produktivitätseinbußen. Vergleicht man die Performance von Abfragen, so offenbart sich ein differenziertes Bild. Einige komplexe Queries liefen dank des optimierten Anfragemanagers der CockroachDB schneller als bei PostgreSQL. Dies traf jedoch eher auf spezielle Fälle zu, bei denen CockroachDB die Aggregationen besser erkennen und verarbeiten konnte. Im Alltagsbetrieb dominierten dafür häufig Situationen, in denen Prisma komplexe und ineffiziente SQL-Anfragen generierte, die beim Cockroach-Backend zu langen Volltabellenscans führten. PostgreSQL bewältigte solche Anfragen in der Regel deutlich schneller. Letztendlich erwies sich PostgreSQL als die bessere Wahl für die Mehrheit der realen Anwendungsfälle.
Nicht zu vernachlässigen waren auch Probleme, die in der Nutzeroberfläche für die Entwickler auftraten. Beispielsweise war die Anzeige von nicht genutzten Indizes in CockroachDB oft irreführend, was die Entwickler verwirrte und zu unnötigen oder sogar falschen Entscheidungen bei der Indexpflege führte. Auch das Abbrechen laufender Abfragen gestaltete sich in der verteilten CockroachDB komplexer und riskanter, da die Abbruchbefehle auf mehreren Knoten gleichzeitig ausgeführt werden mussten und nicht immer zuverlässig wirkten. Der Support von CockroachDB stellte zudem eine Herausforderung dar, da er auf einem separaten Portal mit eigenständiger Authentifizierung angeboten wurde und die Antwortzeiten bei kritischen Problemen langsam waren. Dies führte in Notfällen zu verzögerter Hilfe, was die Zuverlässigkeit beeinträchtigte.
Ein wiederkehrendes Netzwerkproblem mit Verbindungen über Tailscale-VPN-Verbindungen zwischen den CockroachDB-Clustern und den Entwicklungs- sowie Produktionsumgebungen erschwerte den Betrieb zusätzlich. Dieses Problem war nicht dauerhaft nachvollziehbar und trat sporadisch auf, was die Fehlersuche erheblich erschwerte. Nach dem Wechsel zu PostgreSQL traten solche Probleme nicht mehr auf. Der technische Kern der Migration bestand darin, eine große Datenbank mit mehreren hundert Millionen Datensätzen effizient zu übertragen. Da es nur wenige robuste ETL-Lösungen für CockroachDB gab, entwickelte das Team ein eigenes Tool auf Basis von Bun, einer modernen Javascript-Laufzeitumgebung. Das Tool las das Schema der bestehenden Datenbank aus, exportierte die Daten in CSV-Dateien und importierte diese datenstrombasiert in PostgreSQL.
Während dieses Prozesses stellte sich heraus, dass CockroachDB bei JSON- und Array-Datentypen eine leicht abweichende Byte-Kodierung verwendete, die vor dem Import in PostgreSQL konvertiert werden musste, um Datenintegrität zu gewährleisten. Am Tag der Migration wurde ein leistungsstarker Cloud-Server mit 128 Prozessorkernen gewählt, um einen reibungslosen Ablauf zu garantieren. Nach Aktivierung des Wartungsmodus dauerte die vollständige Datenübertragung lediglich 15 Minuten. Zum Schutz vor unerwarteten Fehlern wurde bewusst eine Downtime von ungefähr einer Stunde eingeplant, die auch so eingehalten wurde. Das Ergebnis war eine Null-Datenverlust-Migration, was in der Größenordnung mit 100 Millionen Datensätzen ein verlässlicher Beleg für die Qualität der Umsetzung war. Im Nachgang konnte das Team eine sofortige Verbesserung der Systemperformance feststellen.
Die durchschnittlichen Antwortzeiten der Anfragen reduzierten sich um ein Drittel, was den Nutzern ein deutlich besseres Erlebnis brachte. Darüber hinaus waren dank des umfangreichen PostgreSQL-Ökosystems und Analysewerkzeugen wie PGAnalyze schnelle Optimierungen bei Abfragen möglich. So konnten innerhalb weniger Stunden mehrere zuvor nicht performante Abfragen erheblich beschleunigt werden. Finanziell bedeutete die Umstellung eine signifikante Kosteneinsparung. Auch bei vergleichsweise konservativ ausgestatteter PostgreSQL-Installation konnten jährlich mehr als 110. 000 US-Dollar eingespart werden. Bei weiterem Wachstum des Datenverkehrs ist mit zusätzlichen Einsparungen zu rechnen, was die Wirtschaftlichkeit der Migration unterstreicht. Zusammenfassend lässt sich sagen, dass die Migration von CockroachDB zu PostgreSQL bei Motion ein erfolgreiches Beispiel für die Vorteile einer gut durchdachten Datenbankumstellung ist.
Trotz der technologischen Anziehungskraft verteilter Datenbanksysteme zeigte sich, dass in bestimmten Anwendungsfällen ein klassisches relationales Datenbankmanagementsystem die bessere Wahl sein kann – insbesondere, wenn Kosten, Performance und Betriebssicherheit im Fokus stehen. Wer technische Herausforderungen dieser Art schätzt und gerne in einem dynamischen Umfeld mitwirken möchte, für den eröffnen sich bei Motion spannende Karrierechancen. Das Unternehmen sucht weiterhin Talente, die mit innovativen Lösungen den Bereich AI-gestützter Workflow-Systeme voranbringen möchten und dabei die technische Basis modernisieren und stabil gestalten wollen. Die Geschichte des Wechsels von CockroachDB zu PostgreSQL verdeutlicht eindrucksvoll, dass die Wahl der Datenbanktechnologie stets wohlüberlegt erfolgen sollte und regelmäßige Evaluierungen helfen, die beste Lösung für das jeweilige Geschäftsmodell zu finden.
Dies sorgt nicht nur für technische Effizienz, sondern hat auch direkten Einfluss auf die Unternehmenskosten und die Zufriedenheit der Anwender.
