In Zeiten stetig wachsender Datenmengen ist die Wahl der richtigen Datenbanktechnologie entscheidend für den Erfolg eines Unternehmens. Viele Start-ups und etablierte Firmen greifen zunächst auf verteilte Datenbanksysteme wie CockroachDB zurück, um von deren Skalierbarkeit und Hochverfügbarkeit zu profitieren. Doch mit wachsendem Unternehmen und zunehmenden Datenvolumen geraten diese Systeme oft an ihre Grenzen – sowohl in puncto Kosten als auch Performance. Ein praktisches Beispiel ist das Unternehmen Motion, das sich nach Jahren intensiver Nutzung von CockroachDB dazu entschloss, seine gesamte Datenbanklandschaft auf Postgres umzustellen. Dieser Wechsel bietet wertvolle Erkenntnisse für alle, die einen ähnlichen Schritt in Erwägung ziehen.
Bereits zu Beginn der Nutzung von CockroachDB lagen die Vorteile klar auf der Hand: eine einfache horizontale Skalierung, insbesondere bei Multi-Region-Setups, gepaart mit hoher Verfügbarkeit und einer SQL-kompatiblen Schnittstelle. Gerade angesichts strenger Datenschutzbestimmungen wie der DSGVO schien ein verteiltes System, das Daten lokalisiert speichern kann, attraktiv. Doch in der Praxis zeigten sich bald Einschränkungen. Trotz der theoretischen Vorteile wurde der Betrieb schnell kostspielig. Im Fall von Motion stiegen die Kosten bis 2024 auf eine fünfstellige Summe pro Monat an, obwohl sie sich zu diesem Zeitpunkt noch in einer einzigen Region befanden und überwiegend einfache Transaktionsabfragen ausführten.
Die Herausforderung lag nicht nur in den Kosten. Das Unternehmen stellte fest, dass bei der Durchführung von Datenbankmigrationen regelmäßig Zeitüberschreitungen (Timeouts) auftraten. Diese führten dazu, dass Deployments blockiert wurden und Entwickler gezwungen waren, Migrationen manuell und oft parallel im CockroachDB-Cluster durchzuführen. Solche Verzögerungen kosteten wertvolle Zeit und führten zu Dokumentations- und Prozessbrüchen. Noch problematischer war, dass auch Upgrades auf neuere Versionen der Datenbank immer schwieriger wurden, da veraltete Versionen lange verwendet werden mussten, was die Reaktionszeiten des Supports negativ beeinflusste.
Neben diesen operativen Schwierigkeiten beeinträchtigte die Wahl des Datenbanksystems auch die Verarbeitung von ETL-Prozessen (Extract, Transform, Load). Die Konnektivität zu ETL-Tools wie Airbyte war limitiert, und bestehende Schnittstellen befanden sich lange in einer Alpha-Phase mit bekannten Fehlern wie Speicherlecks, die zu Ausfällen führten. Selbst wenn ETL-Jobs erfolgreich durchliefen, war ihre Performance häufig unzureichend, was den Gesamtbetrieb zusätzlich belastete.Spannend sind auch die Unterschiede bei der Performance von SQL-Abfragen, die Motion zwischen CockroachDB und Postgres analysierte. Zwar gab es Szenarien, in denen CockroachDB dank seines optimierten Query Planners Vorteile zeigte, etwa bei bestimmten Aggregationen.
Doch häufig dominierte Postgres die Performance, besonders bei komplexen Abfragen, die durch ORM-Tools wie Prisma generiert wurden. Bei vielen realen Anwendungsszenarien führte die teilweise unnötige Volltabellen-Scans bei CockroachDB zu drastisch erhöhten Antwortzeiten. Die Folge waren Belastungen für die Nutzererfahrung und eine Beeinträchtigung der Skalierbarkeit.Auch im Bereich Usability zeigte sich Postgres von seiner stärkeren Seite. Bei CockroachDB waren Entwickler beispielsweise mit der Schwierigkeit konfrontiert, laufende Abfragen abzubrechen, da dies aufgrund der verteilten Architektur aufwendig war.
Mit Postgres konnte man hingegen bequem über bekannte SQL-Clients wie TablePlus einzelne Abfragen stoppen, ohne das gesamte System zu gefährden. Darüber hinaus gestaltete sich die Verwaltung von Indexen und Support-Anfragen bei CockroachDB oft umständlich und für Entwickler frustrierend.Ein entscheidendes Hindernis in der verteilten CockroachDB-Umgebung stellten zudem immer wiederkehrende Verbindungsprobleme in der Netzwerk-Infrastruktur dar. Motion berichtet von unvorhersehbaren Ausfällen der Tailscale-Anbindung, die sowohl Entwicklungsumgebungen als auch Produktionssysteme betrafen. Diese instabilen Verbindungen traten regelmäßig auf, ohne dass eine nachhaltige Lösung gefunden werden konnte.
Mit Postgres kam es zu solchen Fällen nicht mehr.Die technische Migration an sich war eine Herausforderung, die von Motion durch eine eigens entwickelte ETL-Lösung gemeistert wurde. Statt auf unzuverlässige, bestehende Tools zu setzen, wurde ein mehrstufiger Prozess mit Hilfe moderner Tools wie Bun implementiert. Dabei wurden zunächst Daten und Schema aus CockroachDB extrahiert, in CSV-Dateien aufbereitet, um dann in einem Streaming-Verfahren in die neue Postgres-Datenbank importiert zu werden. Trotz anfänglicher Schwierigkeiten aufgrund unterschiedlicher Bytekodierungen bei JSON- und Array-Spalten gelang es, die Daten komplett und fehlerfrei zu migrieren.
Die gesamte Migration wurde in einem Zeitfenster von unter einer Stunde durchgeführt, wobei der produktive Betrieb nur minimal beeinträchtigt wurde.Der Aufwand für die Migration zahlte sich schnell aus. Im Anschluss zeigte sich nicht nur eine signifikante Verbesserung der Antwortzeiten und eine Reduktion der Fehlerraten bei der Datenverarbeitung, sondern auch eine unmittelbare Kostenersparnis von über 100.000 US-Dollar jährlich bei Motion. Diese Einsparungen entstehen durch niedrigere Betriebskosten, effizientere Nutzung der Infrastruktur und die höhere Effizienz der Datenbankabfragen.
Gleichzeitig ergaben sich Verbesserungen im Kundenfeedback und bei der Zufriedenheit der Entwicklerteams.Zusammenfassend macht das Beispiel von Motion deutlich, dass die Migration zu Postgres selbst für ursprünglich verteilte Anwendungen sinnvoll sein kann, sofern bestimmte Anforderungen wie Multi-Region-Betrieb noch nicht zwingend notwendig sind. Postgres bietet eine stabilere und effizientere Plattform für viele Anwendungsszenarien, die mit klassischen relationalen Datenbanken gut abgedeckt werden können. Die hervorragende Performance, umfangreiche Tools zur Analyse und Optimierung sowie eine große Community machen Postgres zu einer idealen Lösung für das Wachstum von Unternehmen.Unternehmen, die einen Wechsel in Betracht ziehen, sollten sich auf technische Herausforderungen bei der Migration einstellen, insbesondere bei der Datenkonvertierung und ETL-Prozessen.