Die Wahl der richtigen Datenbanklösung ist für viele Unternehmen ein entscheidender Faktor im Wachstum und Betrieb ihrer Infrastruktur. Motion, ein innovatives Unternehmen im Bereich KI-gesteuerter Workflow-Lösungen, hat Anfang 2022 auf CockroachDB gesetzt, um von den Vorteilen einer hochverfügbaren und horizontal skalierbaren Datenbank mit SQL-Kompatibilität zu profitieren. Doch im Laufe der Entwicklung und unter steigenden Nutzungsanforderungen zeigte sich, dass eine verteilte Datenbank nicht immer die optimale Wahl für jede Anwendung ist – das Team entschied sich 2024 für den Wechsel zu PostgreSQL. Dieser komplexe Prozess offenbart wertvolle Erkenntnisse zu Migration, Performance und Kostenoptimierung. CockroachDB galt für Motion zu Beginn als vielversprechende Lösung, vor allem wegen der einfachen Skalierung über mehrere Regionen und den strengen Datenschutzanforderungen wie der GDPR. Die Vorstellung, Daten über verschiedene Kontinente zu replizieren, war ein starker Beweggrund.
Allerdings war die Realität bei Motion anders: Bis 2024 befand sich der Betrieb noch in einer einzigen Region und die Abfragen im Wesentlichen transaktional und relativ einfach. Die hohen Kosten der verteilten Infrastruktur – die mittlerweile auf ein fünfstelliges Vielfaches im mittleren sechsstelligen Bereich angewachsen waren – passten nicht mehr zum tatsächlichen Bedarf. Der erste Schmerzpunkt zeigte sich bei Datenbankmigrationen. Mit dem populären ORM Prisma führte Motion viele Änderungen an der Datenstruktur durch. Doch die Migrationen auf CockroachDB dauerten oft zu lange und endeten in Timeouts. Wenn Migrationen blockierten, hieß das, manuelle Eingriffe in die Datenbank von Hand vorzunehmen – was für eine Unterbrechung des Deployments von bis zu zwei Stunden sorgen konnte und die Entwickler frustrierte.
Die Angst vor lang laufenden Lockings veranlasste das Team, operative Kompromisse einzugehen und teilweise auf Datenbankoperationen zu verzichten oder sie außerhalb der Datenbank zu erledigen. Einer der entscheidenden Tests zeigte, wie schnell PostgreSQL migrationsbezogene Änderungen auf einer vergleichbaren Datenbasis durchführen konnte: Die gleiche Änderung, das Hinzufügen einer neuen Spalte, dauerte unter PostgreSQL lediglich zehn Sekunden. Dieser Geschwindigkeitsvorteil allein rechtfertigte bereits eine ernsthafte Überlegung, ob der hohe Preis und die Komplexität von CockroachDB noch tragbar seien. Probleme beschränkten sich nicht nur auf die Migrationen. Auch ETL-Prozesse waren von Timeouts betroffen. Airbyte, das einzige einigermaßen verfügbare Tool für CockroachDB-Integration, war in der Praxis fehlerhaft – es litt unter einer Speicherleckage, die zu unsteten und langsamen Ladezeiten führte.
Gleichzeitig war das Ökosystem für Cockroach recht eingeschränkt, was den Aufbau stabiler und effizienter Datenpipelines erschwerte. Interessant sind die detaillierten Vergleiche der Abfragegeschwindigkeiten. Einige komplexe Abfragen liefen aufgrund des optimierten Query Planners von CockroachDB schneller als unter PostgreSQL. Doch diese Vorteile zeigten sich nur bei bestimmten Abfragearten. Im praktischen Alltag mit Prisma-generiertem SQL, das oft sehr komplexe und verschachtelte Abfragen mit mehreren Joins und Subabfragen erzeugt, zeigte CockroachDB eine oft deutlich schlechtere Performance. So waren manche Anfragen zeitweise zwanzig Mal langsamer als unter PostgreSQL. Dies lag auch daran, dass Cockroach bei manchen Abfragen zu wahlweise unvorteilhaften Volltabellenscans tendierte, während PostgreSQL effizientere Ausführungspläne wählte. Die hohe Komplexität des automatisch generierten SQLs führte zu Performanceproblemen, die erst durch den Umstieg gelindert wurden.
Neben technischen Aspekten wirkten sich die Eigenheiten der CockroachDB-UI und der Support in der täglichen Arbeit negativ aus. Die Anzeige von ungenutzten Indizes war häufig irreführend und führte teils zu falschen Entscheidungen seitens der Entwickler. Das Abbrechen langer Queries in Cockroach war cumbersome und riskant, da der Prozess nicht zentral gesteuert werden konnte, sondern manuell in der Konsole an jedem Knoten erfolgen musste, was gelegentlich zu Instabilitäten führte. Die Support-Erfahrung erwies sich als unpraktisch: Ein separates Portal ohne gemeinsame Authentifizierung verlangte wiederholte Angaben und wartete lange auf Antworten. Solche Herausforderungen erhöhen den Aufwand für den Support erheblich. Zusätzlich gab es wiederkehrende VPC-Konnektivitätsprobleme mit CockroachDB über Tailscale, die sporadisch auftraten und das Entwicklerteam vor Rätsel stellten.
Diese Verbindungsabbrüche betrafen verschiedene Umgebungen, von CI bis zu lokalen Datenbankclients, und wurden nie vollständig gelöst. Erstaunlicherweise trat ein derartiges Problem mit PostgreSQL nie auf. Aus Sicht der Migration stellte sich die Situation folgendermaßen dar: Motion verfügte im Jahr 2024 über eine riesige Datenbank mit rund 100 Millionen Datensätzen in der größten Tabelle. Da keine ausgereiften Tools für die Migration von CockroachDB zu PostgreSQL existierten und der einzige ETL-Connector für CockroachDB fehlerhaft war, wurde entschieden, ein eigenes ETL-Verfahren zu entwickeln. Der Entwickler nutzte Bun, eine moderne JavaScript-Laufzeitumgebung, um eine maßgeschneiderte Lösung zu schreiben. Der Ablauf bestand darin, zunächst die Datenbankschemata auszulesen, die Daten jeder Tabelle in separate Dateien zu exportieren und dann parallel für jede Tabelle einen Bun-Prozess zu starten, der Daten zeilenweise per CSV-Streaming in PostgreSQL einspeiste.
Eine nicht erwartete Herausforderung war die unterschiedliche interne Kodierung von JSON- und Array-Datentypen zwischen CockroachDB und PostgreSQL, die zunächst zu Dateninkonsistenzen führte. Das Entwicklerteam erstellte daraufhin eine eigene Parsing-Pipeline, die die Daten während des Export-Imports anpasste, ohne den Anwendern eine Änderung spürbar zu machen. Der eigentliche migrationstechnische Aufwand wurde insbesondere durch die sorgfältige Ablaufplanung möglich. Für den Produktivumstieg wurde eine leistungsstarke virtuelle Maschine mit 128 CPU-Kernen bei Google Cloud Platform eingesetzt. Der Wechsel selbst verlief während einer nächtlichen Wartungsphase und dauerte etwa 15 Minuten. Beim Hochfahren der Anwendung wurde die Belastung nach und nach wieder zurückgeführt, insgesamt fiel die Downtime auf etwa eine Stunde. Erfreulicherweise kam es zu keinerlei Datenverlusten.
Nach dem Wechsel zu PostgreSQL konnten sofort Verbesserungen bei der Gesamtperformance gemessen werden: Die aggregierten Latenzen bei Anfragen sanken um rund ein Drittel. Darüber hinaus erlaubte das breite Ökosystem von PostgreSQL den Einsatz von Tools wie PGAnalyze, mit denen das Team rasch mehrere ineffiziente Abfragen identifizierte und optimierte. Dies führte zu einer nachhaltigen Steigerung der Datenbankeffizienz. Auch die Betriebskosten konnten deutlich eingespart werden. Trotz einer vergleichsweise konservativen Überdimensionierung der neuen PostgreSQL-Cluster betrug die Einsparung vor allem in Bezug auf Rechnungshöhe und Wartungsaufwand über 110. 000 US-Dollar im Jahr. Noch wichtiger: Die Infrastruktur ist nun zukunftssicherer und lässt sich flexibel an steigende Anforderungen anpassen.
Im Rückblick zeigt der Erfahrungsbericht von Motion exemplarisch die Herausforderungen und Chancen einer großen Migration von einem verteilten, hochskalierbaren Datenbanksystem hin zu einem klassischen relationalen Datenbankmanagementsystem. Er unterstreicht, dass die beste Wahl nicht immer die vermeintlich modernste oder technisch ausgefeilteste Lösung ist, sondern dass Skalierbarkeit, Performance, Wartbarkeit und Kosten immer im Gesamtzusammenhang zu bewerten sind. Firmen, die ähnliche Datenbankentscheidungen treffen müssen, profitieren von diesen Einsichten und sollten kritisch prüfen, ob Cloud-native, verteilte Datenbanklösungen wirklich den erhofften Mehrwert gegenüber bewährten Systemen wie PostgreSQL erbringen. Die Migration zeigt, dass mit sorgfältiger Planung, geeigneten Tools und der richtigen Expertise der Übergang selbst bei großen Datenmengen reibungslos gelingen kann – mit anschließendem Vorteil für Anwender und Wirtschaftlichkeit.
Schließlich bleibt festzuhalten, dass immer die individuellen Anforderungen, die Abfrageprofile und das zu erwartende Wachstum bei der Wahl der Datenbanktechnologie maßgeblich sind. Die Geschichte von Motion liefert wertvolle Hinweise, wie man sowohl technische als auch unternehmerische Ziele in Einklang bringen kann und wie ein Wechsel zu PostgreSQL trotz anfänglicher Aufwände durchaus ein großer Gewinn sein kann. Unternehmen mit technischen Herausforderungen und dem Bedarf an Kosteneffizienz oder höherer Performance im Bereich relationaler Datenbanken können von solchen Migrationsprojekten viel lernen und vielversprechende Wege für ihre eigene IT-Infrastruktur ableiten.
