Die Wahl der richtigen Datenbank ist für Unternehmen angesichts wachsender Datenmengen und steigender Nutzerzahlen von größter Bedeutung. In dieser Hinsicht stand auch das Team von Motion vor einer bedeutenden Entscheidung: Anfang 2022 vertraute das Unternehmen auf CockroachDB, eine verteilte SQL-Datenbank, die durch horizontale Skalierbarkeit und Hochverfügbarkeit überzeugte. Doch mit dem Wachstum von Motion zeigten sich zunehmend Grenzen und Herausforderungen, die letztlich zu einer Migration hin zu Postgres führten – einem traditionellen, etablierten Datenbanksystem. In diesem Beitrag beleuchten wir die Beweggründe, Herausforderungen und Erfahrungen bei der Migration zu Postgres sowie die Auswirkungen auf Performance und Kostenstruktur. Motion startete mit CockroachDB aufgrund der starken Eigenschaften im Bereich Multi-Region und Skalierbarkeit.
Gerade vor dem Hintergrund der anstehenden Datenschutzanforderungen (wie der DSGVO), die eine Datenlokalisierung in verschiedenen Regionen erfordern, erschien eine verteilte Datenbank als logische Wahl. CockroachDB bot eine SQL-kompatible Oberfläche, was die Arbeit mit bisherigen Tools und ORM-Systemen erleichterte. Allerdings nutzte Motion die Datenbank ohne Multi-Region-Setup, denn der Großteil der Anfragen erfolgte aus einer einzigen Region und die Datenbankabfragen blieben vorwiegend simpel und transaktional. Im Verlauf des Unternehmenswachstums stiegen die Nutzung und die Kosten für die CockroachDB erheblich an. Bis 2024 vervielfachte sich die Datenbankrechnung auf mittlere sechsstellige Beträge, ohne dass der entsprechende Mehrwert der verteilt skalierbaren Architektur wirklich zum Tragen kam. Zudem traten immer dann Probleme auf, wenn umfangreiche Datenbankmigrationen anstanden.
Das ORM Prisma, das Motion für die Datenbankinteraktionen einsetzte, geriet regelmäßig an seine Grenzen und führte bei komplexen Migrationen zu Timeouts. Diese Verzögerungen führten zu längeren Deploy-Phasen, wodurch manuelle Eingriffe am Cockroach-Backend notwendig wurden und häufig mehrere Stunden Downtime in Kauf genommen werden mussten. Im Gegensatz dazu zeigte Postgres in Tests beeindruckende Vorteile: Beispielsweise dauerte dieselbe Migration, die in CockroachDB zu langen Timeouts führte, auf einer vergleichbaren Postgres-Datenbank nur wenige Sekunden. Dieses deutlich bessere Verhalten von Postgres bei Migrationsprozessen stellte einen entscheidenden Faktor für den Wechsel dar. Die Möglichkeit, schnell und zuverlässig Datenbankschemata anzupassen, ist für agile Entwicklungsprozesse essentiell und kann bei ineffizienten Migrationen zum echten Bottleneck werden. Die Herausforderungen beschränkten sich aber nicht nur auf Migrationen.
Auch die ETL-Prozesse (Extract, Transform, Load), die für die Datenintegration nötig waren, zeigten Schwachstellen. Das Team bei Motion setzte auf Airbyte als ETL-Connector, der aber für CockroachDB lange Zeit nur eine Alpha-Version bot und mit einer speicherintensiven Fehlfunktion kämpfte. Diese Instabilitäten führten zu regelmäßigen Ausfällen und täglichem manuellen Eingreifen, was die Zuverlässigkeit der Datenflüsse stark beeinträchtigte. Im Vergleich dazu ist das Postgres-Ökosystem mit seinen ausgereiften ETL-Unterstützungen und stabilen Tools deutlich robuster und anwenderfreundlicher. Spannend waren auch die Unterschiede bei den Abfragegeschwindigkeiten: Obwohl CockroachDB in einigen Spezialfällen dank seines Optimizers Vorteile zeigte und bestimmte Anfragen schneller als Postgres bearbeiten konnte, überwiegen die Nachteile.
Viele von Motion verwendete Abfragen zeigten unter Cockroach hohe Latenzen, da das ORM Prisma komplexe, ineffiziente SQL-Abfragen generierte, die Cockroach-Optimizer trotz ihrer Intelligenz nicht immer optimal verarbeiten konnten. Während Postgres bei realen Anwendungsszenarien meist eine drei- bis zwanzigfache Geschwindigkeit gegenüber Cockroach erreichte, führten ineffiziente Scan-Strategien und Planschwächen bei letzterem zu spürbaren Nutzungserfahrungsproblemen. Zudem führten UI- und Bedienungsschwierigkeiten auf Seiten der CockroachDB-Administration zu zusätzlichem Frust. Beispielsweise ließen sich laufende Abfragen auf CockroachDB nicht einfach über gängige SQL-Clients abbrechen, was in Mehrknoten-Clustern zu kritischen Blockaden führen konnte. Auch die Verwaltung von Indizes mit konfliktträchtigen Empfehlungen erschwerte Entwicklern die Arbeit.
Der Supportprozess bei Cockroach war zudem wenig benutzerfreundlich und die lange Reaktionszeit bei ernsthaften Problemen schränkte die Produktivität zusätzlich ein. Ein weiteres technisches Ärgernis war die instabile Netzwerkverbindung, vor allem bei der Nutzung von VPNs wie Tailscale. Diese sporadischen Verbindungsabbrüche bei CockroachDB traten in allen Arbeitsumgebungen – von der CI-Umgebung bis zum lokalen Client – auf und ließen sich trotz zahlreicher Versuche nicht dauerhaft beheben. Mit Postgres hatten die Entwickler dagegen keinerlei entsprechende Probleme. Die Migration zu Postgres stellte vor allem wegen der enormen Datenmengen eine Herausforderung dar: Die größte Tabelle umfasste etwa 100 Millionen Datensätze. Da es an ausgereiften ETL-Lösungen im Cockroach-Umfeld mangelte, entwickelte Motion eine eigene Streaming-Datenpipeline mit Bun, einer plattformübergreifenden JavaScript-Laufzeitumgebung.
Dieses Tool exportierte zunächst die Daten tabellenweise in CSV-Dateien, die dann parallel per Stream in Postgres importiert wurden. Die anfänglichen Probleme bestanden in der unterschiedlichen Byte-Codierung von JSON- und Array-Datentypen zwischen Cockroach und Postgres, die durch eine maßgeschneiderte Konvertierungs-Pipeline gelöst wurden. Der eigentliche Migrationsprozess verlief am Abend des Umstiegs schnell und kontrolliert: Nach Aktivierung des Wartungsmodus auf der Plattform wurde die Migration in etwa 15 Minuten abgeschlossen. Die Transparenz und Verlässlichkeit dieses Prozesses ermöglichte es, Ausfallzeiten gering zu halten – unter einer Stunde, bei null Datenverlust. Im Nachgang führte der Wechsel zu Postgres zu einer sofort sichtbaren Verbesserung der Systemlatenz um etwa ein Drittel und ermöglichte dank zahlreicher etablierter Toolings eine rasche Optimierung unperformanter Datenbankabfragen.
Auch finanziell zahlte sich die Migration aus: Trotz Überprovisionierung des neuen Postgres-Clusters wurden die jährlichen Kosten um über 110. 000 US-Dollar reduziert, ein Effekt, der sich mit weiterem Wachstum der Datenbankstruktur potenziell noch verstärken dürfte. Darüber hinaus fühlt sich das Entwicklerteam durch die Stabilität, die schnellen Migrationszyklen und die gute Toolunterstützung in Postgres insgesamt produktiver und weniger eingeschränkt. Zusammenfassend zeigt der Erfahrungsbericht von Motion exemplarisch die Vorteile einer wohlüberlegten Datenbankmigration von einem spezialisierten, verteilten System zu einem ausgereiften relationalen Datenbanksystem. Trotz der ursprünglichen Faszination von CockroachDB und der damit verbundenen technischen Innovationen wurde schnell klar, dass für das konkrete Nutzungsszenario klassische Stärken wie Zuverlässigkeit, bekannte Migrationspfade und Werkzeugvielfalt einen höheren Wert besitzen.
Die von Motion entwickelte individualisierte ETL-Lösung stellte dabei sicher, dass auch bei großen Datenmengen ein zuverlässiger Umstieg möglich war. Unternehmen, die vor einer ähnlichen Entscheidung stehen, sollten neben den offensichtlichen Skalierbarkeitsargumenten auch die langfristigen Betriebskosten, die Performance unter realen Arbeitslasten, die Stabilität der ETL-Prozesse sowie die Verfügbarkeit von Support und Software-Werkzeugen bewerten. Die Migration hin zu Postgres beweist, dass der Erfolg eines modernen datengetriebenen Unternehmens maßgeblich von passenden Infrastrukturentscheidungen abhängt – und dass etablierte Technologien oft die pragmatischere Wahl für nachhaltigen Betrieb und Wachstum darstellen. Das Team von Motion sieht der Zukunft mit Postgres optimistisch entgegen und betont, dass eine gut geplante Datenmigration nicht nur die technischen Abläufe verbessert, sondern auch signifikant zur Kosteneffizienz beiträgt.
Für Entwickler und technische Entscheider lohnt sich der genaue Blick auf Datenbanklösungen abseits des Hypes, um eine optimale Balance für aktuelle und zukünftige Anforderungen zu finden.
