Eine Datenbank sollte Ihr Standard sein
Die meisten SaaS-Startups überdenken ihre Datenbankschicht.
Das Pitch Deck zeigt Postgres für transaktionale Daten, MongoDB für Dokumente, Elasticsearch für Suche, Redis für Caching und eine Vektordatenbank “für die KI-Features”. Fünf Systeme, fünf Sätze Zugangsdaten, fünf Backup-Strategien, fünf Stellen, an denen um 3 Uhr morgens etwas schiefgehen kann.
Wir haben diesen Stack mehr als einmal von Kunden geerbt. Wir haben ihn auch wieder auf Postgres allein zurückgeschrieben und dabei sinkende Antwortzeiten und fallende Betriebskosten gesehen.
Ein Kunde kam mit einem B2B-Analytics-Produkt zu uns, das Postgres + MongoDB + Elasticsearch + Redis betrieb. Vier Datenbanken, drei Entwickler, die den Großteil ihrer Zeit mit der Datensynchronisation zwischen ihnen verbrachten.
Wir haben in sechs Wochen alles auf eine einzige Postgres-18-Instanz mit JSONB, tsvector und pgvector migriert. Die monatliche Datenbankrechnung sank von 4.200 auf 380 USD. Die Bereitschaft wurde ruhig. Das Team konnte zum ersten Mal seit Monaten wieder an Features arbeiten, statt an Synchronisationspipelines zwischen vier Systemen.
Die ehrliche Antwort 2026: PostgreSQL bewältigt rund 90 % dessen, was ein B2B-SaaS braucht. Die anderen 10 % sind real, aber enger gefasst, als Berater Ihnen weismachen.
Postgres ist seit 2023 in jedem Stack Overflow Developer Survey die meistgenutzte Datenbank. Im 2025er Survey lag sie bei 55,6 % unter professionellen Entwicklern, ein Vorsprung von 15 Punkten gegenüber MySQL. Die “langweilige” Wahl ist auch die populäre.
In diesem Beitrag geht es um beide Hälften.
Was Postgres leise mitliefert, das viele vergessen
Postgres begann als relationale Datenbank. Das ist sie nach wie vor. Die Engine in Ihrem docker-compose.yml kann jedoch deutlich mehr als SELECT * FROM users.
Dokumente, mit Zwängen
JSONB ist seit Postgres 9.4 (2014) produktionsreif. Sie bekommen Dokumentenspeicher mit Schemaflexibilität, GIN-Indizes für schnelle Lookups im JSON-Baum und die Option, einzelne Felder in relationale Spalten zu überführen, sobald sie sich stabilisieren.
Wir hatten Kunden, die MongoDB gewählt hatten “weil wir unser Schema noch nicht kennen”, und dann achtzehn Monate damit verbrachten, Joins von Hand im Anwendungscode zu bauen. Dieselben Daten in Postgres + JSONB wären schneller ausgeliefert worden und SQL-abfragbar geblieben.
Volltextsuche, die gut genug ist
tsvector und tsquery sind seit Postgres 8.3 dabei. Mit GIN-Indizes und ts_rank bekommen Sie eine Suche, die für die meisten B2B-Anwendungsfälle gut gegen Elasticsearch besteht. Mehrsprachiges Stemming, Präfixsuche, gewichtete Treffer, alles in Ihrer bestehenden Datenbank.
Ist sie so flexibel wie Elasticsearch für Log-Analytics oder massive Dokumentensammlungen? Nein. Für “lassen Sie Nutzer ihre eigenen Datensätze durchsuchen” reicht sie locker.
Vektorsuche, dank pgvector
Mit pgvector und der Reife der HNSW-Indizierung in pgvector 0.8 (iterative Scans, schnellere Builds, bessere Performance bei gefilterten Queries) hat sich die KI-Diskussion verändert. Sie brauchen Pinecone oder Weaviate für die meisten RAG-Anwendungen nicht. Sie brauchen eine Postgres-Erweiterung und eine Query.
Wir haben für Kunden RAG-Systeme gebaut, bei denen der gesamte Vektorspeicher eine einzige embeddings-Tabelle neben den bestehenden Daten ist. Vektorähnlichkeit zusammen mit Mandantenfiltern, Berechtigungschecks und Aktualitätsregeln in einer SQL-Abfrage zu joinen, ist befreiend, wenn Sie sonst zwei Datenbanken synchronisieren.
Queues ohne Redis
Verzichten Sie auf Redis. SELECT FOR UPDATE SKIP LOCKED (Postgres 9.5+) lieferte das Primitiv, das für die meisten Job-Queues gut genug ist. Solid Queue (Rails 8) verarbeitet bei HEY 20 Millionen Jobs pro Tag darauf. River für Go, Procrastinate oder PgQueuer für Python, Graphile Worker für Node.
Für die meisten Teams bedeutet “kein Redis” ein System weniger zu überwachen, abzusichern und zu bezahlen.
Echtzeit, in Maßen
LISTEN und NOTIFY geben Ihnen Pub/Sub innerhalb von Postgres. Logical Replication streamt Änderungen auf Zeilenebene überall hin, wo Sie sie haben wollen. In Kombination mit WebSockets im Application-Server reicht das für die meisten “zeig mir, wann sich dieser Datensatz ändert”-Features.
Reicht nicht für Chat-App-Fan-out. Reicht für die Live-Dashboards und Benachrichtigungen, die ein B2B-SaaS tatsächlich ausliefert.
Warum die Ein-Datenbank-Variante gewinnt
Operative Einfachheit ist unterbewertet, besonders in Unternehmen ohne dediziertes Plattform-Team. Die meisten B2B-SaaS-Firmen brauchen keine Kubernetes-Cluster, Service Meshes oder Polyglot-Persistenz. Sie brauchen Features, und sie wollen am Wochenende nicht angerufen werden.
Eine Datenbank bedeutet einen Connection Pool, eine Backup-Strategie, einen Satz Zugriffsregeln, einen Satz Metriken zur Überwachung, einen Upgrade-Pfad. Ihr psql-Wissen funktioniert auf jedem Teil des Systems.
Auch Multi-Tenancy-Entscheidungen werden einfacher. Egal ob Shared Schema mit Row-Level Security oder Schema-pro-Mandant, Postgres beherrscht beides nativ. Wir haben die Trade-offs in Datenisolierung und Sicherheit in Multi-Mandanten-Systemen ausführlich beschrieben.
Eine einzige Postgres-Instanz auf einem Hetzner-Server mit sauberer Indexierung, Connection-Pooling über PgBouncer und einer verwalteten Read Replica bewältigt zehntausende Requests pro Sekunde. Die meisten B2B-SaaS erreichen diese Decke nie.
Wenn Ihres es tut, herzlichen Glückwunsch. Sie können sich einen Plattform-Engineer leisten.
Wann Postgres nicht mehr genügt
Postgres ist der richtige Startpunkt. Es ist nicht für alles der richtige Endpunkt.
Time-Series in großem Maßstab
Sobald Sie hunderttausende Zeilen pro Sekunde an Metriken, IoT-Messungen oder Finanztickern aufnehmen, beginnt Postgres zu leiden. Indizes wachsen explosiv, Vacuums hängen hinterher, und Partitionierung wird zum Vollzeitjob.
TimescaleDB (eine Postgres-Erweiterung) erkauft Ihnen eine weitere Größenordnung, bevor Sie die Familie verlassen. Danach: ClickHouse, InfluxDB oder QuestDB. Wählen Sie nach Ihren Abfragemustern.
Wenn Sie unter “anhaltend zehntausende Inserts pro Sekunde” liegen, ist Postgres mit pg_partman wirklich in Ordnung.
Suche über heterogene, riesige Dokumentenkorpora
Die Postgres-Volltextsuche ist großartig für “lassen Sie unsere Nutzer ihre eigenen Daten durchsuchen”. Sie ist nicht das richtige Werkzeug, wenn die Suche selbst das Produkt ist (denken Sie an Log-Analytics-Plattformen, öffentliche Dokumentenindizes oder Multi-Mandanten-Search-as-a-Service).
Elasticsearch und OpenSearch existieren, weil dieser Workload anders ist. Facetten, Aggregation über Milliarden Dokumente, Synonymwörterbücher, eigene Relevanzmodelle. Postgres schlägt sie nicht in ihrem eigenen Spiel.
Echte Graph-Workloads
Wenn Sie beliebig tiefe Beziehungen durchqueren (Empfehlungen, Betrugsringe, Wissensgraphen mit tiefen transitiven Abfragen), funktionieren rekursive CTEs in Postgres, werden aber langsam.
Neo4j oder Memgraph existieren aus einem Grund. Der Break-even-Punkt liegt später, als Leute denken, aber er existiert.
Cache, der in Mikrosekunden leben muss
Für Application-Level-Caching ist Postgres + das Solid-Cache-Muster in Ordnung. Für Sub-Millisekunden-Cache-Hits bei extremem Volumen (heiße Leaderboards, Session-Tokens bei 100k req/s) gewinnen Redis oder KeyDB weiterhin.
Die meisten B2B-SaaS erreichen diese Schwelle nicht. Wenn Ihres es tut, werden Sie es wissen.
Was wir ausliefern
Standard: Postgres 18 auf einer einzigen verwalteten Instanz (Hetzner, Supabase, Neon oder AWS RDS) mit PgBouncer für Pooling und einem täglichen logischen Backup in einen EU-Bucket. Mandantenisolation über Row-Level Security oder Schema-pro-Mandant, je nach Produkt. PG18s Async-I/O-Subsystem und uuidv7-Primärschlüssel sind die Art Upgrade, die Sie umsonst bekommen, wenn Sie auf dem langweiligen Pfad bleiben.
JSONB für alles wirklich Dokumentförmige. tsvector für In-App-Suche. pgvector für Retrieval-augmentierte Features. SELECT FOR UPDATE SKIP LOCKED (oder Solid Queue, River, Graphile) für Hintergrundjobs.
Wenn Kunden eine echte Decke erreichen, fügen wir gezielt das hinzu, was sie brauchen. TimescaleDB, wenn die Metrik-Aufnahme die Komfortzone verlässt, Elasticsearch als Sekundärindex, wenn die Suche selbst zum Produkt wird, Redis zuletzt und nur, wenn Cache-Latenz in nutzerseitigen Metriken auftaucht.
Wir starten fast nie mit fünf Datenbanken. Wir landen fast immer bei einer oder zwei.
Die architektonische Lehre ist dieselbe wie in unserem Blick auf die wahren Kosten technischer Schulden: Bauen Sie für das Problem, das Sie wirklich haben, nicht für jenes, das Ihr Pitch Deck bei der Series B vermutet.
Postgres hat Ihnen ein Jahr gekauft, oft drei. Nutzen Sie die Zeit, um Produkt auszuliefern, statt fünf Systeme zusammenzuflicken, die alle ungefähr dasselbe tun.
Den Wechsel von “fünf Datenbanken auf eine” erzählen wir immer wieder, weil wir ihn immer wieder funktionieren sehen. Der schwierige Teil ist nicht die Migration. Der schwierige Teil ist, sich vorher selbst davon abzuhalten, vier Datenbanken einzubauen, die Sie am Tag eins nicht brauchen.
Sie wählen die Datenschicht für ein neues SaaS oder entwirren ein polyglottes Setup, das Sie ausbremst? Lassen Sie uns reden. Wir schauen uns Ihren echten Workload an und sagen Ihnen ehrlich, wann Sie auf einer Datenbank bleiben können und wann nicht.