Wer heute ein neues Softwareprojekt mit einer relationalen Datenbank beginnt, landet erstaunlich oft bei PostgreSQL. Das gilt für das Start-up mit seiner ersten Web-App ebenso wie für den Mittelständler, der eine Oracle-Lizenz ablösen will, oder das Entwicklungsteam, das für einen KI-Assistenten eine Vektorsuche braucht. Bemerkenswert ist das, weil hinter PostgreSQL kein Konzern steht, sondern eine weltweite Gemeinschaft aus Entwicklern und Firmen.

Woher kommt PostgreSQL, was unterscheidet die Datenbank von anderen, und wo liegen ihre Grenzen? Die allgemeinen Grundlagen relationaler Datenbanken – Primär- und Fremdschlüssel, Beziehungstypen, Normalisierung und JOINs – werden hier vorausgesetzt. Sie stehen im Beitrag Beziehungen in SQL-Datenbanken: Schlüssel, Normalisierung und JOINs.

Von Berkeley zum Gemeinschaftsprojekt

Die Geschichte beginnt 1986 an der University of California in Berkeley. Der Informatiker Michael Stonebraker startete dort das Forschungsprojekt POSTGRES, den Nachfolger seiner früheren Datenbank Ingres – daher der Name „Post-Ingres“. Das Ziel war ein System, das sich um eigene Datentypen und Funktionen erweitern lässt. Mitte der 1990er-Jahre erhielt das Projekt eine SQL-Schnittstelle, 1996 den heutigen Namen PostgreSQL. Seitdem entwickelt die PostgreSQL Global Development Group die Datenbank weiter.

Zwei Eigenschaften prägen das Projekt bis heute. Erstens gibt es keinen einzelnen Eigentümer: Beiträge kommen von Freiwilligen und von Firmen, die PostgreSQL selbst einsetzen oder Dienstleistungen dafür anbieten. Kein Hersteller kann die Lizenz ändern oder das Produkt einstellen. Zweitens folgt die Entwicklung einem verlässlichen Rhythmus: Einmal im Jahr, meist im Herbst, erscheint eine neue Hauptversion, und jede Hauptversion erhält laut Projekt fünf Jahre lang Fehlerkorrekturen und Sicherheitsupdates. Die Version 18 erschien im September 2025 und brachte unter anderem ein neues Subsystem für asynchrone Ein- und Ausgabe sowie die Funktion uuidv7() für zeitlich sortierbare IDs. Welche Hauptversion aktuell ist und wie lange Ihre Version noch unterstützt wird, zeigt die Versionsübersicht auf postgresql.org.

Die Lizenz: Open Source ohne Haken

PostgreSQL steht unter der PostgreSQL License, einer kurzen, freizügigen Lizenz nach dem Vorbild der BSD- und MIT-Lizenzen. Sie erlaubt Nutzung, Änderung und Weitergabe, auch in kommerziellen Produkten, ohne dass eigener Code offengelegt werden muss. Es gibt keine kostenpflichtige „Enterprise Edition“ des Projekts selbst, in der wichtige Funktionen stecken.

Für Unternehmen ist das mehr als ein Detail. Mehrere bekannte Datenbanken und Infrastrukturprojekte haben in den vergangenen Jahren ihre Lizenzen verschärft, um Cloud-Anbieter auszubremsen; Nutzer mussten danach prüfen, ob ihr Einsatz noch erlaubt ist. Bei PostgreSQL ist ein solcher Schritt praktisch ausgeschlossen, weil kein Rechteinhaber einseitig neue Bedingungen setzen kann. Der Vergleich mit MySQL zeigt den Unterschied: MySQL gehört Oracle und ist unter der GPL oder einer kommerziellen Lizenz erhältlich. Das ist kein Nachteil an sich, bedeutet aber eine Abhängigkeit von einem Hersteller.

Die freizügige Lizenz hat eine weitere Folge: Zahlreiche Firmen bauen eigene Produkte auf PostgreSQL auf, von Cloud-Diensten wie Amazon Aurora, Azure Database for PostgreSQL oder Google AlloyDB bis zu spezialisierten Varianten für Zeitreihen oder verteilte Datenbanken. Wer die PostgreSQL-Schnittstelle beherrscht, kann zwischen diesen Angeboten wechseln.

Was PostgreSQL technisch auszeichnet

