PostgreSQL vs MongoDB für SaaS

Die falsche Frage

"PostgreSQL oder MongoDB?" ist die falsche Frage. Die richtige Frage lautet: "Welches Datenmuster hat meine Anwendung?" Trotzdem wird die Datenbankwahl in vielen Teams nach persönlicher Vorliebe oder dem letzten Hype-Artikel getroffen. Das führt zu Architekturen, die gegen die Stärken der gewählten Datenbank arbeiten.

Beide Datenbanken sind exzellent. Beide können Ihre SaaS antreiben. Aber sie lösen unterschiedliche Probleme optimal.

PostgreSQL: Die verlässliche Grundlage

PostgreSQL ist eine objekt-relationale Datenbank mit über 35 Jahren Entwicklung. Sie unterstützt SQL, ACID-Transaktionen, JSON/JSONB-Spalten, Volltextsuche, GIS-Daten und erweiterte Indizierung.

Ideal für:

• SaaS mit strukturierten Daten (User, Subscriptions, Invoices, Teams)
• Multi-Tenant-Architekturen (Row Level Security)
• Anwendungen mit komplexen Abfragen (JOINs, Aggregationen)
• Regulierte Branchen (Finanz, Gesundheit)

Nicht ideal für:

• Schemalose, sich schnell ändernde Datenstrukturen
• Extrem schreiblastige Workloads (Millionen Writes/Sekunde)
• Dokumenten-zentrische Anwendungen (CMS, Kataloge mit variablen Attributen)

MongoDB: Die flexible Alternative

MongoDB ist eine dokumentenbasierte Datenbank die JSON-ähnliche Dokumente speichert. Schema-flexibel, horizontal skalierbar durch Sharding, mit einer starken Query-Sprache.

Ideal für:

• Content-Management-Systeme
• IoT-Daten und Event Logs
• Prototyping und MVPs mit sich änderndem Schema
• Kataloge mit variablen Produktattributen

Nicht ideal für:

• Transaktionslastige Anwendungen (Banking, E-Commerce Checkout)
• Anwendungen mit vielen Relationen zwischen Entitäten
• Multi-Tenant SaaS mit strikter Datenisolierung

ACID vs Eventual Consistency

Der fundamentale Unterschied. Und der Grund, warum die meisten SaaS-Anwendungen mit PostgreSQL besser bedient sind.

ACID (PostgreSQL): Ein User upgraded seinen Subscription-Plan. Das erfordert: Subscription aktualisieren, Invoice erstellen, Feature-Flags setzen, Audit-Log schreiben. Entweder passiert alles oder nichts. Kein Zwischenzustand.

BEGIN;
UPDATE subscriptions SET plan = 'pro' WHERE user_id = 42;
INSERT INTO invoices (user_id, amount) VALUES (42, 49.00);
UPDATE feature_flags SET pro_features = true WHERE user_id = 42;
INSERT INTO audit_log (user_id, action) VALUES (42, 'plan_upgrade');
COMMIT;

Eventual Consistency (MongoDB): Ohne explizite Transaktionen könnte es passieren, dass die Subscription aktualisiert wird, aber die Invoice-Erstellung fehlschlägt. Der User hat dann Pro-Features aber keine Rechnung. MongoDB unterstützt seit Version 4.0 Multi-Document-Transaktionen, aber mit Performance-Overhead und Einschränkungen.

Für die meisten SaaS-Anwendungen, in denen es um Geld, Berechtigungen und Nutzerdaten geht, sind ACID-Transaktionen nicht optional.

JSON-Spalten in PostgreSQL: Das Beste aus beiden Welten

Ein häufiges Argument für MongoDB: "Unsere Daten sind nicht alle gleich strukturiert." PostgreSQL löst das mit JSONB-Spalten.

CREATE TABLE products (
  id SERIAL PRIMARY KEY,
  name TEXT NOT NULL,
  price DECIMAL NOT NULL,
  metadata JSONB DEFAULT '{}'
);

-- Flexibles Schema innerhalb einer relationalen Struktur
INSERT INTO products (name, price, metadata)
VALUES ('T-Shirt', 29.99, '{"color": "blue", "sizes": ["S", "M", "L"]}');

-- JSONB-Spalten sind indizierbar und abfragbar
CREATE INDEX idx_metadata ON products USING GIN (metadata);
SELECT * FROM products WHERE metadata->>'color' = 'blue';

Mit Prisma ORM:

const product = await prisma.product.create({
  data: {
    name: 'T-Shirt',
    price: 29.99,
    metadata: { color: 'blue', sizes: ['S', 'M', 'L'] },
  },
});

