SQL Server vs. PostgreSQL — Vor- und Nachteile für den Umstieg

SQL Server oder PostgreSQL — die Frage ist selten „Welche Datenbank ist besser?“, sondern „Welche passt zu Budget, Team und Plattform?“. Wer die beiden Fragen verwechselt, migriert aus den falschen Gründen und merkt es erst, wenn die Lizenzrechnung zwar schrumpft, die Betriebskosten aber wachsen.

Kurzüberblick:

• Lizenzkosten und Gesamtbetriebskosten (TCO = Total Cost of Ownership): wo PostgreSQL wirklich spart und wo die Kosten nur die Spalte wechseln
• Features und Reife: was beim Umstieg fehlt (BI-Stack, Agent) und was dazukommt (Extensions, jsonb)
• Developer-Experience: T-SQL gegen PL/pgSQL, SSMS gegen pgAdmin und DBeaver
• Betrieb, Plattform und Lock-in: Cloud-Optionen, Hochverfügbarkeit, Personal
• Wann SQL Server die richtige Wahl bleibt — der Artikel ist kein Werbeblock
• Eine Entscheidungs-Matrix, die die eigene Konstellation einordnet

Voraussetzung: SQL-Server-Praxiserfahrung genügt. PostgreSQL-Begriffe wie MVCC oder Extensions werden beim ersten Auftreten kurz erklärt. Alle Lizenz- und Feature-Aussagen beziehen sich auf SQL Server 2022 und PostgreSQL 17 (Stand: Juli 2026). Beide Punkte ändern sich mit jeder Major-Version, das Prüfdatum gehört zu jeder Abwägung dazu.

Inhalt

• Lizenzkosten und TCO
• Features und Reife
• Developer-Experience und Ökosystem
• Betrieb, Plattform und Lock-in
• Wann SQL Server die richtige Wahl bleibt
• Entscheidungs-Matrix: SQL Server oder PostgreSQL?
• FAQ
• Verwandte Artikel

Lizenzkosten und TCO

Der Kostenvergleich ist der häufigste Auslöser für die Umstiegs-Frage und zugleich die Stelle, an der am meisten schöngerechnet wird. Deshalb lohnt sich zuerst ein nüchterner Blick darauf, wie die beiden Kostenmodelle aufgebaut sind.

SQL Server lizenziert nach Editionen und Cores. Die Express-Edition ist kostenlos und für kleine Anwendungen eine völlig legitime Wahl. Sie ist allerdings begrenzt, unter anderem auf rund 10 GB pro Datenbank. Standard und Enterprise werden pro CPU-Core lizenziert, verkauft in 2-Core-Packs. Dabei gilt eine Mindestabnahme von vier Core-Lizenzen pro physischem Prozessor beziehungsweise pro VM, auch wenn die Maschine weniger Cores hat. Eine VM mit zwei Cores braucht also trotzdem zwei 2-Core-Packs, und die überschüssigen Lizenzen kleben ungenutzt an dieser Maschine. In der Praxis dimensioniert man SQL-Server-Instanzen deshalb selten kleiner als vier Cores, selbst wenn der Workload es hergäbe: Die Lizenz redet beim Sizing mit. Die Standard-Edition lässt sich alternativ über eine Server-Lizenz plus Client Access Licenses (CALs) abdecken.

Die Listenpreise liegen pro 2-Core-Pack im vierstelligen (Standard) bis fünfstelligen Bereich (Enterprise), die jeweils aktuellen Beträge führt Microsofts Preisübersicht. Dazu kommt üblicherweise Software Assurance, die erst Rechte wie passive Failover-Instanzen oder License Mobility in die Cloud freischaltet. Wer Hochverfügbarkeit, mehrere Umgebungen und wachsende Kerne zusammenrechnet, landet bei Summen, die in Budgetrunden auffallen. Genau dort entsteht der Evaluierungs-Druck.

PostgreSQL kostet keine Lizenz, aber „kostenlos“ heißt nicht „kostenfrei im Betrieb“. Die PostgreSQL-Lizenz (BSD-ähnlich) erlaubt uneingeschränkten produktiven Einsatz. Die Kosten wechseln jedoch die Spalte. Wenn der Betrieb Rückendeckung braucht, kommt ein Support-Vertrag bei Anbietern wie EDB, Crunchy Data oder Cybertec dazu. Wenn kein eigenes Betriebs-Team da ist, übernimmt Managed-Hosting wie Amazon RDS/Aurora, Azure Database for PostgreSQL oder Google Cloud SQL diese Rolle. Und einmalig fällt der Migrations-Aufwand selbst an: Schema, Daten, Prozeduren und Tests. Bei einer Anwendung mit hunderten T-SQL-Prozeduren kann dieser Posten die Lizenzersparnis mehrerer Jahre auffressen.