Im Kern ist PostgreSQL eine klassische relationale Datenbank mit Tabellen, SQL und Transaktionen. Es hält sich eng an den SQL-Standard und gilt als besonders strikt bei der Datenintegrität: Was gegen einen Datentyp oder eine Regel verstößt, lehnt die Datenbank ab, statt es stillschweigend anzupassen.

Transaktionen und MVCC

Transaktionen in PostgreSQL erfüllen die ACID-Eigenschaften: Eine Überweisung wird entweder vollständig gebucht oder gar nicht, auch wenn mitten im Vorgang der Server ausfällt. Für gleichzeitige Zugriffe nutzt PostgreSQL MVCC (Multiversion Concurrency Control). Jede Transaktion sieht einen konsistenten Schnappschuss der Daten. Ändert jemand eine Zeile, legt PostgreSQL eine neue Version an, statt die alte zu überschreiben. Lesende Zugriffe müssen deshalb nicht auf schreibende warten und umgekehrt.

Die Kehrseite: Alte Zeilenversionen bleiben zunächst liegen. Ein Hintergrundprozess namens Autovacuum räumt sie auf. Bei Tabellen mit sehr vielen Änderungen muss er gut eingestellt sein, sonst wachsen Tabellen und Indizes unnötig an. Das ist eine der wenigen Stellen, an denen PostgreSQL mehr Pflege braucht als manche Alternative.

Objektrelational: eigene Typen und Funktionen

PostgreSQL bezeichnet sich als objektrelationale Datenbank. Gemeint ist vor allem, dass Sie eigene Datentypen, Operatoren und Funktionen definieren können und die Datenbank sie wie eingebaute behandelt. Hinzu kommen Arrays, Bereichstypen (etwa für Buchungszeiträume, die sich nicht überschneiden dürfen) und Funktionen in mehreren Sprachen: neben SQL und der eingebauten Sprache PL/pgSQL auch Python oder Perl über Erweiterungen.

Die Tabellenvererbung, die frühere Darstellungen gern als Besonderheit nennen, spielt in der Praxis kaum noch eine Rolle. Für das Aufteilen großer Tabellen gibt es seit Version 10 die deklarative Partitionierung, die einfacher zu handhaben ist.

JSONB: Dokumente in der relationalen Datenbank

Viele Anwendungen speichern neben fest strukturierten Daten auch Angaben, deren Form sich häufig ändert: Produkteigenschaften im Webshop, Einstellungen von Benutzerkonten, Antworten externer Schnittstellen. Früher war das ein Argument für eine zusätzliche Dokumentdatenbank. PostgreSQL bietet dafür seit Version 9.4 den Datentyp JSONB, der JSON in einem binären, durchsuchbaren Format speichert.

CREATE TABLE produkte (
  produkt_id  INTEGER GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  name        TEXT NOT NULL,
  preis       NUMERIC(10, 2) NOT NULL,
  merkmale    JSONB NOT NULL DEFAULT '{}'
);

INSERT INTO produkte (name, preis, merkmale) VALUES
  ('Bürostuhl Basic', 249.00, '{"farbe": "schwarz", "armlehnen": true}'),
  ('Stehtisch Pro',   689.00, '{"farbe": "weiß", "hoehenverstellbar": true, "max_hoehe_cm": 125}');

-- GIN-Index beschleunigt Suchen innerhalb der JSON-Dokumente
CREATE INDEX produkte_merkmale_idx ON produkte USING GIN (merkmale);

-- Alle höhenverstellbaren Produkte
SELECT name, preis, merkmale ->> 'farbe' AS farbe
FROM produkte
WHERE merkmale @> '{"hoehenverstellbar": true}';

Der Operator @> prüft, ob das Dokument die angegebenen Schlüssel und Werte enthält, ->> liest einen einzelnen Wert als Text aus. So lassen sich feste Spalten für Name und Preis mit flexiblen Merkmalen kombinieren – in einer Transaktion und mit einem einzigen Backup.

Unsere Einschätzung: JSONB ist eine Ergänzung, kein Ersatz für ein Datenmodell. Was regelmäßig gefiltert, verknüpft oder durch Fremdschlüssel abgesichert werden soll, gehört in eigene Spalten. Für den variablen Rest ist JSONB ideal.

Erweiterungen: PostGIS, pgvector und mehr

Die größte Stärke von PostgreSQL ist sein Erweiterungssystem. Mit CREATE EXTENSION lassen sich neue Datentypen, Indexverfahren und Funktionen nachladen, die sich anfühlen, als wären sie Teil der Datenbank.

