Die Wahl der richtigen Datenbank ist eine der wichtigsten Entscheidungen für Unternehmen, die skalierbare und zuverlässige Anwendungen betreiben möchten. Für viele Startups und mittelständische Unternehmen ist die Verlockung moderner, verteilter Datenbanksysteme groß, insbesondere wenn Funktionen wie horizontale Skalierbarkeit und Multi-Region-Unterstützung gefragt sind. Motion, ein Unternehmen, das sich auf KI-gestützte Workflow-Lösungen spezialisiert hat, entschied sich bereits Anfang 2022 für CockroachDB. Diese Datenbank beeindruckte mit einer SQL-kompatiblen Schnittstelle, automatischem Multi-Region-Setup und sehr hoher Verfügbarkeit – alles Merkmale, die insbesondere für Anwendungen mit globaler Reichweite und strengen Datenschutzanforderungen von Bedeutung sein können. Doch mit dem Wachstum von Motion stiegen nicht nur die Kunden- und Datenmengen, sondern in gleichem Maße auch die technischen und finanziellen Herausforderungen.
CockroachDB erwies sich in vielen Bereichen zwar als leistungsfähig, dennoch zeigten sich im Laufe der Zeit deutliche Limitierungen und Kostensteigerungen, die eine kritische Neubewertung der Datenbankstrategie notwendig machten. Die Ausgangslage war so spannend wie herausfordernd: Obwohl die Multi-Region-Features von CockroachDB überzeugten, benötigte Motion noch keine Datenlokalisierung, sonst wäre dies ein zwingendes Argument für ein verteiltes System gewesen. Die meisten Abfragen waren noch einfach und es wurde regional betrieben. Trotzdem multiplizierten sich die Betriebs- und Lizenzkosten auf ein mittleres sechsstelliges Niveau jährlich, ein Faktor, der das Kosten-Nutzen-Verhältnis zunehmend infrage stellte.
Zudem konnten Migrationen innerhalb von CockroachDB nach mehreren Jahren erheblich verzögern, zum Beispiel ertappten sich die Entwickler häufig dabei, auf manuelle Eingriffe angewiesen zu sein, weil automatisierte Aktualisierungen mit Tools wie Prisma bei größer werdenden Tabellen aufgrund von Timeout-Problemen immer wieder blockierten. Diese verzögerten und ausfallgefährdeten Datenbank-Migrationen führten zu einem Betriebsrisiko, das sich nicht einfach ignorieren ließ. Tatsächlich blockierten die Probleme mit den Migrationsprozessen interne Updates am Cockroach-Cluster selbst - das Ganze bedeutete ein echtes Sicherheitsrisiko, weil das System auf einer veralteten Version verharrte. Zeitgleich beeinträchtigten diese Herausforderungen auch externe Workflows. So zeigte sich beispielsweise die ETL-Prozesspipeline, insbesondere bei Nutzung von Airbyte, anfällig für Instabilitäten, was sich in häufigen Job-Ausfällen und Leistungseinbrüchen äußerte.
Interessanterweise zeigten Vergleichsmessungen der Systemperformance ein differenziertes Bild: Bestimmte komplexe Abfragen liefen auf CockroachDB dank ihres Optimizers schneller, während einfachere, durch das ORM generierte SQL-Statements oftmals von PostgreSQL deutlich besser bearbeitet wurden – teils mit bis zu zwanzigfach schnellerer Ausführung. Die Ursache lag häufig in überkomplizierten Abfragen, die das ORM erzeugte, was auf dem Cockroach-Optimierer oft in ineffizienten Full-Table-Scans resultierte. Bei PostgreSQL erwiesen sich ähnliche Queries als wesentlich performanter, was sich messbar in der Nutzererfahrung und Systemantwortzeit widerspiegelte. Aus UX-Sicht beliefen sich die Probleme nicht nur auf Performance und Stabilität: Auch das Management der Datenbankindices stellte sich als unbefriedigend dar.
Die CockroachDB-Benutzeroberfläche verwirrte Entwickler durch ungenaue oder irreführende Empfehlungen, beispielsweise indem noch bis dato verwendete Indizes fälschlicherweise als ungenutzt angezeigt wurden. Zudem erschwerte die verteilte Architektur das Abbrechen langlaufender, ressourcenintensiver Abfragen erheblich – ein Vorgang, der bei PostgreSQL bequem über SQL-Clients mit einem Klick erledigt werden kann. Der Cockroach-Cluster erforderte dagegen oftmals manuelles Eingreifen in der Administrationskonsole, was nicht selten mit unerwarteten Ausfällen einherging. Die Problematik wurde durch Support-Hürden noch verschärft: Der Zugang zum Cockroach-Support erfolgte über eine separate, nicht integrierte Plattform, die mehrfach erforderliche Eingaben verlangte und oft nur verzögert reagierte. Gerade bei kritischen Fehlern oder Produktionsausfällen war dieses ineffiziente Supportmodell besonders hinderlich.
Netzwerkseitig traten während der Cockroach-Nutzung wiederholt Connectivity-Ausfälle auf, die sich über alle Umgebungen zogen, darunter CI-Systeme, lokale SQL-Clients und ETL-Konnektoren. Trotz eingehender Untersuchungen blieben diese Probleme unlösbar und führten zu immer wiederkehrenden Betriebsunterbrechungen, mit denen PostgreSQL in der Folgephase keine Probleme mehr hatte. Angesichts dieser Summe an Herausforderungen entschied sich Motion Anfang 2024 für die Migration zu PostgreSQL – einer bewährten, leistungsfähigen und kosteneffizienten relationalen Datenbank mit einem großen Ökosystem an bewährten Tools und Unterstützungsmöglichkeiten. Die Migration bedeutete bei über 100 Millionen Datensätzen eine gewaltige technische Aufgabe, die mit einer cleveren, selbstgebauten ETL-Pipeline bewältigt wurde. Dabei kam das neue JavaScript-Framework Bun zum Einsatz, das parallelisierte Datenströme pro Tabelle ermöglichte.
Das Verfahren basierte auf einem Dump der Cockroach-Daten im CSV-Format, der in einem Streaming-Prozess sauber in PostgreSQL geladen wurde. Während der Tests tauchten jedoch unerwartete Hürden auf: Die unterschiedlichen Byte-Encoding-Verfahren für JSON- und Array-Felder zwischen Cockroach und PostgreSQL führten zu Kompatibilitätsproblemen. Diese mussten durch aufwändige, eigens entwickelte Transformationslogiken gelöst werden, um Datenverluste oder inkonsistente Darstellungen zu vermeiden. Die nächtliche produktive Migration verlief schließlich mit rund 15 Minuten Laufzeit sehr erfolgreich. Die komplette Datenbank stand für etwa eine Stunde nicht zur Verfügung, was bewusst konservativ geplant war, um Risiken zu minimieren. Das Ergebnis war enttäuschend gut: Neben dem Wegfall der zuvor im Cockroach-Betrieb entstandenen Kosten explodierten Performance-Daten förmlich. Die aggregierten Antwortzeiten der Anfragen verbesserten sich um ein Drittel unmittelbar nach der Umstellung.
Die zusätzlichen Vorteile des subtileren Query-Optimierers von PostgreSQL und die vielfältigen Analysewerkzeuge eröffneten neue Möglichkeiten zur Performancesteigerung, sodass mehrere komplexe Queries innerhalb kürzester Zeit merklich optimiert werden konnten. Gleichzeitig reduzierte sich die Komplexität des Betriebs dem Aspekt Einfachheit und Zuverlässigkeit zuliebe erheblich. Aus wirtschaftlicher Sicht sparte die Migration Motion mehrere hunderttausend Euro pro Jahr ein, Optionen zur weiteren Kostenreduktion bestehen durch die Möglichkeit, geschickt Ressourcen entsprechend des tatsächlichen Bedarfs noch feiner zu skalieren. Das Team hinter Motion profitiert nun von einer robusteren Datenplattform, besserem Entwicklererlebnis und deutlich weniger operationalen Risiken. Die Erfahrungen von Motion stehen exemplarisch für viele Unternehmen, die vor der Wahl stehen, hochmoderne verteilte Datenbanken gegen klassische relationale Systeme abzuwägen.
Die Vorteile verteilter Systeme sind insbesondere bei globalem Betrieb und hohen Verfügbarkeitsanforderungen unbestritten, doch sind die damit verbundenen Komplexitäten und Kosten keineswegs zu unterschätzen. Das PostgreSQL-Ökosystem bietet dagegen eine reiche Fülle ausgereifter Werkzeuge, eine breite Community und einen bewährten Betrieb im Enterprise-Umfeld. Zusammenfassend lässt sich sagen, dass Migrationen nicht nur technische Herausforderungen mit sich bringen, sondern auch strategische Entscheidungen reflektieren. Der Fall Motion illustriert, wie ein Unternehmen durch das pragmatische Abwägen von Kosten, Performance und operativer Komplexität letztlich eine nachhaltige Lösung fand, die auch für andere Unternehmen und Branchenmodell-Anwendungen als Best Practice gelten kann.
Wer mit seiner Datenbank optimal skalieren und gleichzeitig Kosten und Komplexität im Griff behalten möchte, sollte konkret prüfen, ob moderne relationale Systeme wie PostgreSQL nicht die einfachere und effektivere Wahl sein könnten.