Wo PostgreSQL wirklich spart: Die größte Ersparnis liegt bei Enterprise-Features, die dort schlicht keine Editions-Frage sind. Partitionierung, Verschlüsselung, Kompression, parallele Abfragen, unbegrenzte Cores: In PostgreSQL gibt es keine Editionen, der volle Funktionsumfang steckt in der einen Community-Version. Ein zweiter Spar-Hebel liegt in der Zahl der Umgebungen. Entwicklungs-, Test-, Staging- und CI-Instanzen kosten keine Lizenz, was gerade containerisierte Workflows spürbar entlastet. Und weil kein Core-Zähler mitläuft, darf eine Instanz auch klein sein. Das Sizing folgt dem Workload, nicht der Lizenz.

Features und Reife

Beide Systeme sind ausgereifte, jahrzehntelang gehärtete Datenbanken. Die Unterschiede liegen nicht in der Zuverlässigkeit, sondern im Umfeld. Deshalb folgt hier eine ehrliche Bestandsaufnahme in beide Richtungen:

Was beim Umstieg wegfällt (SQL-Server-Stärken):

• Der integrierte BI-Stack. SSIS (ETL), SSRS (Reporting) und SSAS (Analysis) sind in der Lizenz enthalten und tief integriert. PostgreSQL hat kein Pendant „in der Box“. Der Ersatz besteht aus eigenen ETL-Strecken (siehe die Tooling-Frage im verwandten ETL-vs.-ELT-Artikel), Reporting-Tools wie Power BI oder Metabase und separaten Analytik-Lösungen. Wer den BI-Stack produktiv nutzt, migriert nicht eine Datenbank, sondern drei Systeme.
• SQL Server Agent. Der eingebaute Scheduler für Jobs, Alerts und Operatoren fehlt in PostgreSQL. Üblich sind dort die Extension pg_cron oder ein externer Scheduler. Das ist funktional lösbar, bleibt aber ein eigener Umbau-Posten in der Migrations-Planung.
• Query Store und In-Memory OLTP. Der Query Store als eingebauter Plan-Verlauf ist komfortabler als sein PostgreSQL-Pendant: die Extension pg_stat_statements liefert aggregierte Statistiken, aber keine Plan-Historie. Werkzeuge wie auto_explain und pg_store_plans oder Dienste wie pganalyze verkleinern den Abstand, den Komfort des Query Store erreichen sie aber nicht ganz. In-Memory OLTP für Hochfrequenz-Workloads hat in PostgreSQL kein direktes Gegenstück.
• AlwaysOn Availability Groups. Ausgereifte, GUI-geführte Hochverfügbarkeit. PostgreSQL erreicht Vergleichbares mit Streaming-Replikation und Werkzeugen wie Patroni, das in vielen Unternehmen Produktionsstandard ist. Kubernetes-Operatoren und Managed-Angebote nehmen dem Selbstbetrieb inzwischen viel ab. Wer klassisch auf eigenen Servern aufbaut, leistet trotzdem mehr Handarbeit als mit dem SQL-Server-Assistenten.

Was beim Umstieg dazukommt (PostgreSQL-Stärken):

• Extensions als Ökosystem. PostGIS für Geodaten, TimescaleDB für Zeitreihen, Fremdzugriffe über Foreign Data Wrapper: Erweiterungen sind in PostgreSQL ein Architektur-Prinzip und kein nachträglicher Anbau.
• jsonb und reichere Typen. PostgreSQL speichert JSON in einem nativen, direkt indexierbaren jsonb-Typ. SQL Server kennt seit 2016 ebenfalls JSON-Funktionen wie OPENJSON und JSON_VALUE, legt die Daten aber als Text in nvarchar-Spalten ab und indexiert über berechnete Spalten statt direkt. Dazu kommen Arrays, Range-Typen und echte Enums: Datenmodelle, die in SQL Server auf Hilfstabellen ausweichen müssen, haben in PostgreSQL native Typen.
• Index-Vielfalt. Expression-Indizes (Index auf einem Ausdruck statt einer Spalte), GIN/GiST für JSON und Volltext, BRIN für große append-only-Tabellen. SQL Server kennt gefilterte Indizes, deckt aber nicht dieselbe Breite ab.
• Transaktionale DDL als Alltag. CREATE/ALTER/DROP in einer Transaktion mit sauberem Rollback ist in PostgreSQL selbstverständlich und macht Schema-Deployments gut automatisierbar.

