PostgreSQL im Vergleich: Das kann die freie Datenbank wirklich

TL;DR — PostgreSQL ist quelloffen, kostenlos und steht bei den SQL-Funktionen auf Augenhöhe mit teuren Schwergewichten wie Oracle, SQL Server oder Db2. Dieser Vergleich stellt die wichtigsten relationalen Datenbanken nebeneinander — mit klaren Tabellen zu SQL-Befehlen, Transaktionen, Lizenzen und Limits. So siehst du auf einen Blick, wer was kann.

PostgreSQL kostet keine Lizenzgebühr — nicht heute, nicht bei wachsendem Datenvolumen, nicht in der Cloud. Du zahlst nur, wenn du willst: für Support oder Hosting.

Warum dieser Vergleich? Die Ausgangslage

Wer eine Datenbank auswählt, vergleicht selten Äpfel mit Äpfeln. Ein quelloffenes System wie PostgreSQL steht neben kommerziellen Schwergewichten, die seit den 1980er-Jahren Rechenzentren füllen. Die Frage ist nicht "Welche ist die beste?", sondern "Welche passt zu meinem Problem — und was muss ich dafür können?".

Genau hier setzt dieser Artikel an. Statt Marketing-Versprechen zeigen die folgenden Tabellen, welches System welchen SQL-Befehl beherrscht, wie es Transaktionen handhabt und wo seine technischen Grenzen liegen. Die Kandidaten:

• PostgreSQL — quelloffener Allrounder, objektrelational
• Microsoft SQL Server — Microsofts Enterprise-Datenbank
• Microsoft Access — die Desktop-/Datei-Datenbank aus dem Office-Paket (ACE/Jet-Engine)
• Oracle Database — der kommerzielle Platzhirsch
• IBM Db2 — Großrechner- und Enterprise-Tradition, in drei Plattform-Varianten: LUW (Linux/Unix/Windows), z/OS (Mainframe) und i (IBM i)
• IBM Informix — robuste OLTP-Datenbank (Entwicklung heute bei HCL)
• Sybase (SAP) — drei unterschiedliche Engines: ASE für Transaktionen, IQ für spaltenorientierte Analysen, SQL Anywhere für eingebettete/mobile Szenarien
• MySQL / MariaDB — die Web-Datenbanken schlechthin
• SQLite — die meistverbreitete Datenbank der Welt (eingebettet)
• Firebird — quelloffener Nachfahre von Borland InterBase
• SAP HANA — spaltenorientierte In-Memory-Datenbank

Weil sich Db2 und Sybase in mehrere Varianten gabeln, führen die Tabellen unten 15 Zeilen. Das ist Absicht: "Sybase kann keine Fensterfunktionen" stimmt nur für ASE — IQ und SQL Anywhere können es sehr wohl.

Microsoft Access fällt dabei bewusst aus dem Rahmen: Es ist eine Desktop-/Datei-Datenbank, kein Server. Die vielen ❌ in seiner Zeile sind keine Schwäche, sondern Ausdruck eines anderen Einsatzzwecks — Einzelplatz, Formulare, kleine Büro-Tools.

Legende für alle Vergleichstabellen: ✔️ = ja / voll unterstützt  ·  🟡 = teilweise (über Umweg, Erweiterung oder abweichende Syntax)  ·  ❌ = nein / nicht unterstützt.

Steckbrief: Wer ist wer?

Lizenz und Kosten: der erste große Unterschied

Der deutlichste Trennstrich verläuft nicht zwischen den Features, sondern zwischen den Rechnungen. Vier der Systeme sind komplett kostenlos — die kommerziellen kosten Lizenzgebühren, die bei Oracle, Db2 z/OS oder HANA schnell fünfstellig werden.

Hinweis: Tabelle Stand Mai 2026. Lizenz- und Editionskonditionen der kommerziellen Anbieter ändern sich regelmäßig — vor einer Kaufentscheidung beim jeweiligen Hersteller prüfen.

Das Herzstück: SQL-Befehle im direkten Vergleich

Hier wird es konkret. Die folgenden drei Matrizen zeigen, welcher SQL-Befehl in welchem System funktioniert (Legende: ✔️ ja · 🟡 teilweise · ❌ nein).

