PostgreSQL: relationale Standard-Datenbank für CH-KMU und KI-Stacks

Was ist PostgreSQL?

PostgreSQL ist eine relationale Open-Source-Datenbank, die seit 1996 unter der PostgreSQL License (einer MIT-ähnlichen, sehr freien Lizenz) entwickelt wird. Im Mai 2026 ist Version 17 der stabile Standard; Version 18 ist im Beta-Stadium. PostgreSQL wird von Stripe, Notion, Instagram, GitLab und tausenden weiteren produktiven Systemen eingesetzt -- es ist die Datenbank, die am wenigsten oft die falsche Wahl ist.

Funktional deckt PostgreSQL deutlich mehr ab als das klassische SQL-Repertoire. Native JSON- und JSONB-Spalten erlauben semi-strukturierte Daten ohne separate Dokumenten-DB. Window-Functions, Common Table Expressions (CTEs) und Recursive Queries machen Reports möglich, die in MySQL umständlich sind. Mit der pgvector-Extension wird Postgres zur produktiv einsetzbaren Vektor-Datenbank für RAG-Workloads bis ca. 1 Million Embeddings. PostGIS macht die gleiche Instanz zur Geo-Datenbank für Liegenschafts- oder Logistik-Anwendungen.

Die Lizenz ist ein praktischer Bonus: keine Royalties, keine Re-Distribution-Sperren, keine Lizenz-Inspektionen. Ein KMU darf PostgreSQL frei einsetzen, modifizieren und weiterreichen -- auch in kommerziellen SaaS-Produkten. Im Vergleich zur SSPL-Lizenz von MongoDB oder Redis (ab 2024) ist das ein echter Vorteil.

In unserem Hetzner-Stack laufen mehrere Postgres-Instanzen pro Server in Docker-Containern: eine für Fairlane-Mandanten, eine für Acquanta-CRM, eine für Pexeos. Backup über WAL-Archiving plus Basebackup. Die Instanzen sind isoliert, aber teilen sich die Hardware -- eine kosteneffiziente Konfiguration für ein KMU mit mehreren Produkten.

Warum es wichtig ist

Die Datenbank-Entscheidung hält 5-10 Jahre. Wer falsch wählt, finanziert später Migrationen, die Wochen oder Monate Entwickler-Zeit verschlingen. PostgreSQL ist im Mai 2026 die sichere Default-Wahl für drei Gründe.

Erstens: Funktions-Breite ohne zusätzliche Server. Eine Postgres-Instanz erledigt relationale Daten, JSON-Dokumente, Full-Text-Search, Vektor-Suche und Geo-Queries. Wer bei einer KMU-Anwendung mit MySQL plus MongoDB plus Elasticsearch plus Qdrant startet, betreibt vier Server, vier Backup-Strategien, vier Monitorings. Postgres erledigt 80 Prozent davon in einer einzigen Instanz -- weniger Komplexität, weniger Risiko.

Zweitens: revDSG- und DSGVO-Tauglichkeit ohne Nachverhandlung. Self-Host auf Hetzner Falkenstein oder Helsinki ist eine 30-Minuten-Installation, kein Drittland-Transfer nötig. AVV (Auftragsverarbeitungsvertrag) fällt weg, weil keine externen Datenverarbeiter beteiligt sind. Für Treuhand, Anwalt, Versicherung und öffentlichen Sektor in CH ist das der Pfad des geringsten Widerstands.

Drittens: Migrations-Optionen bleiben offen. Postgres-Wire-Protokoll wird von CockroachDB (verteilt), Supabase (BaaS), Neon (Serverless) und AWS Aurora Postgres-kompatibel gesprochen. Wer in 3 Jahren auf eine dieser Optionen wechseln muss, hat einen klaren Migrationspfad -- meist ein Dump-Restore mit minimalen Anpassungen. MongoDB- oder DynamoDB-Migrationen sind dagegen mehrwoechige Projekte mit Schema-Redesign.