Bewusst ausgeklammert bleibt ein Performance-Shootout: Benchmark-Ergebnisse hängen so stark an Version, Workload und Tuning, dass sich seriös nur der eigene Workload auf beiden Systemen vergleichen lässt, nicht zwei Marketing-Folien.

Developer-Experience und Ökosystem

Für das Team ist der Umstieg vor allem ein Dialekt- und Werkzeug-Wechsel. T-SQL und PL/pgSQL sind sich konzeptionell ähnlich (prozedurale Blöcke, Variablen, Exception-Handling) und unterscheiden sich in hunderten Details. Ein Mini-Paar zeigt die Sorte Reibung, um die es geht: dieselbe Abfrage in beiden Dialekten.

  1: SELECT TOP (10)
  2:     order_id
  3:    ,ISNULL(note, N'(ohne Anmerkung)') AS note
  4:    ,order_date
  5: FROM
  6:    dbo.customer_order
  7: WHERE
  8:    customer_id = @p_customer_id
  9: ORDER BY
 10:    order_date DESC;

  1: SELECT TOP (10)
  2:     order_id
  3:    ,ISNULL(note, N'(ohne Anmerkung)') AS note
  4:    ,order_date
  5: FROM
  6:    dbo.customer_order
  7: WHERE
  8:    customer_id = @p_customer_id
  9: ORDER BY
 10:    order_date DESC;

  1: SELECT
  2:     order_id
  3:    ,COALESCE(note, '(ohne Anmerkung)') AS note
  4:    ,order_date
  5: FROM
  6:    sales.customer_order
  7: WHERE
  8:    customer_id = p_customer_id
  9: ORDER BY
 10:    order_date DESC
 11: LIMIT 10;

  1: SELECT
  2:     order_id
  3:    ,COALESCE(note, '(ohne Anmerkung)') AS note
  4:    ,order_date
  5: FROM
  6:    sales.customer_order
  7: WHERE
  8:    customer_id = p_customer_id
  9: ORDER BY
 10:    order_date DESC
 11: LIMIT 10;

TOP wird zu LIMIT (und wandert ans Ende), ISNULL zum Standard-konformen COALESCE, das N'…'-Präfix entfällt, Parameter verlieren das @. Jede einzelne Stelle ist trivial — die Summe über hunderte Prozeduren ist es nicht. Dazu kommt eine Eigenheit, die regelmäßig unterschätzt wird: PostgreSQL faltet ungequotete Bezeichner auf Kleinbuchstaben, CustomerOrder und customerorder sind dort dasselbe Objekt. CamelCase-Schemata aus SQL Server brauchen deshalb eine bewusste Naming-Entscheidung.

Beim Werkzeug tauscht das Team SSMS gegen pgAdmin, DBeaver oder die IDE-Anbindung. Funktional ist das gleichwertig, aber eingespielte SSMS-Gewohnheiten wie der Aktivitätsmonitor, die Ausführungsplan-Ansicht oder die Agent-Verwaltung verteilen sich danach auf mehrere Werkzeuge statt auf eines. Treiber- und ORM-Unterstützung ist auf beiden Seiten seit Jahren unkritisch (ADO.NET, JDBC, ODBC, Npgsql, Entity Framework, Hibernate). Die PostgreSQL-Dokumentation gilt zu Recht als eine der besten im Datenbank-Umfeld. Die Community beantwortet Fragen öffentlich statt hinter Support-Tickets.

Betrieb, Plattform und Lock-in

Die historische Windows-Bindung von SQL Server ist seit 2017 Geschichte: SQL Server läuft auch auf Linux und in Containern. Die Plattform-Frage hat sich damit verschoben: entscheidend ist nicht mehr das Betriebssystem, sondern das Betriebs-Modell.

Cloud und Managed-Betrieb können beide: Azure SQL auf der einen Seite, Amazon RDS/Aurora, Azure Database for PostgreSQL und Google Cloud SQL auf der anderen. Der Unterschied liegt im Preisschild: Bei SQL Server wandert die Lizenz in den Stundenpreis der Cloud-Instanz mit, bei PostgreSQL zahlt man nur Infrastruktur und Service.