Ein Wort zu den Varianten: Bei den reinen SQL-Features decken sich die drei Db2-Plattformen (LUW, z/OS, i) weitgehend — ihre Unterschiede liegen vor allem bei Limits und Betrieb (siehe weiter unten). Bei Sybase dagegen trennen Welten: SAP ASE beherrscht weder CTEs noch Fensterfunktionen, SAP IQ und SQL Anywhere dagegen schon.

Matrix 1 — Abfragen und Joins

Lesehilfe: LATERAL bildet der SQL Server über CROSS APPLY / OUTER APPLY ab. Bei den Web-Datenbanken klafft eine Lücke: MySQL kann LATERAL (ab 8.0.14), MariaDB nicht — dafür fehlt beiden der FULL OUTER JOIN (er muss per UNION nachgebaut werden). Der große Verlierer ist SAP ASE: weder CTEs noch Fensterfunktionen. Genau hier zeigt sich, warum die Sybase-Aufschlüsselung wichtig ist — SAP IQ und SQL Anywhere beherrschen beides. Microsoft Access kennt keine dieser Konstrukte — es ist eine Desktop-Datenbank, kein SQL-Server. SQLite kann FULL OUTER JOIN erst seit Version 3.39.

Matrix 2 — Schreiben und Mengenoperationen

Lesehilfe: PostgreSQL kennt MERGE erst seit Version 15 (2022) — vorher löste man das über INSERT ... ON CONFLICT. Genau dieses elegante UPSERT als Ein-Befehl-Lösung haben PostgreSQL, MySQL/MariaDB, SQLite, Firebird, SQL Anywhere (INSERT ... ON EXISTING) und HANA; die Übrigen brauchen dafür ein MERGE-Statement (daher 🟡). RETURNING (die geänderten Zeilen direkt zurückgeben) ist eine PostgreSQL-Stärke; SQL Server macht das über OUTPUT, die Db2-Plattformen über SELECT FROM FINAL TABLE (daher 🟡). Bei den Web-Datenbanken hat nur MariaDB (ab 10.5) RETURNING, MySQL nicht. Firebird fehlen INTERSECT/EXCEPT und TRUNCATE komplett; SQLite hat kein TRUNCATE, optimiert aber ein DELETE ohne WHERE.

Matrix 3 — Aggregation, Daten und Objekte

Lesehilfe: Die Spalte ARRAY_AGG ist lehrreich: Nur PostgreSQL hat einen echten Array-Datentyp und kann Werte als Array zusammenfassen (✔️). Alle anderen bieten nur eine String-Variante (STRING_AGG, LISTAGG, GROUP_CONCAT oder LIST — daher 🟡). Bei GROUPING SETS können MySQL/MariaDB nur WITH ROLLUP, nicht die volle ANSI-Syntax. Materialisierte Sichten trennen "groß" von "klein": PostgreSQL, Oracle, die Db2-Plattformen, SAP IQ/SQL Anywhere und HANA haben sie; MySQL/MariaDB, SQLite und Firebird nicht. SQL Server bietet stattdessen indizierte Sichten, SAP ASE "Precomputed Result Sets" (daher 🟡). Access' berechnete Felder (ab Version 2010) sind nur ein schwacher Ersatz für generierte Spalten.

Wichtig: Diese Matrizen bilden den Stand Mai 2026 ab und sind gegen die Hersteller-Doku geprüft. Einzelne Rand-Features hängen an Edition und Version — für eine produktive Entscheidung immer die aktuelle Doku des Anbieters konsultieren.

Transaktionen und Nebenläufigkeit

Wenn viele Nutzer gleichzeitig schreiben und lesen, entscheidet das Transaktionsmodell über Korrektheit und Tempo. Das zentrale Stichwort heißt MVCC (Multiversion Concurrency Control): Die Datenbank hält von einer geänderten Zeile mehrere Versionen vor — Leser sehen die alte, der Schreiber arbeitet an der neuen. Niemand wartet auf eine Lesesperre.

Auffällig: PostgreSQL, Oracle und MySQL setzen voll auf MVCC. SQL Server und SAP ASE arbeiten standardmäßig sperrbasiert und schalten MVCC nur per Snapshot-Isolation hinzu. MySQL/MariaDB fällt mit Repeatable Read als Standard aus der Reihe — die meisten anderen starten bei Read Committed. Microsoft Access kennt keine echten Isolationsstufen, sondern nur Datei- und Satzsperren.

