Wenn du 2026 ein neues Projekt startest und länger als zehn Minuten über die Datenbank-Wahl nachdenkst, ist die Antwort mit sehr hoher Wahrscheinlichkeit: PostgreSQL. Nicht weil Postgres in allem das Beste ist, sondern weil es in fast allem gut genug ist — und weil jede zusätzliche Datenbank in deinem Stack ein zweites System ist, das du betreiben, sichern, überwachen und verstehen musst.
Das klingt nach einer langweiligen These, und genau das ist der Punkt. Ich habe in eigenen Produkten und Kundenprojekten so ziemlich jede Kombination gesehen — und die Projekte mit den wenigsten Datenbank-Problemen waren durchgängig die mit der langweiligsten Wahl.
Das eigentliche Argument: Betriebskosten schlagen Feature-Vergleiche
Datenbank-Diskussionen werden fast immer als Feature-Vergleich geführt: Ist MongoDB schneller bei X? Skaliert Cassandra besser bei Y? Diese Debatte geht am realen Problem vorbei. Für die allermeisten Projekte — sagen wir alles unter Millionen aktiver Nutzer — ist nicht die theoretische Spitzenleistung der Engpass, sondern die Betriebsrealität: Wer spielt Updates ein? Wer testet die Backups? Wer versteht das Berechtigungsmodell? Wer debuggt nachts das zweite System, wenn es klemmt?
Jede Technologie im Stack hat laufende Kosten in Aufmerksamkeit. Ein Postgres, das du gut kennst, schlägt zwei Datenbanken, die du beide halb kennst. Das ist das ganze Argument — der Rest dieses Artikels ist nur die Prüfung, ob Postgres die fachlichen Anforderungen wirklich abdeckt. Spoiler: häufiger, als die Anbieter spezialisierter Datenbanken es dir erzählen.
”Aber ich brauche doch…” — die üblichen Einwände im Realitäts-Check
Dokumente und flexible Schemas → JSONB
Der klassische Grund für MongoDB war schemafreies Speichern von Dokumenten. Postgres kann das seit Jahren mit JSONB: verschachtelte Strukturen speichern, indizieren (GIN-Index), tief abfragen. Der entscheidende Vorteil: Du kombinierst flexibles JSON dort, wo die Struktur wirklich variabel ist, mit harten relationalen Garantien überall sonst. In der Praxis haben nämlich fast alle “schemalosen” Daten doch ein Schema — es steht nur nirgends und tut deshalb erst in Produktion weh.
Key-Value-Cache → erst mal UNLOGGED Tables oder einfach Indexe
Redis ist ein großartiges Werkzeug, aber die Frage ist, ob dein Projekt es schon braucht. Session-Storage, Rate-Limiting-Zähler, simple Caches: Das schafft Postgres für kleine und mittlere Lasten locker mit — eine ordentlich indizierte Tabelle beantwortet Punktabfragen in unter einer Millisekunde. Der Moment für Redis kommt, wenn du echte Hot-Path-Latenz-Probleme gemessen hast — nicht, wenn ein Tutorial es im Stack hatte.
Message Queue → SKIP LOCKED
Für Job-Queues in kleinen bis mittleren Systemen ist das Muster SELECT ... FOR UPDATE SKIP LOCKED erstaunlich robust: mehrere Worker, keine Doppelverarbeitung, Transaktionsgarantien inklusive — dein Job wird genau dann eingereiht, wenn die auslösende Transaktion wirklich committet. Genau diese Garantie verlierst du mit externem Broker (Stichwort Outbox-Pattern, das du dann zusätzlich bauen musst). RabbitMQ oder Kafka werden relevant bei sehr hohem Durchsatz, Fan-out an viele Konsumenten oder Event-Streaming als Architekturprinzip — nicht für “schick nach dem Signup eine Mail”.
Volltextsuche → tsvector reicht öfter als gedacht
Elasticsearch ist mächtig und ein eigenes Biest im Betrieb. Postgres-Volltextsuche mit tsvector, Ranking und Trigram-Indexen (pg_trgm) für Fuzzy-Matching deckt die Suchanforderungen typischer Anwendungen ab — Produktsuche, Dokumentensuche, Admin-Filter. Erst bei facettenreicher Suche über große Korpora mit Relevanz-Tuning als Kernfeature lohnt das separate System.
Vektoren für KI-Features → pgvector
Der neueste Grund für Zusatz-Datenbanken: Embeddings für semantische Suche und RAG. Auch hier gilt: pgvector bringt Vektor-Ähnlichkeitssuche mit Indexen (HNSW) direkt in Postgres. Bei Millionen von Embeddings mit harten Latenzanforderungen kann eine dedizierte Vektor-DB gewinnen — aber die meisten RAG-Projekte, die ich sehe, liegen weit darunter und fahren mit pgvector schlanker: eine Datenbank, ein Backup, Joins zwischen Vektoren und Geschäftsdaten gratis.
Wann du wirklich etwas anderes brauchst
Damit das keine Religion wird — es gibt legitime Ausnahmen, und sie sind erkennbar:
- Analytik über große Datenmengen: Spaltenorientierte Systeme (ClickHouse, BigQuery) schlagen Postgres bei OLAP-Workloads um Größenordnungen. Wenn Dashboards über Milliarden Zeilen dein Kernprodukt sind, ist das der Fall.
- Extreme Schreiblast / Zeitreihen: Metriken und IoT-Daten in sehr hohem Volumen — hier sind TimescaleDB (immerhin eine Postgres-Erweiterung) oder spezialisierte Systeme die richtige Wahl.
- Globale Verteilung mit niedriger Latenz überall: Multi-Region-Writes sind nicht Postgres’ Heimspiel; dafür gibt es verteilte SQL-Systeme.
- Echtes Caching unter Last: Gemessene (nicht befürchtete) Latenz-Probleme im Hot Path — dann Redis, gezielt und mit klarem Zweck.
Beachte das Muster: Alle Ausnahmen beginnen mit einer konkreten, gemessenen oder klar absehbaren Anforderung. Keine beginnt mit “könnte später mal nötig sein”. Für “später mal” hat Postgres eine beruhigende Eigenschaft: Du kannst jede dieser Spezial-Datenbanken nachrüsten, wenn der Bedarf real wird — und dann weißt du auch genau, welche Anforderungen sie erfüllen muss.
Der praktische Setup-Rat für kleine Teams
Wenn du die Wahl getroffen hast, noch die drei Betriebs-Basics, die häufiger vernachlässigt werden als die Wahl selbst: Erstens, automatisierte Backups mit getestetem Restore — ein Backup, das nie zurückgespielt wurde, ist ein Gerücht. pg_dump per Cron auf externen Speicher ist für kleine Projekte völlig legitim. Zweitens, Connection Pooling von Anfang an denken (PgBouncer oder der Pooler deines Frameworks), besonders bei Serverless-Umgebungen, die Verbindungen explodieren lassen. Drittens, langsame Queries sichtbar machen: pg_stat_statements aktivieren und gelegentlich reinschauen kostet nichts und findet die Probleme, bevor Nutzer sie finden.
Damit hast du einen Daten-Stack, der dich von der ersten Zeile bis zu ernsthafter Größe trägt, mit einem einzigen System, das du wirklich beherrschst. Langweilig? Absolut. Genau deshalb funktioniert es.
Wenn du über einen konkreten Fall diskutieren willst — “reicht Postgres für mein Setup?” — bring ihn in den Discord der Community mit, solche Architektur-Fragen sind da Alltag.