Der Kostenpunkt rundet das Bild ab: Postgres auf Hetzner CPX31 (4 vCPU, 16 GB RAM, 160 GB SSD) kostet CHF 25 pro Monat. Mit zusätzlich 30 CHF Storage-Box für Backups landet man bei CHF 55 pro Monat für einen Produktiv-Stack, der mit den meisten Cloud-Angeboten von AWS RDS (USD 70+) oder Azure Database for PostgreSQL (USD 80+) konkurriert -- bei voller Datenresidenz in der EU.

Wie es funktioniert

PostgreSQL ist ein klassischer Multi-Process-Server: ein Postmaster-Prozess akzeptiert Verbindungen, für jede Verbindung wird ein Backend-Prozess geforkt. Dazu kommen Hilfs-Prozesse für WAL-Writer, Checkpointer, Autovacuum und Background-Worker. Auf einem 16-GB-Server laufen typisch 100-200 Verbindungen komfortabel; bei mehr setzt man pgbouncer als Connection-Pool davor.

Die Speicher-Architektur trennt zwei Caches: shared_buffers (typisch 25 Prozent des RAM) hält Datenseiten, der OS-Page-Cache hält den Rest. WAL (Write-Ahead-Log) schreibt jede Änderung erst sequentiell auf Platte, dann werden Datenseiten asynchron geschrieben. Diese Architektur macht PITR (Point-In-Time-Recovery) möglich: man archiviert WAL-Segmente, und kann auf jeden Zeitpunkt zwischen zwei Basebackups zurückspielen.

Ein minimal-produktiver Setup sieht so aus:

CREATE TABLE mandanten ( id BIGSERIAL PRIMARY KEY, name TEXT NOT NULL, metadata JSONB DEFAULT '{}', created_at TIMESTAMPTZ DEFAULT now() );

CREATE INDEX idx_metadata_gin ON mandanten USING GIN(metadata); CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE rag_chunks ( id BIGSERIAL PRIMARY KEY, mandant_id BIGINT REFERENCES mandanten(id), text TEXT, embedding VECTOR(1536) );

CREATE INDEX ON rag_chunks USING hnsw (embedding vector_cosine_ops);

Die Extensions-Mechanik ist Postgres-Kernstärke. Es gibt über 250 Extensions: pgvector für Embeddings, PostGIS für Geo, pg_partman für automatische Partitionierung, pg_stat_statements für Query-Performance, TimescaleDB für Zeit-Reihen, Citus für horizontale Skalierung. Jede Extension ist ein Drop-in -- CREATE EXTENSION reicht, kein Server-Restart.

Replikation läuft über Streaming-Replication mit Primary und Standby. Ein Standby kann synchron oder asynchron repliziert werden; für ein KMU reicht asynchron. Bei Failover wird der Standby per pg_promote zum Primary. Mit Patroni und etcd lässt sich Auto-Failover bauen -- aber für die meisten KMU-Setups ist manuelles Failover (RTO 15-30 Min) ausreichend, das spart Komplexität.

Backup-Standard: tagliches pg_basebackup auf eine Storage-Box, dazu kontinuierliches WAL-Archiving via pg_receivewal. Für Recovery: Basebackup + WAL-Segmente bis zum gewünschten Zeitpunkt, dann pg_ctl start. Eine 50-GB-Datenbank ist in 10-20 Minuten zurück.

PostgreSQL in 5 Schritten produktiv

1. 01Hetzner-Server (CPX31 oder grosser) bereitstellen, Docker installieren, PostgreSQL 17 als Container mit gemountetem Volume starten.
2. 02Schema und Extensions anlegen: CREATE EXTENSION pgvector / pg_stat_statements / pg_audit -- je nach Use-Case. Tabellen mit BIGSERIAL, TIMESTAMPTZ und Foreign Keys definieren.
3. 03Backup-Strategie einrichten: tagliches pg_basebackup auf Hetzner Storage Box, kontinuierliches WAL-Archiving via pg_receivewal, Retention 30 Tage täglich plus monatlich.
4. 04Monitoring anbinden: pg_stat_statements aktivieren, postgres_exporter für Prometheus, Grafana-Dashboard mit Query-Latenz, Connections und Cache-Hit-Ratio.
5. 05Recovery testen: Backup zurückspielen, PITR auf einen Zeitpunkt vor 1 Stunde simulieren -- dokumentieren und im Notfall-Handbuch hinterlegen.