Technische Attribute: Indizes und Limits

Index-Typen (Auswahl)

Der richtige Index entscheidet über die Performance. PostgreSQL hat hier die breiteste Palette; die kommerziellen Systeme punkten oft beim spaltenorientierten Columnstore für Analysen — bei SAP IQ und HANA ist er sogar das Kernprinzip.

Größen-Limits

Hier zeigen sich die Unterschiede zwischen den Db2-Plattformen am deutlichsten: Db2 for z/OS deckelt bei 750 Spalten pro Tabelle, Db2 LUW bei 1.012, Db2 for i erlaubt deutlich mehr. Und Microsoft Access markiert mit seiner 2-GB-Grenze das untere Ende.

Hinweis: Limits sind versions-, editions- und konfigurationsabhängig (Blockgröße, Speicher-Engine, Partitionierung). Die Werte zeigen die Größenordnung, keine harten Garantien.

Erweiterbarkeit: PostgreSQLs heimliche Superkraft

Was PostgreSQL von den meisten Konkurrenten abhebt, ist die Erweiterbarkeit. Über das Extension-System docken zusätzliche Fähigkeiten an den Kern an — von Geodaten bis Künstliche Intelligenz, ohne die Datenbank zu wechseln.

Und der Funktionsumfang wächst stetig: PostgreSQL 18 (September 2025) brachte unter anderem asynchrones I/O für mehr Durchsatz, virtuelle generierte Spalten, ein erweitertes RETURNING mit Zugriff auf OLD- und NEW-Werte sowie eingebauten OAuth-/OIDC-Login. PostgreSQL folgt dabei einem festen Jahres-Rhythmus — die nächste Hauptversion 19 wird für Herbst 2026 erwartet.

Volltext, Dokumente und Künstliche Intelligenz

Moderne Anwendungen brauchen mehr als Tabellen. Volltextsuche, JSON-Dokumente und — seit dem KI-Boom — Vektor-Suche für Embeddings sind gefragt. Hier zeigt sich, wie zukunftsfähig ein System ist.

Sicherheit: Wer schützt die Daten wie?

Zugriffsschutz auf Zeilenebene, Verschlüsselung und Auditing sind in regulierten Umgebungen Pflicht. Die kommerziellen Schwergewichte sind hier traditionell stark — PostgreSQL holt mit Bordmitteln und Erweiterungen auf.

Hochverfügbarkeit und Skalierung

Für den Dauerbetrieb zählt, wie ein System ausfällt — und ob überhaupt. Hier spielt der Mainframe seine Tradition aus: Db2 for z/OS skaliert über Parallel Sysplex Data Sharing wie kaum ein anderes System.

Ein ehrlicher Punkt für PostgreSQL: Automatischen Failover bringt der Kern nicht mit — den ergänzt man über bewährte Werkzeuge wie Patroni. Oracle (RAC), Db2 z/OS und SAP HANA spielen beim eingebauten Cluster-Komfort ihre kommerzielle Stärke aus.

Aus der Praxis: PostgreSQL im Produktivbetrieb

Theorie ist das eine. Wie trägt PostgreSQL eine echte Anwendung? Ein Beispiel aus unserem eigenen Haus ist die Finanzdaten-Plattform Inside-Filings: Sie läuft vollständig auf PostgreSQL und nutzt dabei genau die Features aus den Tabellen oben.

• Saubere Trennung über Schemas — Marktdaten, Broker-Anbindung, Benutzerverwaltung, Content-Management und mehr liegen in getrennten Namespaces (market, broker, auth, cms, core …) in einer Datenbank.
• JSONB für flexible Daten — Signal-Schnappschüsse landen als JSON-Dokument in der relationalen Welt und bleiben trotzdem abfragbar.
• Materialisierte Sichten — vorberechnete Aggregationen liefern Reports in Millisekunden, statt bei jedem Aufruf neu zu rechnen.
• Geplante Jobs in der Datenbank — wiederkehrende Auswertungen laufen über pg_cron, direkt dort, wo die Daten liegen.

Das Spannende: All das funktioniert ohne eine einzige Lizenzgebühr — und mit SQL, das man lernen kann.