Hochverfügbarkeit und Backup sind auf beiden Seiten gelöst, aber unterschiedlich verpackt: SQL Server bringt AlwaysOn und die Backup-Kette mit GUI und Assistenten mit, PostgreSQL setzt auf Streaming-Replikation, pg_basebackup/WAL-Archivierung und Community-Werkzeuge wie Patroni oder pgBackRest. Wer Managed-Hosting nutzt, delegiert diese Ebene ohnehin an den Anbieter — dann ist der Unterschied klein.

Lock-in ist keine Einbahnstraße. Bei SQL Server bindet das Lizenzmodell plus proprietäre Features (T-SQL-Spezifika, SSIS-Pakete, Agent-Jobs). Bei PostgreSQL gibt es keinen Hersteller, der die Preise erhöhen kann. Wer sich allerdings tief in einen Managed-Dienst oder eine spezielle Extension eingräbt, baut auch dort Wechselkosten auf. Der ehrliche Vergleich lautet: Lizenz-Lock-in gegen Betriebs-Know-how-Lock-in. Beim Personal hat sich der Markt angeglichen. PostgreSQL-Kenntnisse haben unter Entwicklerinnen und Entwicklern in den letzten Jahren deutlich zugenommen, klassische SQL-Server-DBA-Profile sind dagegen seltener geworden.

Wann SQL Server die richtige Wahl bleibt

Dieser Blog arbeitet überwiegend mit PostgreSQL. Gerade deshalb gehört die Gegenrichtung ausformuliert. SQL Server bleibt die richtige Wahl, wenn eine der folgenden Konstellationen zutrifft:

• Der Microsoft-Stack ist das Zuhause. Tiefe .NET-Integration, Active-Directory-Authentifizierung, Power-BI-Landschaft, SSIS-Strecken und SSRS-Berichte in Produktion: hier ersetzt ein Umstieg nicht eine Datenbank, sondern eine Plattform, mit entsprechendem Projekt-Risiko.
• Lizenzen und Skills sind vorhanden. Ein bestehender Enterprise-Agreement-Rahmen, eingespielte DBAs, ausgereifte Betriebs-Runbooks: die Ersparnis eines Umstiegs muss erst einmal die Kosten übertreffen, dieses eingespielte System aufzugeben.
• Ein spezifisches Feature trägt die Last. In-Memory OLTP, verteilte Availability Groups oder der Query Store im täglichen Tuning-Einsatz: Wer solche Features produktiv braucht, findet in PostgreSQL keinen 1:1-Ersatz.
• Express reicht. Für kleine Anwendungen unterhalb der Express-Grenzen ist die Lizenzkosten-Frage gegenstandslos. Dann gibt es keinen Kosten-Grund für einen Wechsel, höchstens strategische Gründe.
• Der Zeitpunkt ist falsch. Mitten in einem großen Release, ohne Test-Abdeckung der Datenbank-Schicht, ohne Betriebs-Erfahrung mit Linux oder Managed-Diensten: ein Umstieg unter Druck misslingt eher als einer mit Anlauf.

Kein Migrations-Druck ist auch ein Ergebnis. Die Frage lohnt eine ehrliche Antwort — nicht die, die das nächste Projekt rechtfertigt.

Entscheidungs-Matrix: SQL Server oder PostgreSQL?

Die Abwägung SQL Server oder PostgreSQL entscheidet sich an der eigenen Konstellation, nicht an Feature-Listen. Die Matrix ordnet die häufigsten Fälle:

Fällt die Tendenz Richtung PostgreSQL, ist der nächste Schritt nicht die Installation, sondern der Plan: der vollständige Umstiegs-Leitfaden im verwandten Pillar-Artikel führt durch die fünf Phasen der Migration, und das Datentyp-Mapping zeigt am konkretesten, wo der Umzug wehtut.

FAQ

Verwandte Artikel

Wenn die Entscheidung für den Umstieg gefallen ist:

• Datenmigration: SQL Server nach PostgreSQL — der vollständige Leitfaden (der Pillar-Artikel: fünf Phasen von der Inventur bis zur Verifikation)

Der erste konkrete Stolperstein:

• Datentyp-Mapping SQL Server → PostgreSQL — was sauber konvertiert und was kippt

Brücke:

• ETL vs. ELT — woran du erkennst, welches Muster du wirklich gebaut hast (die Tooling-Frage, wenn SSIS wegfällt)