PostGIS für Geodaten

PostGIS macht PostgreSQL zu einem Geoinformationssystem. Es speichert Punkte, Linien und Flächen, rechnet Entfernungen auf der Erdkugel und beantwortet Fragen wie „Welche Filialen liegen im Umkreis von fünf Kilometern?“. Behörden, Energieversorger und Logistikunternehmen setzen PostGIS seit vielen Jahren ein.

CREATE EXTENSION IF NOT EXISTS postgis;

CREATE TABLE filialen (
  filiale_id  INTEGER GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  name        TEXT NOT NULL,
  standort    GEOGRAPHY(POINT, 4326) NOT NULL
);

-- Filialen im Umkreis von 5 km um den Kölner Dom (Länge, Breite)
SELECT name
FROM filialen
WHERE ST_DWithin(
  standort,
  ST_SetSRID(ST_MakePoint(6.958, 50.941), 4326)::geography,
  5000
);

pgvector für KI-Anwendungen

Mit dem Aufkommen großer Sprachmodelle ist eine weitere Erweiterung wichtig geworden: pgvector. Sie speichert Embeddings, also Zahlenvektoren, die die Bedeutung eines Textes abbilden, und findet zu einer Frage die inhaltlich ähnlichsten Textabschnitte. Das ist die Grundlage von RAG (Retrieval-Augmented Generation), bei der ein Sprachmodell vor der Antwort passende Dokumente aus dem Firmenwissen erhält.

CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE textabschnitte (
  abschnitt_id  BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  inhalt        TEXT NOT NULL,
  embedding     vector(1536) NOT NULL  -- Dimension hängt vom Embedding-Modell ab
);

-- HNSW-Index für schnelle Näherungssuche nach Kosinus-Abstand
CREATE INDEX ON textabschnitte USING hnsw (embedding vector_cosine_ops);

-- Die fünf ähnlichsten Abschnitte zu einem Anfragevektor ($1)
SELECT inhalt
FROM textabschnitte
ORDER BY embedding <=> $1
LIMIT 5;

Der Vorteil gegenüber einer separaten Vektordatenbank: Texte, Vektoren, Zugriffsrechte und Metadaten liegen in einem System und lassen sich in einer Abfrage kombinieren. Bei sehr großen Datenmengen mit vielen Millionen Vektoren können spezialisierte Systeme schneller sein. Für die meisten Unternehmensanwendungen reicht pgvector aus. Konkurrierende Ansätze wie die 2023 vorgestellte Erweiterung pg_embedding wurden zugunsten von pgvector wieder eingestellt.

Weitere verbreitete Erweiterungen sind pg_stat_statements zur Analyse langsamer Abfragen, pg_cron für zeitgesteuerte Jobs und TimescaleDB für Zeitreihen. Wie weit sich dieser Ansatz treiben lässt, bis PostgreSQL Cache, Suche und Job-Planung gleich mit übernimmt, beschreibt der Beitrag PostgreSQL als vollständige Backend-Lösung.

Betrieb: selbst hosten oder als Cloud-Dienst

PostgreSQL läuft auf Linux, Windows und macOS sowie in Containern. Für eine Entwicklungsumgebung genügt ein einziger Docker-Befehl mit dem offiziellen Image. Im produktiven Betrieb stellen sich dieselben Fragen wie bei jeder Datenbank: Backups und deren regelmäßige Wiederherstellungstests, Monitoring, Updates und Hochverfügbarkeit.

Alle großen Cloud-Anbieter bieten PostgreSQL als verwalteten Dienst an, bei dem der Anbieter Backups, Patches und Failover übernimmt. Daneben gibt es spezialisierte Anbieter wie Neon oder Supabase, die PostgreSQL mit zusätzlichen Funktionen für Entwickler verbinden. Bei personenbezogenen Daten sollten Sie auf den Speicherort in der EU und einen Vertrag zur Auftragsverarbeitung nach Art. 28 DSGVO achten.

Wer selbst betreibt, muss sich um Ausfallsicherheit kümmern. PostgreSQL bringt Streaming-Replikation mit, also das fortlaufende Übertragen aller Änderungen auf einen oder mehrere Standby-Server. Den automatischen Wechsel im Fehlerfall übernehmen zusätzliche Werkzeuge wie Patroni. Wie eine solche Architektur aussieht, erklärt der Infothek-Artikel PostgreSQL Hochverfügbarkeit und Failover.