Migration nach PostgreSQL — ein Ausblick

Viele Teams steigen heute von Oracle, SQL Server oder MySQL auf PostgreSQL um — meist aus Kostengründen, oft wegen der Flexibilität. Werkzeuge wie ora2pg oder pgloader nehmen einem dabei viel Handarbeit ab.

Ganz ohne Aufwand geht es trotzdem nicht: Gespeicherte Prozeduren in PL/SQL oder T-SQL müssen nach PL/pgSQL übersetzt werden, Datentypen weichen ab, und manche Eigenheiten (etwa Oracles leerer String gleich NULL) verlangen Sorgfalt. Wer die Stolpersteine kennt, migriert planbar statt mit bösen Überraschungen.

Genau solche Migrationspfade — von der Analyse über die Datentyp-Abbildung bis zum Umschreiben der Prozeduren — gehen wir in unseren Datenbank-Seminaren Schritt für Schritt an einem echten Projekt durch.

Fazit: Welche Datenbank für wen?

Es gibt keine "beste" Datenbank — nur die passende für den Zweck. Als Orientierung:

• PostgreSQL — die erste Wahl, wenn du maximalen SQL-Funktionsumfang, Erweiterbarkeit und null Lizenzkosten willst. Der ideale Allrounder, auch zum Lernen.
• MySQL / MariaDB — der schnelle Einstieg für Web-Projekte; riesige Verbreitung, einfache Bedienung, etwas schlanker im Funktionsumfang.
• SQLite — wann immer eine eingebettete, dateibasierte Datenbank reicht: Apps, Tests, kleine Tools. Kein Server nötig.
• Microsoft Access — für Einzelplatz-Lösungen, Formulare und kleine Büro-Anwendungen mit grafischer Oberfläche. Kein Server, 2-GB-Grenze; zum Lernen von echtem SQL nur bedingt geeignet.
• Oracle / Db2 / SAP HANA — wenn Enterprise-Cluster, In-Memory-Analysen oder bestehende Verträge den Ausschlag geben — und das Budget vorhanden ist.
• SQL Server — naheliegend in Microsoft-Umgebungen mit .NET und Azure.
• Sybase (ASE/IQ/SQL Anywhere), Informix, Firebird — meist dort, wo sie historisch gewachsen sind; für Neuprojekte selten erste Wahl.

Eines zeigt der Vergleich klar: PostgreSQL muss sich vor keinem der teuren Schwergewichte verstecken. Wer SQL einmal sauber beherrscht, trifft solche Entscheidungen souverän — und genau dafür sind unsere Seminare gemacht.

Häufige Fragen (FAQ)

Ist PostgreSQL wirklich kostenlos — auch für kommerzielle Projekte?

Ja. PostgreSQL steht unter der freien PostgreSQL-Lizenz (BSD-artig) und darf ohne Lizenzgebühren auch kommerziell, in Produkten und in der Cloud eingesetzt werden. Kosten entstehen nur für optionalen kommerziellen Support oder Managed-Hosting.

PostgreSQL oder MySQL — was ist besser?

Beide sind quelloffen und kostenlos. MySQL/MariaDB punktet mit einfachem Einstieg und großer Web-Verbreitung. PostgreSQL bietet den größeren SQL-Funktionsumfang: echte Arrays, MERGE, FULL OUTER JOIN, materialisierte Sichten, mehr Index-Typen und Erweiterungen wie PostGIS oder pgvector. Für anspruchsvolle Datenmodelle ist PostgreSQL meist die flexiblere Wahl.

Kann PostgreSQL Oracle ersetzen?

Für einen Großteil der Anwendungen ja. PostgreSQL deckt fast alle SQL-Features von Oracle ab, inklusive Fensterfunktionen, MERGE und materialisierter Sichten. Spezialitäten wie Oracle RAC oder bestimmte PL/SQL-Pakete erfordern beim Umstieg Mehraufwand — eine pauschale Eins-zu-eins-Migration gibt es nicht.

Was bedeutet MVCC und warum ist es wichtig?

MVCC steht für Multiversion Concurrency Control. Die Datenbank hält von geänderten Zeilen mehrere Versionen vor, sodass Lesezugriffe nicht von Schreibzugriffen blockiert werden. Das erlaubt hohe Parallelität ohne Lesesperren. PostgreSQL, Oracle, MySQL (InnoDB) und weitere nutzen MVCC.

