Seit Anfang 2022 setzte das Unternehmen Motion auf CockroachDB, eine verteilte SQL-Datenbank, die vor allem für ihre mühelose horizontale Skalierbarkeit, besonders in multi-regionalen Umgebungen, sowie ihre hohe Verfügbarkeit bekannt ist. Die Entscheidung für CockroachDB beruhte vor allem auf Bedenken hinsichtlich einer zukünftigen Multi-Region-Anforderung, die durch die Datenschutz-Grundverordnung (DSGVO) vorgegeben werden könnte. Man wollte bereits früh auf eine Infrastruktur setzen, die sich in einem solchen Szenario gut aufstellen lässt. Doch mit dem Wachstum von Motion wuchsen auch die Herausforderungen, die mit CockroachDB einhergingen. Die Kosten explodierten und die Performance begann zu leiden, was letztlich die Entscheidung zum Wechsel auf Postgres begünstigte. Ursprünglich erfüllte CockroachDB viele Anforderungen und stellte sich als attraktive Lösung dar.
Das Problem zeigte sich jedoch vor allem 2024, als die Kosten im Vergleich zum Startzeitpunkt auf das Fünffache anstiegen und sich Kritikpunkte in der Nutzung abzeichneten. Obwohl Datenlokalisierungsanforderungen durch Kunden noch nicht umgesetzt werden mussten und die Datenbank noch in einer Region betrieben wurde, erschien die Nutzung einer verteilten Datenbank mit ihren Ineffizienzen und hohen Kosten hinterfragt. Grundsätzlich stellen sich Unternehmen oft die Frage, warum für einfache, primär transaktionale Abfragen eine hochskalierbare, teure und komplexe Lösung genutzt werden sollte, wenn diese den Bedarf nicht rechtfertigt. Ein großer Vorteil für Motion war die Verwendung eines ORMs, das Vergleiche zwischen Datenbanken und Tests von Migrationen vereinfachte. Dadurch konnte der Betrieb von CockroachDB und Postgres vergleichend analysiert werden, was half, die Entscheidung für den Wechsel zu treffen und technische Risiken bei Migrationen zu minimieren.
Migrationen waren eine echte Herausforderung: das Update von Schemas und Datenbankstrukturen über Prisma verursachte häufig Timeouts in CockroachDB. Das bedeutete oft zwei Stunden Blockadezeiten und manuelle Eingriffe, die den Deploy-Prozess deutlich verlangsamen und Betriebsteams stark belasten. Im direkten Vergleich zeigte sich, dass Postgres Migrationen auf vergleichbaren Datenmengen in Sekunden absolvierte – eine enorme Zeitersparnis und ein Gewinn an Stabilität. Die Einschränkungen bei Migrationen hatten weitreichende Folgen. Entwickler mussten wegen der Angst vor System-Deadlocks zunehmend ausweichen und Prozesse außerhalb des Datenbanksystems abwickeln, was nicht nur ineffizient, sondern auch fehleranfällig war. Diese operative Belastung führte letztlich sogar dazu, dass ein Versionsupgrade von CockroachDB unterblieb und man auf einer bereits veralteten Version 22 verharren musste.
Da die Support-Unterstützung für diese Version langsam und mangelhaft wurde, schwächte dies die Stabilität und Sicherheit der Umgebung weiter. Die Entscheidung war am Ende klar: Migration zu Postgres als nachhaltigere Lösung. Doch nicht nur Migrationen verursachten Probleme. Auch ETL-Prozesse, die für Datenintegration und -verarbeitung unerlässlich sind, wurden durch Timeouts massiv beeinträchtigt. Insbesondere Lösungen wie Airbyte, das als wichtiger Connector zu CockroachDB diente, wiesen erhebliche Mängel auf: eine unstable Alpha-Version mit speicherbedingten Fehlern führte zu häufigen Ausfällen und unzuverlässiger Performance. Das Fehlen ausgereifter ETL-Tools für CockroachDB erschwerte den Datenfluss und Verzögerungen waren an der Tagesordnung. In puncto Abfragegeschwindigkeit zeigte sich in der Praxis eine geteilte Bilanz.
Für bestimmte, anspruchsvolle Queries zeigte CockroachDB dank eines optimierten Abfrageplaners Vorteile, da Aggregationen intelligent und effizient umgesetzt wurden. Für einige einzelne Fälle konnte CockroachDB so Abfragen in deutlich kürzerer Zeit erledigen als Postgres. Allerdings waren diese Fälle die Ausnahme. In der überwiegenden Zahl der realen Anwendungsfälle schnitt Postgres deutlich besser ab. Grund hierfür war die Komplexität der von Prisma generierten SQL-Statements, die oft umfangreiche Joins und mehrere Spalten einschlossen. CockroachDBs Optimizer geriet hier manchmal an seine Grenzen und verursachte Full Table Scans mit langen Antwortzeiten statt selektive und gezielte Abfragen. Sogar Abfragen, die bei Postgres um das Zwanzigfache schneller liefen, waren keine Seltenheit. Auch die Benutzererfahrung (UI/UX) litt unter der Cockroach-Lösung. Entwickler berichteten von irreführenden Anzeigen zu nicht genutzten Indices, die eigentlich weiterhin in Gebrauch waren.
Die mangelnde Intuition und Verständlichkeit der Indizierungsübersicht erschwerte die Wartung. Zudem war das Abbrechen langlaufender Queries in CockroachDB ein technisches und organisatorisches Problem. Es erforderte Zugang zur Cockroach-Konsole und Koordination über alle Cluster-Knoten hinweg – ein Prozess, der trotz aller Mühe nicht immer erfolgreich war und in einem Fall sogar zum Systemabsturz führte. Im Vergleich bot Postgres mit seiner Integration in gängige Tools wie TablePlus deutlich komfortablere Möglichkeiten zur Steuerung von Abfragen. Die Cockroach-Umgebung war zudem anfällig für Netzwerkausfälle, insbesondere im Zusammenspiel mit Tailscale, einem VPN-Anbieter. Die Probleme traten sporadisch auf, erschwerten CI-Pipelines, den lokalen Entwicklungszugang und ETL-Operationen gleichermaßen und konnten trotz umfangreicher Fehlersuche nicht nachhaltig behoben werden.
In der Postgres-Umgebung trat dieses Problem nicht in Erscheinung, was für größere Zuverlässigkeit und weniger Unterbrechungen sorgte. Der tatsächliche Migrationsprozess war für Motion ein großes Projekt. Die größte Tabelle umfasste Ende 2023 rund 100 Millionen Datensätze. Die nicht vorhanden ausgereifte ETL-Infrastruktur für CockroachDB führte dazu, dass Motion eine individuell zugeschnittene Lösung entwickelte. Inspiriert durch aufkommende Technologien wie das JavaScript-Framework Bun wurde eine Pipeline geschaffen, die den Datenbankinhalt in CSV-Dateien exportierte und diese mittels mehrerer paralleler Prozesse wieder in Postgres importierte. Dieses Verfahren konnte den massiven Datenbestand in etwa 15 Minuten auf eine leistungsfähige Google Cloud VM mit 128 Prozessorkernen übertragen. Ein entscheidender technischer Stolperstein war die unterschiedliche Byte-Kodierung von JSON- und Array-Daten in CockroachDB und Postgres.
Um Konsistenz und Fehlerfreiheit bei der Migration zu garantieren, entwickelte das Team einen speziellen CSV-Parsing-Konverter, der Datenformate kompatibel machte, ohne die Nutzererfahrung zu beeinträchtigen. Dies verdeutlicht die oftmals unterschätzte Komplexität bei großen Datenmigrationen zwischen unterschiedlichen Datenbanksystemen. Nach der Migration zeigte sich sofort eine messbare Verbesserung in der Systemperformance. Die aggregierten Antwortzeiten für Datenbankanfragen sanken um ein Drittel, was die Nutzerzufriedenheit und das Gesamtsystem deutlich verbesserte. Darüber hinaus konnten dank umfangreicher Analyse-Tools aus dem Postgres-Ökosystem mehrere ineffiziente Abfragen innerhalb weniger Stunden optimiert werden. Diese Investition in Performance-Steigerung war nur nach dem Umzug möglich geworden. Gleichzeitig bedeutete der Wechsel auch eine signifikante Kosteneinsparung für Motion.
Durch den Verzicht auf eine hochverteilte Datenbankumgebung und den Einsatz einer bewährten relationalen Lösung wurden die jährlichen Datenbankkosten um über 110. 000 US-Dollar reduziert. Dieses Einsparpotenzial wächst zudem kontinuierlich, da die Nutzerzahlen und Transaktionsvolumina weiter steigen. Die Entscheidung, sich auf Postgres zu konzentrieren, bringt für Motion und ähnliche Unternehmen eine Vielzahl von Vorteilen mit sich. Postgres hat sich als extrem robuste, performante und günstige Lösung etabliert, die dank umfassender Community und Tools rasch weiterentwickelt wird. Die Migration verdeutlicht auch, dass hochkomplexe, skalierbare Systeme nicht immer die beste Wahl für jede Anforderung sind. Stattdessen kann eine genaue Analyse von Workloads und Kosten zu pragmatischeren und nachhaltigen Entscheidungen führen.
Für Entwickler und Technikteams, die vor der Wahl einer Datenbanklösung stehen, bietet die Motion-Erfahrung zahlreiche wichtige Erkenntnisse: Die Tauglichkeit von CockroachDB für verteilte Umgebungen ist unbestritten, aber wenn Multi-Region-Replikation nicht benötigt wird und einfache Transaktionen dominieren, kann Postgres eine deutlich effizientere Alternative darstellen. Die Integration bewährter Migrationstools, ein zuverlässig arbeitendes ETL-Ökosystem sowie die schnellere Behebungen von Engpässen und Abfrageproblemen sind nicht zu unterschätzende Vorteile. Darüber hinaus unterstreicht die Motion-Migration die Bedeutung einer sorgfältigen Planung und schrittweisen Umsetzung. Die akribische Vorbereitung, Testläufe auf rewound Instanzen, die Berücksichtigung verschiedener Datenformate und die Absicherung von Ausfallzeiten führten zu einem reibungslosen Prozess mit minimaler Betriebsunterbrechung.
Ein kompetentes Entwicklerteam, das auch bereit ist, innovative Technologien wie Bun zum Aufbau von ETL-Pipelines zu nutzen, ist heute wichtiger denn je, um technische Herausforderungen zu meistern und Wettbewerbsvorteile auszubauen. Zusammenfassend zeigt die Reise von Motion, dass ein Umstieg auf Postgres nicht nur eine technische Notwendigkeit sondern auch eine wirtschaftlich sinnvolle Entscheidung sein kann. Postgres überzeugt mit zuverlässiger Performance, einfacher Handhabung und signifikanten Kostenvorteilen, die gerade für schnell wachsende Technologieunternehmen ein echter Gewinn sind. Motion veranschaulicht eindrucksvoll, wie mutige Entscheidungen und technisches Know-how Unternehmen in die Lage versetzen, komplexe Dateninfrastrukturen erfolgreich umzugestalten und zukunftssicher zu machen.
