PostgreSQL ist ein relationales Open-Source-Datenbanksystem mit über 35 Jahren Entwicklungsgeschichte. Es gilt als die ausgereifteste freie SQL-Datenbank und konkurriert in vielen Bereichen direkt mit kommerziellen Systemen wie Oracle oder SQL Server. In diesem Artikel klären wir, was Postgres genau ist, wie es entstanden ist, wofür es heute eingesetzt wird und wie es sich von anderen verbreiteten Datenbanken unterscheidet.

Kurzdefinition

PostgreSQL — kurz Postgres — ist ein objekt-relationales Datenbanksystem (ORDBMS), das den SQL-Standard konsequent unterstützt und um eine ganze Reihe an PostgreSQL-spezifischen Erweiterungen ergänzt. Dazu gehören:

  • ein reiches Typsystem (Arrays, Ranges, JSON/JSONB, UUID, Geometrie, eigene Composite-Typen),
  • transaktionale DDL (CREATE TABLE, ALTER TABLE etc. laufen innerhalb von Transaktionen),
  • ein offen erweiterbares Index-Framework (B-tree, Hash, GIN, GiST, BRIN, SP-GiST),
  • eine Extension-Schnittstelle, die Drittprojekte wie PostGIS, pgvector oder TimescaleDB ermöglicht,
  • volle ACID-Garantien und MVCC-basiertes Concurrency Control.

Postgres wird unter der PostgreSQL License veröffentlicht — einer permissiven Lizenz im Stil von BSD/MIT. Du darfst es kommerziell einsetzen, modifizieren und weitervertreiben, ohne Lizenzgebühren zu zahlen.

Geschichte in drei Sätzen

Das Projekt begann 1986 an der UC Berkeley unter Michael Stonebraker als Nachfolger des damaligen Ingres und hieß zunächst nur POSTGRES. 1995 wurde der proprietäre Query-Parser durch SQL ersetzt — daraus wurde Postgres95, kurz darauf PostgreSQL. Seit 1996 ist die Entwicklung in den Händen einer weltweit verteilten Community (PostgreSQL Global Development Group), die jedes Jahr im Spätsommer/Herbst ein neues Major-Release veröffentlicht.

Wofür wird Postgres heute eingesetzt?

Postgres ist eine Universal-Datenbank — die meisten Workloads, die nach “relational” rufen, laufen darauf gut. Typische Einsatzfelder:

  • Web-Anwendungen: das klassische Backend für Web-Apps, von kleinen Side-Projects bis zu großen SaaS-Plattformen. Die meisten Web-Frameworks (Rails, Django, Laravel, Spring, NestJS, Phoenix, …) bringen Postgres-Adapter mit.
  • Analytics & Reporting: durch Window Functions, CTEs, Partitionierung und Extensions wie cstore_fdw oder TimescaleDB auch für Reporting-Lasten geeignet.
  • Geo-Anwendungen: zusammen mit PostGIS ist Postgres die de-facto-Open-Source-Geo-Datenbank.
  • Data Lakehouse / OLAP: durch Foreign Data Wrappers und Tools wie Citus oder Greenplum (Postgres-Fork) auch im verteilten Bereich.
  • Vektor-Suche / AI-Workloads: mit pgvector lassen sich Embeddings direkt neben den Anwendungsdaten speichern und durchsuchen.
  • Embedded / Single-Server-Setups: dank kleiner Footprint-Konfigurationen auch für Edge-Geräte oder Self-Hosting interessant.

Abgrenzung zu anderen Datenbanken

SystemArtTypische StärkeTypische Lücke ggü. Postgres
MySQL / MariaDBRDBMSSehr verbreitet, einfache ReplikationSchwächeres SQL (CTEs, Window Functions später hinzugefügt), historisch laxere Defaults
SQLiteEmbeddedIn-Process, null Setup, super für Tests/MobileKein Server, keine Concurrency für Schreiblasten, eingeschränkte Typen
Oracle / SQL ServerRDBMS (kommerziell)Enterprise-Features, kommerzieller SupportLizenzkosten, geringere Portabilität
MongoDBDocumentFlexible Schemas, JSON-natives ModellKeine echten Joins, eingeschränkte Konsistenz; Postgres deckt JSON-Use-Cases mit JSONB ab
RedisKey-Value / CacheSehr schnell, In-MemoryAndere Aufgabe — kein Ersatz für relationale Persistenz

