Der Einsatz der richtigen Datenbanktechnologie ist für moderne Softwareunternehmen entscheidend, um Skalierbarkeit, Performance und Kosteneffizienz zu gewährleisten. Ein besonders interessantes Szenario entsteht, wenn eine Datenbanklösung ihre Grenzen erreicht und ein Wechsel notwendig wird. So war es auch beim Unternehmen Motion, das seit 2022 auf CockroachDB setzte, schließlich aber zu PostgreSQL wechselte. Dieser Wechsel ist nicht nur aus technischer Sicht spannend, sondern bietet wertvolle Erkenntnisse für Unternehmen, die eine ähnliche Migration planen oder mit Herausforderungen im Bereich Datenbankperformance und Betriebskosten kämpfen. Motion begann seine Reise mit CockroachDB, einer verteilten SQL-Datenbank, deren Vorteile vor allem in der mühelosen horizontalen Skalierbarkeit und hohen Verfügbarkeit liegen. Die Möglichkeit, Multi-Region-Setups einfach und GDPR-konform umzusetzen, war ein entscheidender Faktor für die ursprüngliche Wahl.
Allerdings kamen mit dem Wachstum von Motion auch erhöhte Nutzungsanforderungen und weit steigende Kosten, die Mitte 2024 bereits im sechsstelligen Bereich lagen. Diese Entwicklung war für das Unternehmen Anlass, kritisch zu hinterfragen, ob die gewählte Technologie für den aktuellen Use Case weiterhin optimal ist. Ein wesentlicher Punkt war die Frage, ob ein verteilter Datenbankansatz bei einem einzigen Rechenzentrumsstandort mit einfachen Transaktionsabfragen tatsächlich gerechtfertigt ist – schließlich bieten relationale Datenbanken wie PostgreSQL in solchen Fällen oft günstigere und performantere Lösungen. Die absehbaren Migrationserfahrungen und die Möglichkeit, dank eines ORMs wie Prisma vergleichbare Abfragen einfach testen zu können, erleichterten den Entschluss zum Umstieg erheblich. Ein Kernproblem bei CockroachDB stellte die Anwendung von Datenbankschemata-Migrationen dar.
Bei wachsender Datenbankgröße führte die Ausführung von Prisma-Migrationsskripten immer wieder zu Zeitüberschreitungen, die Deployments teilweise für Stunden blockierten. Selbst das direkte Ausführen von Migrationen im CockroachDB-Interface war nur mit erheblichem manuellem Aufwand möglich, da parallele Migrationen koordiniert werden mussten. Im Gegensatz dazu bewährte sich PostgreSQL in vergleichbaren Szenarien als deutlich stabiler, indem selbst komplexe Änderungen auf einer rewound-Datenbankinstanz innerhalb von Sekunden durchgeführt wurden. Diese Migrationsproblematik führte bei Motion sogar zu betrieblichen Kompromissen, etwa dem Versuch, Migrationen größtenteils außerhalb der Datenbanklogik auszuführen oder auf notwendige CockroachDB-Updates zu verzichten, um Stabilitätsrisiken zu vermeiden. Letztendlich blieb das Team lange Zeit auf einer veralteten Cockroach-Version, was den Support erschwerte und die Problemlösungszeiten verlängerte.
Auch im Bereich ETL (Extract, Transform, Load) zeigte CockroachDB Schwächen. Die Datenintegration mit Drittanbietern wie Airbyte war nur rudimentär unterstützt und durch Alpha-Stadien sowie technische Schwachstellen wie Speicherlecks geprägt. Da zuverlässige Replikationsmechanismen fehlten, stellte dies ein erhebliches Risiko für stabile und performante Datenverarbeitungsprozesse dar. Im Vergleich dazu ist das PostgreSQL-Ökosystem mit zahlreichen ausgereiften Tools und breiter Community-Unterstützung deutlich vorteilhafter für ETL-Szenarien. Im Bereich der Abfrageperformance zeigte sich ein differenziertes Bild. Einige spezifische Abfragen wurden von CockroachDB dank ihrer fortschrittlichen Optimierung schneller ausgeführt. Jedoch übertrafen viele typische, im Alltag des Teams häufig genutzte Abfragen die Performance von PostgreSQL deutlich, teilweise um das Zwanzigfache schneller.
Besonders problematisch waren durch das ORM generierte komplexe SQL-Abfragen mit zahlreichen Joins und Verschachtelungen, bei denen CockroachDB oft auf Full-Table-Scans zurückfiel und so die Latenz signifikant anstieg. PostgreSQL durchschaut in vielen Fällen die SQL-Konstrukte besser und verwendet zielführende Indexstrukturen. Weitere negative Begleiterscheinungen bei CockroachDB erschwerten den Entwicklungsalltag und den Betrieb: So waren Meldungen zu ungenutzten Indizes im CockroachDB-UI häufig irreführend, was zu Verwirrungen und potentiellen Fehlentscheidungen führte. Das Abbrechen laufender Abfragen ist bei kommerziellen verteilten Systemen wie CockroachDB kompliziert und riskant, bei PostgreSQL hingegen unkompliziert und direkt über gängige SQL-Clients möglich. Auch die Supporterfahrung mit CockroachDB erwies sich als problematisch. Getrennte Portale, lange Antwortzeiten und aufwendige Authentifizierungsprozesse behinderten schnelle Problemlösungen.
Ein kritischer Ausfall zeigte, wie zeitintensiv der Kontakt zum Support in solchen Situationen sein kann. Solche Herausforderungen sind gerade für schnelle und agile Entwicklungsprozesse hinderlich. Zudem machte sich bei Motion die Infrastruktur bemerkbar: Häufige und nicht nachvollziehbare Verbindungsprobleme mit CockroachDB aufgrund von VPC- und DNS-Ausfällen beeinflussten verschiedenste Umgebungen negativ, von CI-Systemen über Airbyte-Connectors bis zu lokalen SQL-Clients. Bei PostgreSQL sind solche Probleme in der Regel weder bekannt noch auftreten, was den Betrieb erleichtert. Die eigentliche Migration war eine beachtliche technische Herausforderung. Mit knapp 100 Millionen Zeilen im größten Table stand das Motion-Team vor einer umfangreichen Datenmigration, die nicht durch verfügbare Tools abgedeckt war. Daher wurde eine eigene ETL-Lösung entwickelt, die mittels des modernen Backend-Runtimes Bun Skripte ausführte.
Daten wurden tabellenweise in CSV-Dateien ausgegeben und dann in parallel laufenden Prozessen nach PostgreSQL importiert. Aufwendig war jedoch die Anpassung von Datentypen: CockroachDB und PostgreSQL verwenden teils unterschiedliche Binär- und JSON-Encodings, die einen direkten Transfer unmöglich machten. Mit zusätzlichen Pipeline-Lösungen aus JavaScript-Bibliotheken gelang es, die Daten-Transformation stabil und konsistent zu gestalten. Am Tag der Migration wurde ein leistungsstarker virtueller Server mit 128 CPU-Kernen genutzt, und die Anlage wurde vorsorglich in den Wartungsmodus versetzt, um Datenverlust und Ausfälle zu vermeiden. Die komplette Migration dauerte knapp 15 Minuten, und auch wenn theoretisch eine noch kürzere Downtime möglich gewesen wäre, entschied man sich aus Sicherheitsgründen für eine Stunde Betriebspause mit gestaffeltem Traffic-Resuming.
Das Ergebnis war beeindruckend: Die Latenz sämtlicher Anfragen sank um rund ein Drittel, und dank der etablierten Tools im PostgreSQL-Ökosystem konnten viele zuvor unoptimierte Abfragen innerhalb weniger Stunden erkannt und verbessert werden. Neben Performancegewinn führte der Wechsel auch zu erheblichen Kosteneinsparungen von über 110. 000 Dollar jährlich, eine Summe, die mit dem weiterhin steigenden Traffic-Wachstum noch weiter steigen dürfte. Der Fall von Motion zeigt exemplarisch, wie wichtig eine sorgfältige Evaluierung der Datenbankstrategie ist. Technologien wie CockroachDB sind in bestimmten Anwendungsfällen und bei besonderen Anforderungen an Skalierung und Verfügbarkeit unschlagbar, aber für einzelne Regionen mit einfacher Query-Last kann die klassische relationale PostgreSQL-Datenbank Leistung, Stabilität und Kostenbilanz deutlich verbessern. Die Migration stellt keine triviale Herausforderung dar, lohnt sich aber langfristig.
Unternehmen, die ähnliche Überlegungen anstellen und vor Herausforderungen bei Skalierung, Performance oder Kosten stehen, sollten neben technischen Aspekten auch die betriebliche Sicht, Wartbarkeit und Community-Unterstützung bei ihrer Datenbankauswahl mitbeachten. Die adjustierte Balance zwischen modernen verteilten Systemen und bewährten relationalen Datenbanken ist essentiell, um nachhaltig hohe Qualität und Wirtschaftlichkeit zu gewährleisten. Abschließend bleibt festzuhalten, dass Migrationen von komplexen Datenbanklösungen ein interdisziplinäres Projekt erfordern: Technisches Know-how, präzise Planung und ausreichende Testing-Strategien sind unerlässlich, um Ausfallzeiten zu minimieren und Datenkonsistenz zu garantieren. Dank der offenen und vielseitigen Natur von PostgreSQL sowie seines lebendigen Ökosystems eröffnen sich jedoch vielfältige Möglichkeiten, die eigene Dateninfrastruktur langfristig performant und kosteneffizient zu gestalten.
