Die Wahl der richtigen Datenbanklösung ist für wachstumsstarke Unternehmen essenziell. Sie entscheidet vielfach über Skalierbarkeit, Performance, Kosten und Betriebssicherheit. Im Spannungsfeld der modernen Anforderungen stand das Scale-up-Unternehmen Motion, das nach zweieinhalb Jahren intensiver Nutzung von CockroachDB entschied, auf PostgreSQL zu migrieren. Die Gründe, der Ablauf sowie die daraus resultierenden Erkenntnisse sind auch für andere Unternehmen spannend, die vor vergleichbaren Herausforderungen stehen. Motion startete im Jahr 2022 mit CockroachDB, einer verteilten SQL-Datenbank, die sich vor allem durch ihre horizontale Skalierbarkeit und hohe Verfügbarkeit auszeichnet. Gerade in Hinblick auf geplante Multi-Region-Konfigurationen, die u. a. durch die Datenschutzgrundverordnung (GDPR) notwendig werden könnten, erschien CockroachDB damals als optimale Lösung.
Die Idee war, von Anfang an eine Datenbank zu nutzen, die auch über Regionen hinweg performant und konsistent arbeitet. Im Laufe des Wachstums und zunehmender Nutzungsintensität stellte sich jedoch heraus, dass die Kostenseite zunehmend belastend wirkte. Bis 2024 hat sich die Datenbankrechnung nahezu verfünffacht und erreichte Summen mittlerer sechsstelliger Beträge. Da Multi-Region-Setups bis dahin nicht umgesetzt waren und die Anfragen hauptsächlich einfache transaktionale Queries in einer einzigen Region betrafen, entstand die Frage nach der tatsächlichen Notwendigkeit einer verteilten Datenbank. Ein entscheidender Vorteil ergab sich aus der Nutzung eines Object-Relational Mapper (ORM), genauer Prisma, der ein Head-to-Head-Testen unterschiedlicher Datenbanken relativ einfach machte. So ließen sich Migrationen und Query-Leistungsvergleiche zügig durchführen. Dabei traten zunehmend Probleme bei der Migration im CockroachDB-Cluster auf.
Bei wachsendem Datenvolumen kam es zu Timeout-Problemen während Schema-Änderungen, was dazu führte, dass man Migrationen manuell und einzeln durchführen musste. Die Folge waren Blockierungen von Deployments und eine erhebliche Verzögerung des Entwicklungsflusses. Im Gegensatz dazu erwies sich PostgreSQL in vergleichbaren Tests als deutlich schneller und robuster bei Schema-Migrationen. Selbst auf einer Datenbasis mit vergleichbarer Größe konnte PostgreSQL Migrationen in Sekunden statt in Stunden durchführen. Diese Zeitersparnis war nicht nur eine Frage der Bequemlichkeit, sondern entlastete auch die Entwicklerinnen und Entwickler erheblich, die zuvor aus Angst vor vollständigen Sperrungen bei Migrationen immer öfter versuchten, Änderungen außerhalb der Datenbank umzusetzen. Ein weiteres Problemfeld trat im Bereich Extract-Transform-Load (ETL) auf.
Die Integrationsprozesse, die Daten aus CockroachDB extrahieren und in externe Systeme einspeisen sollten, waren von Instabilitäten und Performanceeinbrüchen geprägt. Eine Airbyte-Connector-Lösung war zum Testzeitpunkt noch in der Alpha-Phase und litt unter Speicherlecks, die zu ständigen Ausfällen führten. Die mangelnde Verfügbarkeit ausgereifter ETL-Tools für CockroachDB erwies sich als hinderlich. Im direkten Vergleich der Abfragegeschwindigkeit zeigte sich ein differenziertes Bild. Einige Anfragen konnten dank des CockroachDB-optimierten Queryplanners schneller ausgeführt werden. Dies betraf vor allem einfache Aggregationen, bei denen der Planner interne Optimierungen vornahm. Allerdings generierte Prisma häufig sehr komplexe SQL-Strukturen mit zahlreichen Joins und Verschachtelungen, die den CockroachDB-Optimierer überforderten. Dadurch kam es zu Full-Table-Scans, die die Ausführung drastisch verlangsamten.
Das wiederum lud PostgreSQL ein, durch effizientere Ausführungspläne zu beeindrucken. Reale Anwendungsqueries, etwa auf Task-Tabellen mit mehreren Millionen Datensätzen, konnten dort bis zu zwanzigmal schneller abgearbeitet werden. Die komplexe SQL-Generierung durch Prisma schien also im Zusammenspiel mit PostgreSQL deutlich weniger problematisch als mit CockroachDB. Neben den technischen Aspekten kamen zudem Einflüsse auf die Nutzererfahrung hinzu. Zum Beispiel zeigte die CockroachDB-Benutzeroberfläche ungenaue Empfehlungen zu vorhandenen und ungenutzten Indizes an, was zu Verwirrung bei Entwicklerteams führte. Das Abbrechen laufender langwieriger Abfragen gestaltete sich durch die verteilte Architektur der Datenbank deutlich schwieriger und fehleranfälliger als bei einer relationalen Standard-Datenbank wie PostgreSQL. Auch der Support hinterließ Wünsche offen.
Das Supportportal lag auf einer separaten Website ohne gemeinsamen Login, und typischerweise lagen Antwortzeiten bei mehreren Tagen. Besonders kritische Fehler, etwa, wenn diese zu Ausfällen führten, konnten so nicht schnell genug adressiert werden. Zudem gab es immer wieder Verbindungsprobleme in der CockroachDB-Umgebung, die sich durch interne Netzwerklösungen wie Tailscale äußerten, und die durch PostgreSQL bislang nicht bekannt waren. Die Migration selbst stellte eine logistische und technische Herausforderung dar. Das größte Datenvolumen bei Motion lag bei 100 Millionen Zeilen in einer Tabelle. Wegen mangelhafter Tools beschloss der Autor, ein eigenes ETL-Skript zu schreiben, um die Daten sukzessive von CockroachDB nach PostgreSQL zu übertragen. Das Skript wurde in der damals aufkommenden Programmiersprache Bun umgesetzt und nutzte CSV-Streams und Kindprozesse für parallele Datenübertragung.
Ein unerwartetes Problembestand darin, dass CockroachDB und PostgreSQL JSON- und Array-Datentypen unterschiedlich codierten. Daher war es notwendig, eine Zwischenschicht zum Parsing und Transformieren der Daten zu implementieren, um Kompatibilität und Datenintegrität sicherzustellen. Am Tag der Migration konnte dann die gesamte Datenbank in einem Zeitraum von etwa 15 Minuten auf einem leistungsstarken VM-Cluster bei Google Cloud Platform migriert werden. Um Produktionsausfälle zu minimieren, schaltete Motion vorübergehend in den Wartungsmodus und steigerte den Datenverkehr nach der Migration kontrolliert wieder hoch. Insgesamt belief sich die Down-Time auf unter eine Stunde, ohne Datenverlust. Nach der Migration bestätigte sich der Vorteil von PostgreSQL in Form messbarer Verbesserungen. Die aggregierte Latenz bei Anfragen sank um ein Drittel, und dank umfangreicher Werkzeuge aus dem PostgreSQL-Ökosystem konnten ineffiziente Abfragen schnell identifiziert und optimiert werden.
Auch betriebswirtschaftlich zeigte sich der Wechsel als sinnvoll: Die jährlichen Datenbankkosten verringerte Motion um über 110. 000 US-Dollar. Bei weiterem Wachstum wären die Einsparungen noch höher. Der Erfahrungsbericht von Motion zeigt eindrücklich, dass etablierte relationale Datenbanksysteme wie PostgreSQL auch in modernen, dynamischen Entwicklungsumgebungen konkurrenzfähig bleiben. Verteilte Datenbanksysteme wie CockroachDB überzeugen zwar mit besonderen Features für horizontale Skalierung und Multi-Region-Betrieb, können in bestimmten Anwendungskontexten jedoch auch erhebliche Nachteile durch Komplexität, Performanceeinbußen aufgrund von SQL-Generierung oder Schwierigkeiten bei Migrationen mit sich bringen. Für Entwickler und IT-Verantwortliche bedeutet das, sorgfältig abzuwägen, welche Anforderungen die Datenbank abdecken muss, und entsprechende Tests frühzeitig durchzuführen.
Die Nutzung von ORMs kann dabei helfen, unterschiedliche Systeme vergleichbar zu machen und Migrationen kontrolliert zu simulieren. Bei hohen Datenvolumina sollten zudem ETL-Prozesse und deren Abhängigkeiten genau betrachtet werden, da mangelnde Stabilität hier schnell zum Bottleneck wird. Nicht zuletzt spielt auch der Support und die Bedienbarkeit der Datenbanksysteme eine maßgebliche Rolle. Transparente, einfache Schnittstellen und kurze Reaktionszeiten bei Fehlern erhöhen signifikant die Zuverlässigkeit und Zufriedenheit der Entwicklerteams. Motion eröffnete mit dem Wechsel zu PostgreSQL einen neuen Abschnitt in ihrer technischen Roadmap. Die Migration war nicht nur eine wirtschaftliche Entscheidung, sondern auch ein Schritt zu besserer Performance, höherer Stabilität und deutlicher Entwicklungserleichterung.
Für andere Unternehmen, die vor ähnlichen Herausforderungen stehen, bietet der Erfahrungsbericht wertvolle Einblicke zur Planung, Durchführung und Nachbereitung von Datenbankmigrationen sowie zur Bedeutung der Wahl der richtigen technologischen Basis. Wer sich für die technische Seite von Datenbanken, deren Skalierung und Migration interessiert, findet in diesem Beispiel einen motivierenden und praxisnahen Leitfaden, der Mut macht, komplexe Herausforderungen mutig anzugehen und gleichzeitig auf bewährte Lösungen und eine starke Community zu setzen.
