Für ein SaaS, das skalieren soll, ist die richtige Standardwahl PostgreSQL. Es deckt rund 90 % dessen ab, was ein Web- oder Mobile-Produkt braucht: transaktionale Daten, Beziehungen zwischen Entitäten, Suche, JSON, leichtgewichtige Queues und sogar einen Teil der Vektor-Last für KI. Die eigentliche Frage lautet fast nie "relational oder NoSQL", sondern "habe ich einen konkreten Grund, NICHT Postgres zu nehmen". Meistens nicht.
PostgreSQL als Standard: warum es in 9 von 10 Fällen passt
Ein SaaS verarbeitet strukturierte, miteinander verknüpfte Daten: Nutzer, die zu Organisationen gehören, Abos, die an Rechnungen hängen, Projekte, die mit Aufgaben verbunden sind. Genau dafür sind relationale Datenbanken gemacht. Postgres legt auf dieses Fundament Superkräfte, die das Stapeln zusätzlicher Tools überflüssig machen: JSONB-Spalten für Halbstrukturiertes, integrierte Volltextsuche, die Erweiterung pgvector für KI-Embeddings und Constraints, die die Integrität deiner Daten garantieren.
- ACID-Transaktionen: Zahlungen und kritische Daten bleiben konsistent, selbst nach einem Absturz.
- Ein System statt drei zum Betreiben, Sichern und Überwachen — weniger Kosten, weniger Ausfälle.
- Reifes Ökosystem: Prisma, Migrationen, Replikation, überall managed Hosting (Cloud Run, Neon, Supabase, RDS).
- JSONB, wenn du Flexibilität brauchst, ohne für den Rest auf Relationalität zu verzichten.
Relational vs. NoSQL: wann man Postgres verlässt
NoSQL (MongoDB, DynamoDB, Firestore) ist nicht "moderner", es beantwortet andere Anforderungen. Es zahlt sich nur aus, wenn dein Anwendungsfall wirklich passt: massives, schreibintensives Volumen, ein wirklich unvorhersehbares Schema oder der Bedarf an extremer geografischer Verteilung. Für ein typisches B2B-SaaS in der Launch- und Wachstumsphase existieren diese Anforderungen noch nicht — und wer NoSQL zu früh einführt, zahlt in Komplexität für etwas, das er nie nutzen wird.
NoSQL zu wählen, weil "es skaliert", während man 200 Nutzer hat, heißt ein Problem zu optimieren, das man nicht hat — auf Kosten derer, die man schon hat.
Indizes, Migrationen, Skalierung: drei Reflexe ab der V1
Eine gut gewählte Datenbank reicht nicht: Drei Gewohnheiten entscheiden, ob dein SaaS bei 10.000 Nutzern hält. Erstens Indizes — eine Query, die eine ganze Tabelle scannt, ist bei 100 Zeilen schnell und bei 1 Million katastrophal. Indiziere die Spalten, nach denen du häufig filterst und joinst, und miss mit EXPLAIN. Zweitens Migrationen: Jede Schemaänderung muss versioniert und wiederholbar sein (Prisma Migrate), niemals von Hand in der Produktion angewandt. Drittens Skalierung: zuerst vertikal (mehr CPU/RAM), dann Read-Replicas, und über Sharding denkt man erst sehr spät nach — die meisten SaaS kommen nie dorthin.
- Indizes: ziele auf die Spalten in WHERE-, JOIN- und ORDER-BY-Klauseln; ein schlechter Index kostet beim Schreiben, ein fehlender killt das Lesen.
- Migrationen: versioniert, getestet, reversibel — die Datenbank entwickelt sich mit dem Produkt ohne Downtime.
- Skalierung: zuerst vertikal, dann Read-Replicas; Postgres verkraftet Millionen Zeilen, lange bevor Sharding zum Thema wird.
Die richtige Entscheidung für eine V1
PostgreSQL von Tag eins wählen, sauber modellieren, die richtigen Indizes setzen und Migrationen versionieren: Das erspart dir das Neuschreiben in Monat 12. Genau dieses Fundament bauen wir in unseren V1s, die wir in 7 Tagen für 15.000 € liefern — Next.js, NestJS, Prisma und Postgres —, eine Datenbank, die dich vom ersten Kunden bis zur Skalierung trägt, ohne versteckte technische Schulden.