Was ist neu in Postgres 19: Tiefgehende Analyse der Beta-Version

 (snowflake.com)
1 Punkte von GN⁺ 3 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • Die Beta-Version bringt REPACK CONCURRENTLY direkt in den Core für große Produktionsdatenbanken und enthält breite Verbesserungen in SQL-Property-Graph-Abfragen, logischer Replikation, VACUUM, Performance und vielen weiteren Bereichen
  • Unterstützung für das Zusammenführen und Aufteilen von Partitionen sowie die Synchronisierung von Sequenzwerten machen Designänderungen und Datenbewegungen im laufenden Betrieb deutlich einfacher
  • Für Autovacuum werden parallele Worker und ein Prioritätspunktesystem eingeführt, was Durchsatz und Transparenz bei Wartungsaufgaben verbessert
  • Mit SQL/PGQ lassen sich bestehende Daten in Graphform abfragen, ohne das relationale Modell aufzugeben
  • Nicht ein einzelnes Schlagzeilen-Feature, sondern die Breite (breadth) steht im Mittelpunkt: gleichzeitige Fortschritte bei Anwendung, Betrieb, Performance und Erweiterbarkeit

REPACK standardmäßig integriert

  • In langjährig betriebenen Umgebungen tritt immer wieder die Situation auf, dass man Tabellen-Bloat zurückgewinnen, Tabellen neu schreiben oder Daten reorganisieren will, ohne die Sperren in Kauf zu nehmen, die mit VACUUM FULL oder CLUSTER einhergehen
    • Für dieses Problem existierte bereits ein Erweiterungsökosystem, insbesondere pg_repack, das diese Lücke gefüllt hat
  • Postgres 19 führt den Befehl REPACK in den Core ein, einschließlich Unterstützung für REPACK CONCURRENTLY
    • Voraussichtlich ein Feature, das Produktionsnutzer stärker beachten werden, als es der durchschnittliche Leser von Release Notes erwarten würde

Mehr Praxistauglichkeit für Partitionierung

  • Postgres 19 ergänzt Unterstützung für das Zusammenführen und Aufteilen von Partitionen
  • Partitionierungsstrategien werden oft auf Basis unvollständiger Informationen gewählt; ändern sich Workload, Aufbewahrungsdauer oder Datenwachstum, können einzelne Partitionen zu groß oder zu klein werden
  • Durch Split und Merge entsteht Spielraum, das Design im Laufe der Zeit weiterzuentwickeln, ohne von Anfang an alles neu aufzubauen
    • Beispiel zum Zusammenführen von Q1- und Q2-Partitionen in eine einzelne Partition: ALTER TABLE customer_orders MERGE PARTITIONS (orders_2026_q1, orders_2026_q2) INTO orders_2026_h1;
    • Es wird auch ein Beispiel für SPLIT PARTITION gezeigt, das eine Q3-Partition in Monatssegmente aufteilt

Reifere logische Replikation

  • Logische Replikation ist nützlich für Migrationen, Upgrades, Reporting-Systeme, Datenbewegung, selektive Replikation sowie Hochverfügbarkeits- und Betriebs-Workflows
  • Die wichtigste Verbesserung ist die Synchronisierung von Sequenzwerten, sodass Subscriber besser mit dem Publisher übereinstimmen
    • Werden Daten ohne Sequenzstatus repliziert, werden die Daten zwar übertragen, aber nach dem Cutover kann es zu Problemen kommen, weil die als Nächstes erzeugte ID nicht stimmt
    • Hinzu kommen Unterstützung für ALL SEQUENCES bei Publikationen, Fehlermeldungen zur Sequenzsynchronisierung und ein verbessertes Aktualisierungsverhalten von Subscriptions in Bezug auf Sequenzen
  • Beim Publizieren aller Tabellen kann nun eine EXCEPT-Klausel verwendet werden, um bestimmte Tabellen auszuschließen
  • wal_level = replica aktiviert bei Bedarf die logische Replikation automatisch; zusätzlich gibt es das neue effective_wal_level, das die tatsächlich wirksame Konfiguration meldet und so Konfigurationsfehler reduziert sowie die Transparenz verbessert