Was ist der Unterschied zwischen MySQL und MariaDB?

MariaDB ist eine 2009 entstandene Abspaltung von MySQL, gegründet von den ursprünglichen MySQL-Entwicklern. Die Systeme sind weitgehend kompatibel, driften aber auseinander: MariaDB hat z. B. die RETURNING-Klausel, MySQL dafür LATERAL-Joins. MariaDB ist komplett unter GPL frei, MySQL wird von Oracle in einer freien Community- und einer kostenpflichtigen Enterprise-Variante angeboten.

Was ist der Unterschied zwischen SAP ASE, SAP IQ und SQL Anywhere?

Alle drei stammen aus dem früheren Sybase-Portfolio und gehören heute zu SAP. SAP ASE (Adaptive Server Enterprise) ist die klassische Transaktionsdatenbank, kann aber weder CTEs noch Fensterfunktionen. SAP IQ ist eine spaltenorientierte Analytics-Datenbank und beherrscht beides. SQL Anywhere ist für eingebettete und mobile Szenarien gedacht und ebenfalls funktionsreich. Wer "Sybase" sagt, muss also dazusagen, welches Produkt gemeint ist.

Worin unterscheiden sich Db2 LUW, Db2 for z/OS und Db2 for i?

Es sind drei Db2-Plattformen mit eigenen SQL-Dialekten. Db2 LUW läuft auf Linux, Unix und Windows, Db2 for z/OS auf dem IBM-Mainframe und Db2 for i auf IBM i (früher AS/400). Bei den SQL-Features decken sie sich weitgehend (CTE, Fensterfunktionen, MERGE). Die Unterschiede liegen vor allem bei Limits, Betrieb und Skalierung — etwa Parallel Sysplex Data Sharing unter z/OS.

Ist Microsoft Access eine vollwertige Datenbank?

Microsoft Access ist eine Desktop-/Datei-Datenbank mit der ACE-Engine (früher Jet), kein Client/Server-System. Sie eignet sich für Einzelplatz-Anwendungen, Formulare und kleine Büro-Tools, stößt aber bei der 2-GB-Dateigrenze, ohne CTEs, Fensterfunktionen oder echte Mehrbenutzer-Transaktionen schnell an Grenzen. Für mehrere gleichzeitige Nutzer oder wachsende Datenmengen ist ein Server wie PostgreSQL oder SQL Server die bessere Wahl.

Wann ist SQLite die richtige Wahl?

SQLite ist eine eingebettete, dateibasierte Datenbank ohne Server-Prozess. Ideal für mobile Apps, Desktop-Programme, Tests und kleine bis mittlere Datenmengen mit überwiegend lesendem Zugriff. Für viele gleichzeitige Schreibzugriffe oder Benutzerverwaltung mit Rollen ist eine Client/Server-Datenbank wie PostgreSQL besser geeignet.

Unterstützt PostgreSQL JSON wie eine NoSQL-Datenbank?

Ja. PostgreSQL speichert JSON-Dokumente im binären JSONB-Format, kann darin per Index suchen und einzelne Felder abfragen. Damit lassen sich relationale und dokumentenorientierte Ansätze in einer Datenbank kombinieren — ohne separates NoSQL-System.

Welche Datenbank eignet sich am besten zum Lernen von SQL?

PostgreSQL und SQLite eignen sich beide gut: SQLite für den schnellen Einstieg ohne Installation, PostgreSQL, um den vollen SQL-Standard mit Fensterfunktionen, CTEs und Transaktionen praxisnah zu lernen. Wer SQL einmal sauber auf PostgreSQL beherrscht, findet sich in allen anderen Systemen schnell zurecht.

So wirst du vom Anwender zum Profi

Vom ersten SELECT bis zum performanten Produktivsystem ist es ein Weg in klaren Etappen — genau so ist unser Seminar-Curriculum aufgebaut:

Du brauchst keine teure Lizenz und keinen Vorab-Server, um SQL zu lernen — nur den richtigen Einstieg. PostgreSQL und SQLite sind kostenlos, in Minuten installiert und begleiten dich vom ersten Tag bis ins Produktivsystem.