PostgreSQL statt MongoDB für neue Services

databasepostgresqlarchitecture

Kontext

Wir entwickelten einen neuen Service zur Verwaltung von Kunden-Abonnements mit komplexer Abrechnungslogik. Das Team diskutierte zwischen PostgreSQL und MongoDB, das wir bereits für andere Services eingesetzt hatten.

Entscheidung

PostgreSQL für den Abonnement-Service verwenden und als Standard für neue Services mit relationalen Daten festlegen

Betrachtete Alternativen

MongoDB verwenden (unser bisheriger Standard)

Vorteile
  • Team bereits erfahren mit MongoDB
  • Flexibles Schema für sich ändernde Anforderungen
  • Gut geeignet für dokumentenorientierte Daten
Nachteile
  • Transaktionen über mehrere Collections sind komplex
  • Joins erfordern Logik auf Anwendungsebene
  • Schema-Flexibilität kann zu Dateninkonsistenzen führen

PostgreSQL verwenden

Vorteile
  • ACID-Transaktionen für Abrechnungsgenauigkeit
  • Leistungsfähige Abfragen mit JOINs
  • Starke Datenintegrität durch Constraints
  • JSONB für flexible Felder bei Bedarf
Nachteile
  • Team muss PostgreSQL erst erlernen
  • Schema-Migrationen erfordern mehr Planung
  • Anderes Betriebsmodell als MongoDB

Begründung

Abonnement-Abrechnung erfordert starke Konsistenzgarantien, die in PostgreSQL selbstverständlich sind, in MongoDB aber sorgfältige Handhabung erfordern. Das relationale Modell passt besser zu unseren Daten (Kund:innen, Tarife, Rechnungen, Zahlungen) als Dokumente. JSONB in PostgreSQL bietet uns bei Bedarf Schema-Flexibilität, ohne relationale Fähigkeiten zu opfern.

Warum diese Entscheidung wichtig war

Abrechnungssysteme haben null Toleranz für Inkonsistenzen. Eine doppelte oder gar keine Belastung eines Kunden ist inakzeptabel. Wir benötigten:

  • Atomare Transaktionen über mehrere Tabellen hinweg
  • Starke referenzielle Integrität
  • Komplexe Abfragen für Reporting
  • Audit-Trail für Compliance

Die MongoDB-Erfahrung

Wir hatten MongoDB 3 Jahre lang genutzt. Es funktionierte gut für:

  • Nutzerprofile (dokumentenorientiert)
  • Produktkataloge (flexibles Schema)
  • Aktivitätsprotokolle (überwiegend Anhängen)

Aber wir hatten Schwierigkeiten mit:

  • Transaktionen über mehrere Dokumente (seit 4.0 vorhanden, aber weiterhin umständlich)
  • Reporting-Abfragen (die Aggregation Pipeline ist leistungsfähig, aber komplex)
  • Datenkonsistenz (fehlende Fremdschlüssel führten zu verwaisten Datensätzen)

PostgreSQL-Evaluierung

Wir führten einen zweiwöchigen Testlauf durch, um PostgreSQL zu evaluieren:

  1. Modellierung der Abonnement-Domäne relational
  2. Implementierung zentraler Abrechnungsvorgänge
  3. Test des Transaktionsverhaltens bei Fehlern
  4. Bewertung der Abfrageperformance für Reporting

Die Ergebnisse waren überzeugend. Komplexe Abrechnungsabfragen, die zuvor über 50 Zeilen Aggregation Pipeline erforderten, wurden zu 10-zeiligen SQL-Abfragen.

Migrationspfad

Wir haben bestehende MongoDB-Services nicht migriert. Stattdessen:

  • Neue Services mit relationalen Daten verwenden PostgreSQL
  • Bestehende MongoDB-Services bleiben bestehen (sofern sie gut funktionieren)
  • Gemeinsam genutzte Daten werden über APIs abgerufen, nicht per direktem DB-Zugriff

Lernprozess im Team

Wir haben in PostgreSQL-Schulungen investiert:

  • Interne Workshops zu SQL und PostgreSQL-Funktionen
  • Pair Programming während der ersten Entwicklungsphase
  • Dokumentation von Mustern und Best Practices

Nach 6 Monaten ist das Team mit beiden Datenbanken vertraut und kann für jeden Anwendungsfall das passende Werkzeug wählen.

Alle Entscheidungen