Intelligenteres und transparenteres Autovacuum

  • Autovacuum kann parallele Vacuum-Worker verwenden und lässt sich global sowie pro Tabelle steuern
    • Beispiel für eine globale Einstellung: ALTER SYSTEM SET autovacuum_max_parallel_workers = 4;
  • Ein neues Punktesystem zur Steuerung der Reihenfolge, in der Tabellen vakuumiert werden, verbessert die Priorisierung der dringendsten Tabellen
    • Beispiel für tabellenspezifische Gewichtung: 3.0 für insert-basierte Vacuum-Dringlichkeit, 0.5 für normale update/delete-basierte Vacuum-Dringlichkeit
  • Die neue View pg_stat_autovacuum_scores macht den Entscheidungsprozess sichtbar
    • Detailliertere Informationen in Fortschrittsansichten für Vacuum und Analyze, Angaben zu Speichernutzung und Parallelität in VACUUM VERBOSE und den Autovacuum-Logs sowie ein separates log_autoanalyze_min_duration verbessern zusätzlich die Beobachtbarkeit von Wartungsvorgängen

Einführung von SQL-Property-Graph-Abfragen

  • SQL/PGQ (SQL property graph queries) wird hinzugefügt
    • Als geeignete Workloads für Vertex-/Edge-Modelle werden unter anderem Betrugserkennung, Empfehlungen, Netzwerkanalyse, Berechtigungsgraphen, Lieferketten und Organigramme genannt
    • Beispiel für die Definition eines Property Graphs: CREATE PROPERTY GRAPH store_graph mit Angabe von VERTEX TABLES und EDGE TABLES
  • Das relationale Modell wird nicht aufgegeben; stattdessen kommt eine weitere Möglichkeit hinzu, bereits vorhandene Daten abzufragen
    • Das folgt derselben Linie wie JSONB, Full-Text Search und Erweiterungen, die ebenfalls keine Änderung der bestehenden Architektur erzwungen haben
  • Aus Entwicklersicht lassen sich graphartige Abfragen nutzen, ohne einen separaten Datastore, zusätzliche Synchronisierungspfade, mehr betriebliche Angriffsfläche oder weitere Debugging-Ziele um 2 Uhr morgens einzuführen

COPY wird nützlicher

  • COPY FROM unterstützt nun das Überspringen mehrerer Header-Zeilen
    • Nützlich für CSV-Exporte von Anbietern oder internen Tools, die zusätzliche Metadatenzeilen am Anfang enthalten
  • Für COPY FROM kommt ON_ERROR SET_NULL hinzu, das fehlerhafte Eingabewerte auf null setzt und damit eine zusätzliche Option zwischen „gesamter Load schlägt fehl“ und „vorherige Bereinigung“ bietet
    • Es wird ein Beispiel für das Laden einer Datei gezeigt, in der in einer price-Spalte Werte wie 'N/A' oder 'MISSING' vorkommen
  • COPY TO kann Ausgabe im JSON-Format erzeugen, einschließlich eines einzelnen JSON-Arrays, und kann Partitionstabellen direkt ausgeben (zuvor war COPY (SELECT ...) nötig)
    • Beispiel für den Export einer Tabelle als gültiges JSON-Array: WITH (FORMAT JSON, ARRAY true)

Verbesserungen bei der SQL-Benutzbarkeit

  • Mit GROUP BY ALL werden Ausdrucke aus der Liste nicht aggregierter und nicht als Window-Funktion verwendeter Ziele automatisch gruppiert, was exploratives SQL und Reporting-Abfragen sauberer macht
  • Unterstützung für IGNORE NULLS und RESPECT NULLS bei Window-Funktionen wird für lead, lag, first_value, last_value und nth_value ergänzt
  • INSERT ... ON CONFLICT DO SELECT ... RETURNING ermöglicht es, bei Upserts Konfliktzeilen direkter zurückzugeben
  • UPDATE und DELETE FOR PORTION OF erweitern die Unterstützung für zeitbezogene (temporal) Operationen; dazu kommt eine erweiterte RANDOM()-Zeitfunktion

