- Infisical ist rasant zu einer Plattform gewachsen, die täglich mehr als 50 Millionen Secrets verarbeitet
- Mit der steigenden Nutzung musste der Stack kontinuierlich modernisiert werden; zuletzt wurde eine vollständige Datenbankmigration von MongoDB zu PostgreSQL durchgeführt
- Diese Migration umfasste einen komplexen Prozess aus der Einführung neuer Technologien, dem Aufbau eines Datenbankschemas, der Umstrukturierung von Logik, dem Umschreiben von Abfragen sowie der Übertragung von Millionen (oder sogar Milliarden) von Datensätzen nach PostgreSQL
Erste Schritte
- Beim ursprünglichen Aufbau von Infisical entschied sich das Team für den Stack, mit dem es am vertrautesten war: MongoDB + Mongoose ORM
- Anfangs lag der Fokus stärker auf Infisical Cloud, also einem Managed-SaaS-Angebot; dass viele Nutzer das Produkt selbst hosten würden, wurde kaum erwartet
Warum nicht MongoDB?
- MongoDB funktionierte anfangs gut, doch als die Produkt-Use-Cases über den Managed Service hinausgingen, wurden die Nachteile deutlich
- Viele Organisationen zogen es vor, Infisical selbst zu hosten statt Infisical Cloud zu nutzen, und einige mussten On-Premises-Anforderungen erfüllen
- Wegen der Einschränkungen und Usability-Probleme von MongoDB fiel die Entscheidung für einen Wechsel zu PostgreSQL
Warum PostgreSQL?
- Bei der Suche nach einer neuen Datenbank wurden einfache Verwaltung, Transaktionsunterstützung und relationale Funktionen als wichtige Kriterien betrachtet
- Es wurde zwischen einer internen Speicherlösung und externen Storage-Lösungen abgewogen, letztlich fiel die Wahl jedoch auf PostgreSQL
- PostgreSQL bietet eine aktive Community, umfangreiche Dokumentation sowie vielfältige Lösungen und Erweiterungen; außerdem stellen die meisten Cloud-Anbieter einen Managed Service bereit
Zum ORM
- Nach der Entscheidung für PostgreSQL musste festgelegt werden, wie die Anwendung mit der Datenbank interagieren sollte
- Gesucht wurde ein Tool, das eine ähnliche Erfahrung wie Mongoose ORM bietet; entschieden wurde sich für den Query Builder Knex.js
- Knex.js bietet Seeding- und Migrations-Tools und erreichte durch eine angepasste Zod-Integration für TypeScript-Unterstützung ein zufriedenstellendes Niveau
Migrationsplanung
- Als die Neuschreibung des Codes sich dem Ende näherte, stellte sich die Frage, wie sich die MongoDB-Daten mit minimaler Unterbrechung nach PostgreSQL abbilden lassen
- Für Infisical, das eine Rolle in kritischer Infrastruktur spielt, kam Downtime absolut nicht infrage; als Kompromiss wurden während der Migration Schreibvorgänge untersagt
Die große Umstellung
- Zur Vorbereitung der Migration wurden eine detaillierte Checkliste und ein erwarteter Zeitplan erstellt
- Die Migration wurde über 6 Stunden hinweg im Read-only-Betrieb durchgeführt; nach dem Datentransfer wurde DNS auf die neue Instanz umgeschaltet
Ergebnis
- Die Migration verlief reibungslos und ohne Datenverlust; einige Funktionsfehler mit minimalen Auswirkungen auf Kunden wurden innerhalb von 36 Stunden behoben
- Durch Query-Optimierung via Joins verzeichnete die Plattform Leistungsverbesserungen, zudem sanken die Datenbankkosten um 50 %
- Mit der Einführung von PostgreSQL wurde auch die Datenvalidierung verbessert, und Self-Hosting von Infisical ist nun deutlich einfacher
Fazit
- Die Entscheidung für den Wechsel von MongoDB zu PostgreSQL war nicht einfach und nahm nach sorgfältiger Planung und Diskussion 3 bis 4 Monate in Anspruch
- Es wird empfohlen, vor einem so großen Projekt die eigenen Use-Cases und die Implementierung gründlich zu durchdenken
1 Kommentare
Hacker-News-Kommentare
Ein Nutzer mit Erfahrung im großflächigen Betrieb von Postgres und MongoDB sagt, dass er beide Datenbanken mag, aber nicht nachvollziehen kann, warum Postgres keine Unterstützung für Hochverfügbarkeit (HA) und horizontale Skalierung bietet. Er weist darauf hin, dass jede Postgres-Installation anders sei und man dies mit verschiedenen Erweiterungen und Skripten ausgleichen müsse. Diese Erweiterungen seien oft fehleranfällig und schlecht dokumentiert. Außerdem erwähnt er, dass Upgrades wegen Änderungen am Dateiformat zwischen Hauptversionen sehr schwierig seien. Er zeigt sich überrascht, dass MySQL bei HA/Sharding viel besser sei als Postgres.
Es wird ein Blogpost geteilt, der die Migration von MongoDB zu PostgreSQL aus technischer Sicht beschreibt. Der Verfasser erwähnt, dass dieser Beitrag mit Beispielen und Grafiken technischer sei und weniger geschäftliche Inhalte enthalte.
Ein Nutzer, der sagt, dass PostgreSQL die Datenbankwelt erobere, weist darauf hin, dass die Autoren anfangs eine Architektur gewählt hätten, die nicht zum Datenmodell passte. Relationale Daten in einen nichtrelationalen Speicher zu stecken, werde immer Probleme verursachen.
Es wird auf einen Widerspruch hingewiesen zwischen der Aussage, dass die Wahl von MongoDB und Mongoose ORM darauf optimiert gewesen sei, die Entwicklungsgeschwindigkeit zu erhöhen, und der Verwendung von Tony Hoares Zitat „Vorzeitige Optimierung ist die Wurzel allen Übels“, um diese Wahl zu rechtfertigen.
Ein Nutzer, der Dokumentendatenbanken für neue Projekte nicht für geeignet hält, erwartet steigende Lizenz- und Hosting-Kosten bei MongoDB sowie eine Stagnation bei der Weiterentwicklung von Funktionen.
Ein Nutzer, der wegen Problemen mit MongoDB zu Postgres gewechselt ist, sagt, er sei mit dieser Entscheidung sehr zufrieden. Er ergänzt, dass es unbequem gewesen sei, dass MongoDB statt SQL JavaScript verwende.
Ein Nutzer merkt an, dass eine Diskussion über die Probleme fehle, die beim eigentlichen Rewrite-Prozess aufgetreten seien, und fragt, ob die Queries äquivalent umgesetzt wurden, wie das Produkt so aufgebaut wurde, dass auf beide Datenbanken gelesen und geschrieben werden konnte, ob während der Migration Bugs entdeckt wurden und ob sich die Queries 1:1 übertragen ließen.
Ein Nutzer mit Erfahrung mit MongoDB sagt, dass Dokumentendatenbanken für einige Anwendungsfälle geeignet seien, man aber in dem Moment über einen Wechsel zu einer relationalen Datenbank nachdenken sollte, in dem klar werde, dass Mongoose nötig ist. In den meisten Fällen werde Mongoose einem bestehenden Projekt hinzugefügt; wenn man es von Anfang an brauche, solle man eine relationale Datenbank verwenden.
Ein Nutzer, der ein Projekt mit MongoDB übernommen hat, sagt, dass ihm das BSON-Format nicht gefalle, er aber mag, dass vom JSON-API bis zur Datenbank dasselbe Schema verwendet werden kann. Er ergänzt, dass das gut zu datenorientierter Programmierung in Go und Rust passe. Er kommt zu dem Schluss, dass MongoDB nur für leseintensive Workloads geeignet sei und bei vielen Schreibvorgängen nicht besonders hilfreich sei.
Ein Nutzer sagt, dass der Hauptgrund für den Wechsel zu PostgreSQL eher Lizenzprobleme als technische Gründe gewesen seien, und berichtet von Leistungsverbesserungen durch Query-Optimierung mit Joins. Da die Daten nicht passend für einen Key-Value-Store modelliert gewesen seien, sei der Wechsel zu einer geeigneteren Speicherart der ausschlaggebende Grund gewesen.