Sie bekommen relationale Integrität für strukturierte Daten und JSON-Flexibilität wo nötig. In der Praxis deckt das 95% der Use Cases ab, die Teams als Argument für MongoDB anführen.

Hosting-Optionen im DACH-Raum

Wo Sie Ihre Datenbank betreiben, ist eine DSGVO-Entscheidung. Managed Services in den USA sind bequem, aber rechtlich problematisch.

Anbieter	Datenbank	Region	Preis (ab)	DSGVO
Hetzner VPS + Docker	Beide	DE	€4/Mo	Volle Kontrolle
Supabase	PostgreSQL	EU (Frankfurt)	€0 (Free)	DPA verfügbar
Neon	PostgreSQL	EU (Frankfurt)	€0 (Free)	DPA verfügbar
MongoDB Atlas	MongoDB	EU (Frankfurt)	$0 (Free)	DPA verfügbar
AWS RDS	PostgreSQL	EU (Frankfurt)	~€15/Mo	DPA, CLOUD Act
Railway	Beide	EU möglich	$5/Mo	DPA verfügbar

DSGVO-Aspekte bei Managed Databases

Managed Database Services vereinfachen Betrieb und Wartung erheblich. Aber im DACH-Raum müssen Sie drei Dinge klären:

1. Datenstandort: Liegt die Datenbank physisch in der EU? Frankfurt-Region bei AWS, Atlas und Supabase ist verfügbar, muss aber explizit gewählt werden.

2. Auftragsverarbeitungsvertrag (AVV): Mit jedem Managed-DB-Anbieter muss ein AVV geschlossen werden. Supabase, MongoDB Atlas und AWS bieten Standard-DPAs an.

3. CLOUD Act bei US-Anbietern: AWS, MongoDB Inc. und Supabase (auf AWS gehostet) unterliegen dem US CLOUD Act. Für die meisten Anwendungen ist das ein akzeptables Risiko. Für Gesundheitsdaten, Finanzdaten oder den öffentlichen Sektor kann es ein Ausschlusskriterium sein.

Die konservative Lösung: PostgreSQL auf einem Hetzner VPS mit automatisierten Backups. Volle Kontrolle, kein CLOUD Act, keine Abhängigkeit von US-Diensten. Erfordert aber DevOps-Kapazität für Updates, Monitoring und Backup-Management. Teams, die diese Kapazität nicht intern haben, können das über einen Subscription-Development-Partner abdecken.

Skalierungsmuster

PostgreSQL skaliert vertikal zuerst:

• Read Replicas für Leseoperationen
• Connection Pooling mit pgBouncer
• Partitioning für große Tabellen
• Citus-Extension für horizontales Sharding (wenn nötig)

MongoDB skaliert horizontal:

• Sharding über Shard Keys
• Replica Sets für Hochverfügbarkeit
• Native horizontale Verteilung

In der Realität erreichen die meisten SaaS-Anwendungen nie den Punkt, an dem horizontale Skalierung nötig wird. Ein gut konfigurierter PostgreSQL-Server auf einem €50/Monat Hetzner Dedicated Server bewältigt Millionen von Zeilen und Tausende gleichzeitige Verbindungen.

Unsere Empfehlung

Für 90% der SaaS-Anwendungen: PostgreSQL. Strukturierte Daten, ACID-Transaktionen, Prisma ORM, JSONB für Flexibilität. Sie werden es nicht bereuen.

Für Content-Plattformen und IoT: MongoDB. Wenn Ihre Dokumente wirklich fundamental unterschiedliche Strukturen haben und Relationen zwischen Entitäten selten sind.

Für den Einstieg: Supabase (PostgreSQL) mit Free Tier. Managed, Frankfurt-Region, integrierte Auth und Storage. Wenn Sie wachsen, migrieren Sie auf Self-Hosted.

Fazit

Die Datenbankwahl ist eine der wenigen Architekturentscheidungen, die wirklich schwer zu korrigieren sind. Wählen Sie also bewusst. Für die überwiegende Mehrheit der SaaS-Anwendungen im DACH-Raum ist PostgreSQL die sichere Wahl: bewährt, ACID-konform, flexibel genug durch JSONB, und mit hervorragendem Tooling.

MongoDB hat seine Berechtigung. Aber wenn Ihr erstes Datenmodell Users, Teams, Subscriptions und Invoices enthält, greifen Sie zu PostgreSQL. Die Entscheidung können Sie in 15 Minuten treffen. Die Konsequenz tragen Sie über Jahre.

---

Verwandte Themen

• React vs Vue vs Angular: Vergleich 2026
• Authentifizierung für SaaS richtig umsetzen
• Multi-Tenancy
• API-First Development
• Node.js Backend Entwicklung