Performance-Verbesserungen auf breiter Front

  • Zahlreiche Verbesserungen in Planner und Executor betreffen Anti-Joins, Semi-Joins, Constant Folding, Incremental Sort auf Append-Pfaden, Aggregation vor Joins, Berechnung der Join-Selektivität, Funktionsstatistiken und mehr
  • Postgres entwickelt sich dahin, gängige Abfragemuster besser zu erkennen und unnötige Arbeit zu reduzieren
    • Ein Teil der Aggregation wird vor Joins ausgeführt, wodurch die Zahl der zu verarbeitenden Zeilen sinkt
    • Mehr Fälle von NOT IN und LEFT JOIN werden in effiziente Anti-Joins umgewandelt
    • Verbesserte EXPLAIN-Sichtbarkeit für Memoize, bessere Sortierleistung durch Radix Sort, schnellere Prüfungen von Fremdschlüssel-Constraints und Nutzung von SIMD-Instruktionen für Text- und CSV-Eingaben bei COPY FROM
  • In vielen Fällen ist durch ein Upgrade allein, ohne Änderungen am Anwendungscode, bereits ein besseres Verhalten möglich

Warum Postgres 19 wichtig ist

  • Nicht ein einzelnes Feature, sondern die Breite (breadth) fällt besonders auf
    • Für Anwendungsentwickler: Graph-Abfragen, verbesserte SQL-Syntax, bessere Window-Funktionen und besseres Upsert-Verhalten
    • Für Betreiber: REPACK CONCURRENTLY, verbessertes Autovacuum, besseres Monitoring, Online-Änderung von Checksummen und mehr Transparenz bei der Replikation
    • Für performanceorientierte Nutzer: Planner-Verbesserungen, SIMD-Optimierungen, Transparenz bei asynchronem I/O, schnellere Fremdschlüsselprüfungen und verbesserte Sortierung
    • Für Nutzer, die auf Postgres aufbauen: neue Hooks, ein Planner-Advice-Modul, Verbesserungen bei Erweiterungen, FDW-Statistikabruf und fortgesetzte Investitionen in das Erweiterungsökosystem
  • Nicht nur für einen einzelnen Workload oder eine Persona, sondern als Datenbank und Plattform für Anwendungen, Betrieb, Analyse und Erweiterungen entwickelt es sich gleichzeitig weiter
  • Da es noch kein GA ist, ist jetzt der richtige Zeitpunkt zum Testen — Anwendungen ausführen, Migrationen testen, Erweiterungen prüfen, wichtige Query-Pläne kontrollieren sowie Workflows für logische Replikation und Wartung überprüfen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 3 시간 전