Wann PostgreSQL einsetzen

PostgreSQL ist die richtige Wahl, wenn (a) Daten relational strukturiert sind oder werden können, (b) Transaktions-Sicherheit (ACID) gefordert ist, oder (c) das Team eine bewährte, dokumentierte Standard-DB ohne Lock-in-Risiko sucht.

Konkrete Szenarien: ein Mandanten-Portal für ein Treuhand-Büro mit 200 Kunden, Rechnungen, Belegen und Zeiterfassung. Eine Anwalts-Software mit Fällen, Dokumenten, Honorar-Erfassung und Aktenführung. Ein Versicherungs-CRM mit Verträgen, Schäden, Provisionen. Eine SaaS-Plattform mit Multi-Tenant-Schema und Audit-Trails. Eine RAG-Wissensbasis mit pgvector für 100k-1M Embeddings.

Auch Postgres-Fälle, die oft übersehen werden: Time-Series-Daten (mit TimescaleDB-Extension) bis einige Milliarden Einträge, Job-Queue-Systeme (mit SKIP LOCKED), Eventual-Consistency-Stores (mit Logical Replication als Outbox-Pattern), Real-Time-Dashboards (mit pg_notify und Listen/Notify). Wer 2026 ein neues KMU-System startet, sollte mit Postgres beginnen und nur dann eine andere DB hinzunehmen, wenn ein konkreter Engpass auftritt.

Für regulierte Branchen in der Schweiz -- Treuhand (Art. 957a OR), Anwalt (Berufsgeheimnis Art. 321 StGB), Versicherung (FINMA-Aufsicht), öffentlicher Sektor -- ist Postgres self-host auf CH/EU-Hardware die operativ einfachste und rechtlich sauberste Konfiguration. Audit-Trail über pg_audit-Extension, Row-Level-Security für Mandanten-Trennung, Logical-Replication für Disaster-Recovery.

Wann NICHT

Bei ausschliesslicher OLAP-Last (Aggregate über Milliarden Zeilen) ist ClickHouse oder DuckDB schneller -- Postgres ist row-orientiert, columnar-DBs erreichen bei reinen Analyse-Workloads 50-100x Geschwindigkeitsvorteil. Wer in einem SaaS-Produkt 500M Telemetrie-Einträge pro Monat aggregiert, gehört nicht in Postgres.

Für Multi-Region-Setups mit synchroner Konsistenz über CH + DE + USA hinweg ist CockroachDB die bessere Wahl -- Postgres replication ist asynchron oder synchron mit hohem Performance-Verlust über WAN. Wer Datenkonsistenz unter 100 ms Latenz an drei Standorten braucht, sieht sich Cockroach an.

Für Embedded-Use-Cases ohne Server (Desktop-Apps, mobile Apps, eingebettete Geräte) ist SQLite besser geeignet -- eine Datei, kein Daemon, kein Netzwerk-Stack. Postgres braucht immer einen laufenden Server-Prozess und macht in Single-Tenant-Embedded-Szenarien keinen Sinn.

Für Workloads mit echten schemalosen Daten -- 50+ verschiedene Sensor-Typen mit jeweils anderem Schema, dynamisches CMS mit nutzerdefinierten Feldern -- kann MongoDB einfacher sein. Aber Vorsicht: in 80 Prozent der Fälle reicht Postgres jsonb plus GIN-Index, und Mongo bringt SSPL-Lizenz-Themen mit, die Postgres nicht hat.

In-Memory-Caching, Pub/Sub und Job-Queues sind in Redis besser aufgehoben -- nicht weil Postgres es nicht kann, sondern weil Redis-Latenz im Mikrosekunden-Bereich liegt vs. Postgres im Millisekunden-Bereich. Redis ist die richtige Ergänzung zu Postgres, nicht ein Ersatz.

Vor- und Nachteile

Häufige Fragen

Verwandte Themen

Quellen

1. PostgreSQL 17 Release Notes · 2026-05
2. PostgreSQL Versioning Policy and Support Lifecycle · 2026-05
3. pgvector extension - GitHub releases · 2026-05
4. PostgreSQL Licensing FAQ · 2026-05