Wo PostgreSQL an Grenzen stößt

So vielseitig PostgreSQL ist, es ist nicht für jeden Fall die beste Wahl.

• Viele gleichzeitige Verbindungen: PostgreSQL startet für jede Verbindung einen eigenen Serverprozess. Anwendungen mit Tausenden kurzlebiger Verbindungen, etwa serverlose Funktionen, brauchen deshalb einen Verbindungspool wie PgBouncer.
• Horizontale Skalierung beim Schreiben: Ein einzelner PostgreSQL-Server skaliert gut nach oben, das Verteilen von Schreiblast auf viele Rechner ist aber nicht eingebaut. Dafür gibt es Erweiterungen wie Citus oder verteilte SQL-Datenbanken, die die PostgreSQL-Schnittstelle nachbilden.
• Pflegeaufwand: Autovacuum, Speicherparameter und Indizes wollen verstanden sein. Die Standardeinstellungen sind bewusst vorsichtig gewählt und passen selten zu einem großen Produktivsystem.
• Bestehende Ökosysteme: Wer tief in Microsoft- oder Oracle-Werkzeuge eingebunden ist, etwa über Reporting-Dienste oder Stored Procedures mit herstellerspezifischer Syntax, zahlt für eine Migration einen spürbaren Preis.

Was das für Ihr Unternehmen bedeutet

PostgreSQL ist für die meisten neuen Anwendungen mit relationalen Daten eine solide Standardwahl. Die Datenbank ist ausgereift, frei von Lizenzrisiken, wird von allen großen Cloud-Anbietern unterstützt und deckt mit JSONB, PostGIS und pgvector Anforderungen ab, für die früher eigene Systeme nötig waren. Weniger Systeme bedeuten weniger Betriebsaufwand und weniger Stellen, an denen Daten auseinanderlaufen.

Überschätzt wird dagegen manchmal, wie viel eine einzelne Datenbank leisten sollte. Dass PostgreSQL eine Vektorsuche oder eine Job-Planung beherrscht, heißt nicht, dass jede Aufgabe dorthin gehört. Unsere Empfehlung: Beginnen Sie mit PostgreSQL als zentraler Datenbank und lagern Sie Aufgaben erst dann aus, wenn messbare Gründe dafür sprechen – Last, Datenmenge oder Anforderungen, die ein Spezialsystem nachweislich besser erfüllt.

Bei einer Migration von Oracle oder SQL Server lohnt sich eine nüchterne Bestandsaufnahme vorab: Wie viel Logik steckt in Stored Procedures, welche herstellerspezifischen Funktionen werden genutzt, welche Werkzeuge hängen an der Datenbank? Unterstützung bei Einführung, Migration, Optimierung und Schulung bieten wir auf unserer Seite PostgreSQL – Beratung, Coaching und Seminare an.

Häufige Fragen zu PostgreSQL

Ist PostgreSQL kostenlos, auch für kommerzielle Produkte?

Ja. Die PostgreSQL License erlaubt den Einsatz in kommerziellen Produkten ohne Lizenzgebühren und ohne Pflicht, eigenen Code offenzulegen. Kosten entstehen für Betrieb, Hosting und gegebenenfalls kommerziellen Support von Drittanbietern.

Ist PostgreSQL schwerer zu lernen als MySQL?

Für die tägliche Arbeit mit SQL kaum. Wer SQL beherrscht, findet sich in beiden Systemen schnell zurecht. PostgreSQL ist strikter bei Datentypen und bietet mehr Funktionen, was am Anfang ungewohnt sein kann. Anspruchsvoller ist bei beiden Systemen der Betrieb großer Installationen.

Eignet sich PostgreSQL auch für kleine Projekte?

Ja. PostgreSQL läuft auf einem kleinen virtuellen Server oder lokal im Container und braucht im Ruhezustand wenig Ressourcen. Für eine rein lokale Anwendung ohne Server, etwa eine Desktop-App, ist eine eingebettete Datenbank wie SQLite allerdings einfacher.

Braucht eine KI-Anwendung eine eigene Vektordatenbank?

In vielen Fällen nicht. Wenn Ihre Daten ohnehin in PostgreSQL liegen, ist pgvector der naheliegende Einstieg. Eine spezialisierte Vektordatenbank lohnt sich vor allem bei sehr großen Vektormengen oder besonderen Anforderungen an Suchgeschwindigkeit und Filterung, die pgvector in Lasttests nicht erfüllt.