Hacker-News-Kommentare

  • Ich habe Postgres, Oracle, MS SQL Server und MySQL in echten Projekten eingesetzt; SQLite habe ich zwar nicht intensiv genutzt, halte es aber für eine hervorragende Option.
    Heutzutage vermeide ich für mich selbst Oracle und MySQL/MariaDB grundsätzlich.
    Postgres ist großartig, aber ich wünschte, es hätte leichtgewichtige Verbindungen und synchron aktualisierte materialisierte Views. Connection Pooler verbessern die Lage zwar, aber der Speicherverbrauch pro gleichzeitiger Verbindung ist immer noch absurd hoch, und Funktionen wie die indizierten Views von SQL Server ermöglichen bei komplexen Datensituationen elegante, triviale und stets korrekte Implementierungen.
    SQL Server kann teuer sein, ist den Preis aber in vielen Fällen wert; wer seinen Datenspeicher sorgfältig auswählt, kann sich in Zukunft viele Kopfschmerzen ersparen.

    • Für relationale Storage-Probleme nutze ich hauptsächlich SQLite und MSSQL.
      Wenn man einen kostenlosen Anbieter verwenden will, ist SQLite schwer zu schlagen, und es deckt derzeit die meisten Use Cases ab. Bei Backups, Replikation und Tools beginnt es allerdings zu schwächeln. Wenn ich für Systemverfügbarkeit und Disaster Recovery verantwortlich bin, habe ich kein Problem damit, Geld auszugeben, um Risiken zu reduzieren.
      Wenn ich überhaupt Geld ausgebe, dann gehe ich den ganzen Weg. Die Developer Experience rund um MSSQL ist unerreicht, und SSMS sowie SQL-Projekte in Visual Studio halte ich heutzutage für deutlich besser als Dinge wie Entity Framework. Nimmt man noch Third-Party-Tools wie RedGate dazu, kann das Beratungspakete im Millionenbereich ersetzen.
      Ich würde nicht vorschlagen, einen neuen Oracle- oder DB2-Server aufzusetzen, aber wenn es bereits einen gibt, würde ich mich wohl bis zum Schluss dagegen wehren, ihn wegzurefaktorieren. Solche Datenbanken bringen meist riesige Sammlungen von Horrorgeschichten mit sich, und wenn man diese seltsamen Nebenwirkungen mangels Alternative in einer neuen Engine nachbilden muss, kann das das Geschäft selbst kaputtmachen.
    • Oracle ist eine Mischung aus Schmerz, Leid, hohen Kosten, Klagen und menschlichem Elend. Wären da nicht nichttechnische mittlere Manager, die es mögen, beim Kauf teurer Software Vergünstigungen wie nette Partys zu bekommen, wäre es meiner Meinung nach längst untergegangen.
    • Selbst Microsoft scheint SQL Server im Grunde aufgegeben zu haben und mehr Zeit in die Verbesserung verschiedener Postgres-Produkte auf Azure zu stecken. Seit 2022 bestand die letzte größere Version im Wesentlichen nur aus ein paar zusätzlichen AI-Funktionen.
      Wenn man als DBA viel schwere DBA-Arbeit gemacht hat, spielt Postgres in einer anderen Liga als SQL Server. Postgres ist Linux-nativ und Open Source, sodass Flexibilität, interne Beobachtbarkeit und Operabilität mit SQL Server nicht vergleichbar sind.
      In der heutigen Technologielandschaft ist SQL Server meiner Ansicht nach praktisch tot. Es wird nur noch von Legacy-Windows-zentrierten Organisationen genutzt, und auch die werden immer weniger.
    • Synchron aktualisierte materialisierte Views wären wirklich wünschenswert. In Oracle-Terminologie scheint damit so etwas wie „Refresh on commit“ gemeint zu sein.
      Schön wäre auch eine Option für verzögerte Aktualisierung. Dabei würden mehrere Updates auf einmal verarbeitet, indem nur die seit dem letzten Refresh geänderten Datensätze berücksichtigt werden; wie Oracle das technisch macht, weiß ich allerdings nicht genau. Diese Funktion wäre gegenüber fast allen Open-Source-OLTP-Datenbanken eine fantastische Ergänzung.
      Das Projekt OrioleDB interessiert mich ebenfalls sehr: https://github.com/orioledb/orioledb/releases
      Vor ein paar Jahren hatte ich wegen vieler kontinuierlicher zufälliger Inserts und Deletes in etwas, das temporären Tabellen ähnelte, ziemliche Probleme mit vacuum. Gelöst habe ich es, indem ich Änderungen stärker im RAM gesammelt und dann in die Tabelle geflusht habe, um die Zahl geänderter Zeilen pro Seite zu erhöhen; die richtige Balance zu finden war aber sehr mühsam.
    • PostgreSQL ist zwar das bessere Produkt, hat aber nicht die horizontale Skalierbarkeit von MySQL/MariaDB. Wenn man also einen einfach zu konfigurierenden Cluster braucht, etwa für einen großen Online-Retail-Store, ist MySQL weiterhin nützlich.

  • Aus der Perspektive von jemandem, der Postgres seit über 15 Jahren in der Wissenschaft nutzt, macht mir langsam Sorgen, dass PostgreSQL keinen spaltenorientierten Speicher hat.
    Da die Datensätze immer größer werden, spürt man die Grenzen des PG-Speichers zunehmend stärker. Verschiedene Erweiterungen wie cetus können diese Funktionalität zwar bereitstellen, aber dann ist man davon abhängig, dass diese Erweiterung auch künftig unterstützt wird, und die Komplexität steigt ebenfalls.

    • Ein bisschen unverhohlene Werbung, aber ich arbeite seit einigen Monaten in Form einer Erweiterung an genau diesem Problem: https://github.com/xataio/deltax
      Anfangs dachte ich, dass der inhärente Overhead zu groß wäre, wenn man Postgres-Tabellen als Storage und den Postgres-Executor verwendet; es wäre schon ziemlich cool, an die Performance von Timescale heranzukommen. Ich hätte nicht gedacht, dass man einer dedizierten analytischen Datenbank nahekommen könnte.
      Im Verlauf des Projekts wurde die Performance jedoch immer besser, und inzwischen unterstütze ich klar den Ansatz, Analyse-Workloads mit Postgres + Erweiterung zu erledigen.
    • Wenn man das erwartet, hat man möglicherweise die falsche Datenbank gewählt. Spaltenorientierte Datenbanken sind eine eigene Kategorie.
      Das ist ein bisschen so, als würde man sich Sorgen machen, dass Apple keine Waschmaschinen verkauft.
    • Aus Sicht der Informatik bin ich mir nicht sicher, wie eine transaktionale Datenbank Spaltenorientierung implementieren sollte. Bei größerem Maßstab dürfte eine Kombination wie Postgres + CDC + ClickHouse mit einer echten analytischen Datenbank die stärkste Wahl sein.
    • Wenn die Datensätze immer größer werden, erscheint es sinnvoller, neue Daten in PostgreSQL zu halten und ältere Daten regelmäßig in eine Data-Warehouse-artige Datenbank zu archivieren, damit Postgres klein bleibt.
      Heutzutage nutzen viele Unternehmen in ihrer Haupt-App neben relationalen Datenbanken auch Key-Value-Datenbanken oder Document Stores.
    • Aus Sicht eines Nutzers mit 25 Jahren Erfahrung ist der aktuelle Zustand in Ordnung. Mehr ist nicht zwangsläufig besser; Redis zeigt das gut.

  • Ich verstehe nicht, warum nicht erwähnt wurde, dass PostgreSQL 19 Unterstützung für native application-time temporal data auf Basis des SQL:2011-Standards einführt: https://www.depesz.com/2026/04/02/waiting-for-postgresql-19-...

    • Es überrascht mich, dass der Originaltext das nicht erwähnt. Früher hat man das umgesetzt, indem man manuell tcn-Trigger und _archive-Schatten-Tabellen hinzugefügt hat: https://www.postgresql.org/docs/current/tcn.html
      Wenn das nativ funktioniert, dürfte es, wie die meisten PostgreSQL-Implementierungen, wirklich großartig sein
    • Schade ist auch, dass Query Hints nur kurz erwähnt werden. Unter einem früheren Beitrag mit ähnlichem Titel gab es dazu eine interessante Diskussion
      https://news.ycombinator.com/item?id=48413655
    • Ein cooles Feature, aber ehrlich gesagt meiner Meinung nach etwas schwierig gut zu nutzen. Außerdem muss man aufpassen, dass PII nicht lange irgendwo im temporal void liegen bleibt

  • Ich kann nicht einschätzen, ob dieser Artikel einen Stil verwendet, der in LLM-Trainingsdaten überrepräsentiert ist, oder ob viel AI eingesetzt wurde, um den Text zu glätten. Ich tendiere zu Letzterem

    • „Geglättet“ ist viel zu großzügig formuliert. Noch störender ist, dass die Autorenangabe irreführend ist. craig-kerstiens ist bei Hugging Face nicht zu finden, und kein einziger Satz in diesem Artikel wirkt so, als sei er direkt auf einer Tastatur eingetippt worden
      Dass Claude Sätze wie „Als jemand, der X seit Langem macht“ schreibt, halte ich für eine Art Alignment-Fehler. Ein LLM sollte nicht so schreiben, als hätte es persönliche Erfahrungen. Es kann sein, dass Menschen in den Trainingsdaten so gesprochen haben, aber selbst wenn eine Tokenfolge statistisch plausibel ist, sollte ein LLM meiner Meinung nach keine Lebenserfahrung behaupten, die es nicht hat
    • Man muss das nicht wohlwollend auslegen. Snowflake hat Technical Writers entlassen, um sie durch AI zu ersetzen: https://snowflake.help/snowflake-layoffs-2026-technical-writ...
    • Solche Low-Effort-Kommentare, die sich über Stil und Format beschweren, verstoßen gegen die Diskussionsrichtlinien von Hacker News, und es braucht Maßnahmen, um die Kommentarspalten aufzuräumen. Es ist inzwischen lächerlich geworden
    • Pangram stuft diesen Text vollständig als AI-generiert ein, aber ich weiß nicht, wie sehr man Pangram vertrauen kann. Ich würde gern hören, was andere darüber denken
    • Ich verstehe, dass es gerade im Trend liegt, darüber zu spekulieren, ob AI verwendet wurde. Aber wenn es etwas zu kritisieren gibt, ist es meiner Ansicht nach nützlicher, das Endergebnis zu kritisieren

  • Mir gefallen die Verbesserungen bei COPY und logischer Replikation. Derzeit sichere ich eine PG-Datenbank in eine Sidecar-Databasus-Instanz, und die ist schwergewichtiger als das gesamte Backend + DB + Caddy
    Unten folgt Gemecker über LLM-Stil
    Statt Sätze zu lesen wie „Allein das zeigt: Nutzer hatten einen echten Bedarf, und das Ökosystem hat diese Lücke gefüllt“, „Es wirkt einfach, löst aber reale Betriebsprobleme“ oder „Es verändert nicht die Welt, macht aber alltägliche Daten-Workflows besser“, hätte Orwell, wenn er heute noch leben würde, vielleicht den englischen Analphabetismus ausgerufen und Klingonisch gelernt

  • Die Graphdatenbank-Funktionen sehen interessant aus, aber die GRAPH_TABLE-Syntax ist einfach schrecklich
    SELECT customer_name FROM GRAPH_TABLE (myshop MATCH (c IS customers)-[IS customer_orders]->(o IS orders WHERE o.ordered_when = current_date) COLUMNS (c.name AS customer_name));
    Das erinnert an neo4j, aber ich glaube nicht, dass ein ernstzunehmendes Tool im Jahr 2026 das eins zu eins kopieren sollte
    Am Ende interessiert mich die Geschwindigkeit. Row-level Security ist ein sehr nützliches Feature, aber mit der Postgres-Implementierung etwas Ernsthaftes bauen zu wollen, ist waghalsig. Der Planner gerät durcheinander und matcht pro Zeile, was die Performance zerstört

    • Das ist keine willkürliche Syntax, die Postgres selbst erfunden hat
      Es ist SQL/PGQ, abgeleitet von Neo4Js Cypher-Sprache und inzwischen Teil des SQL-Standards
    • Der Planner prüft bei Row-level Security pro Zeile? Genau das ist Row-level Security. Wie sonst soll geprüft werden, ob eine Zeile die Policy erfüllt?

  • Es wäre gut, wenn PostgreSQL nicht nur Zeilenkompression, sondern auch Blockkompression bekäme. Zeilenkompression allein ist in ihrer Wirkung zu begrenzt
    Man kann die Daten zwar in einem ZFS-Pool ablegen und Blockkompression aktivieren, aber native Unterstützung würde den Konfigurationsaufwand verringern und könnte auch performanter sein

  • GROUP BY ALL ergibt, wenn man darüber nachdenkt, wirklich Sinn, und es ist interessant, dass ich vorher noch nie darauf gekommen bin

  • Aus einer eher DevOps-nahen Perspektive wünsche ich mir, dass PostgreSQL endlich In-place-Upgrades zwischen aufeinanderfolgenden Major-Versionen unterstützt
    Die meisten Distributionen können mit der lästigen Eigenheit umgehen, für pg_upgrade alte und neue Version parallel laufen zu lassen, aber mit Docker ist ein Upgrade auf eine neue Major-Version wirklich schmerzhaft

  • Schön, dass GROUP BY ALL eingeführt wird. Soweit ich weiß, ist das ein Konzept, das DuckDB eingeführt hat
    Auch in der DuckDB-Dokumentation steht, dass mehrere Features zuerst in DuckDB eingeführt und Features wie GROUP BY ALL später von anderen Systemen übernommen wurden
    https://duckdb.org/docs/lts/sql/dialect/friendly_sql