Stephan Schmidt - November 1, 2025

Einfach nur Postgres - Radikale Simplicität

Ersetze Redis, MongoDB, Kafka & mehr mit PostgreSQL. Reduziere Komplexität, beschleunige Entwicklung. Einfache Anleitung mit realen Beispielen.

Da hab ich es gesagt: Nutze einfach Postgres für alles.

Ich habe das bei drei Startups gemacht. Jedes Mal wollten die Entwickler anfangs Redis, Kafka, MongoDB und was weiß ich noch alles. Jedes Mal haben wir mit “nur Postgres” angefangen. Jedes Mal hat es funktioniert - bis zu Millionen von Nutzern.

Das Geheimnis? Mit weniger beweglichen Teilen geht weniger kaputt. Und wenn doch etwas kaputtgeht, weißt du genau, wo du suchen musst.

Warum nicht einfach das “richtige” Tool für den Job?

Weil das “richtige” Tool meistens Komplexität ist, die du nicht brauchst.

Typisches Startup: Redis für Caching, MongoDB für Dokumente, Kafka für Messaging, Elasticsearch für Suche. Das sind vier verschiedene Systeme mit vier verschiedenen Query-Sprachen, vier verschiedenen Monitoring-Setups, vier verschiedenen Backup-Strategien. Und vier verschiedene Möglichkeiten, um 3 Uhr nachts geweckt zu werden.

Postgres kann all das - bis zu Millionen von Nutzern. Ich weiß das, weil ich es gemacht habe.

Die wichtigsten Use Cases

Hier sind die Anwendungsfälle, die ich selbst produktiv eingesetzt habe:

Caching statt Redis

UNLOGGED-Tabellen mit JSONB. Stored Procedures für TTL. Fertig. Ich nutze ChatGPT, um die Stored Procedures zu schreiben - dauert 5 Minuten.

Message Queue statt Kafka

SKIP LOCKED für einfaches Queuing. Für Go gibt es River. Kafka brauchst du erst ab mehreren Millionen Messages pro Sekunde - und das hast du nicht.

Dokumentendatenbank statt MongoDB

JSONB kann alles, was MongoDB kann. Plus: ACID-Transactions. Plus: du musst keinen MongoDB-Admin einstellen.

Volltextsuche statt Elasticsearch

Postgres Fulltext Search reicht für 99% der Anwendungsfälle. Elasticsearch ist toll - aber auch ein Vollzeitjob.

Vector-Datenbank für AI

pgvector für Embeddings. Kein Pinecone, kein Weaviate. Postgres.

Session Store

hstore für Key-Value. Schneller als Redis für die meisten Workloads (ja, wirklich - messen, nicht raten).

Cron Jobs

pg_cron für geplante Tasks. Kein separater Cron-Server nötig.

Geospatial

PostGIS ist der Industriestandard. Besser als jede spezialisierte Geo-Datenbank.

Auditing

pgaudit für Compliance. SOC2-ready.

Und ja, es gibt noch mehr: Data Warehouse mit Timescale, GraphQL mit graphjin, Row-Level Security für Multi-Tenancy. Aber fang mit den Basics an.

Warum funktioniert das?

Postgres ist wie Linux geworden. Linux hat alle anderen Unix-Varianten verdrängt - nicht weil es perfekt war, sondern weil es gut genug war und ein Ökosystem hatte. Postgres absorbiert gute Ideen aus allen Datenbanken und macht sie zugänglich.

Der eigentliche Vorteil ist aber nicht technisch. Es ist:

• Ein Monitoring-Dashboard
• Ein Backup-System
• Eine Expertise, die dein Team aufbauen muss
• Ein System, das um 3 Uhr nachts kaputtgehen kann (statt fünf)

Extensions installieren

psql -U username -d database_name

-- Verfügbare Extensions anzeigen
SELECT * FROM pg_available_extensions;

-- Extension installieren
CREATE EXTENSION vector;  -- für pgvector
CREATE EXTENSION hstore;  -- für Key-Value

-- Prüfen, ob es funktioniert hat
SELECT * FROM pg_extension;

FAQ

“Aber was ist mit Single Points of Failure?”

Du meinst wie Redis, Kafka UND MongoDB, die alle gleichzeitig laufen müssen? Das sind drei Single Points of Failure. Mit Postgres hast du einen. Die Mathematik ist einfach: drei Systeme mit jeweils 99.9% Uptime = 99.7% gesamt. Ein System mit 99.9% = 99.9%.

“Postgres ist zu langsam für Caching!”

Instagram nutzt Postgres. Die haben mehr User als du. Dein Startup mit 10.000 Nutzern braucht keine Redis-Performance. Es braucht Entwickler, die Features shippen statt Infrastruktur zu debuggen.

“Meine Senior-Entwickler werden rebellieren.”

Wenn sie mehr über ihre Lieblingstools reden als über Kundenprobleme, sind sie nicht so senior wie sie denken. Gute Engineers wollen interessante Probleme lösen, nicht mit Spielzeug spielen. Zeig ihnen: ein Connection Pool, ein Monitoring, ein Backup. Das ist DevEx.

“Das ist doch Technical Debt!”

Nein. Technical Debt ist sechs verschiedene Query-Sprachen, vier Monitoring-Tools und drei Backup-Strategien zu haben. Postgres für alles ist das Gegenteil - technisches Guthaben, das später Dividenden zahlt.

“Wie verkaufe ich das dem Board?”

“Wir haben den operativen Overhead um 60% reduziert und liefern 50% mehr Features.” Das Board interessiert sich nicht für deinen Tech-Stack. Es interessiert sich für Ergebnisse.

Wann Postgres NICHT reicht

Ich bin nicht dogmatisch. Es gibt Fälle, wo du spezialisierte Tools brauchst:

• Millionen Messages pro Sekunde? Okay, dann Kafka.
• Petabytes an Daten? Dann brauchst du was anderes.
• Echtzeit-Analytics über Terabytes? Clickhouse oder BigQuery.

Aber wenn du diese Probleme hast, weißt du es. Und du bist wahrscheinlich kein Startup mehr.

Für alle anderen: Postgres. Fertig.

Ich bin Stephan Schmidt, CTO Coach und ehemaliger CTO bei eBay und ImmoScout24. Ich programmiere seit 40 Jahren (immer noch jeden Tag) und habe in dieser Zeit jeden Fehler gemacht, den man mit Datenbanken machen kann. MongoDB in Production? Gemacht. Redis als primäre Datenbank? Gemacht. Kafka für 1000 Messages pro Tag? Gemacht. Alles teuer bezahlt. Deshalb sage ich heute: Fang mit Postgres an. Spezialisierte Tools kannst du später immer noch hinzufügen - wenn du sie wirklich brauchst.

CTO Coaching für Deutschland und Europa | Kostenloses Gespräch buchen