In der Praxis ist die häufigste reale Wahl Postgres vs. MySQL/MariaDB. Wenn deine Anwendung komplexere Queries, JSON-Felder, geographische Daten, Volltextsuche oder Window Functions braucht, ist Postgres meist die bessere Wahl. Wenn du im Kontext einer existierenden MySQL-Infrastruktur arbeitest oder ein Tool ausschließlich MySQL spricht, bist du dort gut aufgehoben.

Release-Modell

Die PostgreSQL Global Development Group bringt einmal pro Jahr ein neues Major-Release, üblicherweise im September oder Oktober. Aktuell verbreitet:

  • PostgreSQL 18 (stabile Hauptlinie)
  • PostgreSQL 17, 16, 15, 14, 13 (jeweils noch unterstützt)

Jede Major-Version wird fünf Jahre lang mit Bugfixes und Sicherheitsupdates versorgt (Minor-Releases). Danach läuft sie aus — alte Major-Versionen ohne Support sollten in Produktion nicht mehr betrieben werden, da Sicherheitslücken nicht mehr gepatcht werden.

Major-Versionen sind beim Major-Upgrade mit Migrationsschritten verbunden (pg_upgrade oder Dump/Restore). Minor-Releases (z. B. 18.1 → 18.2) sind hingegen drop-in: Binary austauschen, Server neu starten, fertig.

Interessantes

Der Name spricht sich „Post-Gres-Q-L“.

Offiziell ja — die FAQ stellt das ausdrücklich klar. In der Praxis sagt fast niemand das Q-L mit, sondern einfach „Postgres“. Beide Schreibweisen sind in der Doku akzeptiert.

Postgres ist objekt-relational, nicht „nur“ relational.

Du kannst eigene Datentypen definieren, Funktionen in mehreren Sprachen schreiben (PL/pgSQL, PL/Python, PL/Perl, …) und Tabellen-Vererbung nutzen. Diese ORDBMS-Wurzeln aus dem POSTGRES-Projekt sind ein Grund, warum Erweiterungen wie PostGIS überhaupt möglich sind — man hängt sich am Typsystem an, statt einen Fork zu pflegen.

Es gibt keine „Enterprise Edition“.

Anders als MySQL (Oracle vs. Community) oder SQL Server (Express vs. Enterprise) gibt es eine PostgreSQL. Anbieter wie EnterpriseDB, Crunchy Data oder Cybertec bieten kommerziellen Support oder Distributionen mit zusätzlichen Tools — der Datenbank-Kern ist aber für alle derselbe.

Die Lizenz erlaubt kommerziellen Einsatz ohne Auflagen.

Die PostgreSQL License ist eine MIT-/BSD-ähnliche Lizenz. Du darfst Postgres in proprietäre Produkte einbetten, weiterverkaufen oder forken — solange der Lizenztext erhalten bleibt. Es gibt keine Klauseln zu „Network Use“ wie bei AGPL.

Cloud-Postgres ist überall verfügbar.

AWS RDS / Aurora, Google Cloud SQL / AlloyDB, Azure Database for PostgreSQL, sowie spezialisierte Anbieter wie Neon, Supabase, Crunchy Bridge oder Render bieten Managed Postgres an. In den meisten Fällen kannst du dasselbe SQL und denselben Anwendungs-Code lokal und in der Cloud verwenden — kleine Unterschiede gibt es bei Extensions und Superuser-Zugriff.

Weiterführende Ressourcen

Externe Quellen

/ Weiter

Zurück zu Grundlagen

Zur Übersicht