BLEIBT INFORMIERT

Meldet euch für unseren Newsletter an und erhaltet exklusive Updates zu Blog, IT-Trends und Neuigkeiten der ORDIX AG.

BLEIBEN SIE INFORMIERT

Melden Sie sich für unsere Newsletter an und erhalten Sie exklusive Updates zu IT-Trends und Neuigkeiten der ORIDX AG.

RAG ohne externe Systeme mit Oracle 26ai
5 Minuten Lesezeit (985 Worte)

PostgreSQL 19 Beta im Überblick

Mit PostgreSQL 19 steht das nächste Major Release in den Startlöchern. Aktuell befindet sich das Release noch in der Beta 3, dennoch lässt sich bereits erkennen, welche Schwerpunkte die Entwickler:innen gesetzt haben. Im Gegensatz zu früheren Versionen konzentriert sich PostgreSQL 19 auf die Weiterentwicklung bestehender Funktionen. Verbesserungen bei Wartung, Replikation, SQL und Performance sollen den Betrieb produktiver Datenbanken vereinfachen.

In diesem Blog-Beitrag wird ein Auszug der neuen Features beschrieben. Für mehr Details zu allen Neuerungen können die offiziellen Release Notes angeschaut werden.

REPACK wird Teil des Datenbankkerns

Eine der wichtigsten Neuerungen ist die Integration des neuen REPACK-Befehls. Bislang konnten Tabellen zwar mit VACUUM bereinigt werden, der belegte Speicherplatz wurde dadurch jedoch nicht an das Betriebssystem zurückgegeben. Für eine vollständige Reorganisation waren VACUUM FULL, CLUSTER oder Erweiterungen wie pg_repack erforderlich.

Mit PostgreSQL 19 steht diese Funktionalität nun direkt im Datenbankkern zur Verfügung. Besonders interessant ist REPACK CONCURRENTLY, das Tabellen im Hintergrund reorganisiert und dabei Lese- und Schreibzugriffe weitgehend zulässt. Lediglich für den abschließenden Austausch der Tabellen ist eine kurze Sperre notwendig. Gerade für produktive Systeme mit großen Tabellen reduziert dies Wartungsfenster erheblich.

Mehr Flexibilität bei Partitionierung und Replikation

Auch die Partitionierung wurde weiter verbessert. Partitionen können künftig zusammengeführt oder aufgeteilt werden, sodass sich einmal gewählte Partitionierungsstrategien einfacher an veränderte Datenmengen oder Aufbewahrungsfristen anpassen lassen. Ein kurzes Beispiel zeigt, wie sich Partitionen künftig zusammenführen und aufteilen lassen: 

-- Merge
ALTER TABLE messdaten 
MERGE PARTITIONS (messdaten_apr, messdaten_mai, messdaten_jun)
INTO messdaten_q2;



-- Split
ALTER TABLE messdaten
SPLIT PARTITION messdaten_q2 INTO (
    PARTITION messdaten_apr FOR VALUES FROM ('01.04.2025') TO ('01.05.2025'),
    PARTITION messdaten_mai FOR VALUES FROM ('01.05.2025') TO ('01.06.2025'),
    PARTITION messdaten_jun FOR VALUES FROM ('01.06.2025') TO ('01.07.2025')
); 

Darüber hinaus entwickelt PostgreSQL die logische Replikation konsequent weiter. Eine wesentliche Neuerung ist die Synchronisation von Sequenzen zwischen Publisher und Subscriber. Dadurch lassen sich Migrationen und Replikationsszenarien einfacher umsetzen, da automatisch erzeugte Schlüsselwerte konsistent bleiben. Ergänzend wurden Publications flexibler gestaltet und das Verhalten bei der Verwaltung von Subscriptions verbessert. 

Verbesserungen für Wartung und Administration

Auch Autovacuum wurde weiterentwickelt. Durch parallele Worker können größere Tabellen künftig effizienter verarbeitet werden.

ALTER SYSTEM SET autovacuum_max_parallel_workers = 4;

Gleichzeitig liefert PostgreSQL zusätzliche Monitoring-Informationen, die Wartungsprozesse transparenter machen und Administrator:innen einen besseren Einblick in die automatischen Hintergrundprozesse geben.

Neue Funktionen für Entwickler:innen

Mit SQL/PGQ unterstützt PostgreSQL erstmals standardisierte Graphabfragen. Dadurch lassen sich relationale Daten auch als Graph analysieren, ohne dass dafür eine separate Graphdatenbank erforderlich ist.

Um dies zu verwenden, wird über CREATE PROPERTY GRAPH definiert, wie die bestehenden relationalen Tabellen als Knoten (Vertices) und Kanten (Edges) interpretiert werden sollen. Im folgenden Beispiel wird mit Hilfe einer User-Tabelle sowie einer Follower-Tabelle ein Graph abgebildet. Dabei bilden die User die Knoten und die Follower-Beziehungen die Verknüpfungen zwischen den Usern:

SELECT * FROM users;
 user_id | name  
---------+-------
       1 | Alice
       2 | Bob
       3 | Caro
       4 | Dave
       5 | Eva
(5 rows)

SELECT * FROM follows;
 follow_id | follower_id | followee_id |    seit    
-----------+-------------+-------------+------------
         1 |           1 |           2 | 10.01.2024
         2 |           2 |           3 | 15.02.2024
         3 |           3 |           4 | 20.03.2024
         4 |           4 |           1 | 05.04.2024
         5 |           1 |           5 | 01.05.2024
         6 |           5 |           3 | 12.06.2024
(6 rows)

CREATE PROPERTY GRAPH social_graph
VERTEX TABLES ( 
users
KEY (user_id)
 	LABEL person 
PROPERTIES (user_id, name)
) 
EDGE TABLES ( 
follows 
KEY (follow_id) 
SOURCE KEY (follower_id) REFERENCES users (user_id) 
DESTINATION KEY (followee_id) REFERENCES users (user_id) 
LABEL follows 
PROPERTIES (since) 
); 

Sobald der Graph definiert ist, können die User und deren Beziehungen über die neue GRAPH_TABLE-Funktion abgefragt werden. Die Abfrage nutzt den definierten Graphen (social_graph) sowie die vergebenen Labels für die Knoten (person) und Kanten (follows): 

SELECT * FROM GRAPH_TABLE (
    social_graph
    MATCH (a IS person)-[IS follows]->(b IS person)
    COLUMNS (a.name AS person_a, b.name AS person_b)
); 

Als Ergebnis liefert diese Abfrage für jede 'Follows'-Beziehung im Graphen eine Zeile mit dem Namen der/des Follower:in (person_a) und dem Namen der gefolgten Person (person_b). 

person_a  | person_b 
----------+----------
 Alice    | Bob
 Bob      | Caro
 Caro     | Dave
 Dave     | Alice
 Alice    | Eva
 Eva      | Caro
(6 rows) 

Außerdem wurde die SQL-Sprache um Komfortfunktionen erweitert. GROUP BY ALL vereinfacht Aggregatabfragen, Window-Funktionen erhalten einen verbesserten Umgang mit NULL-Werten. Die Window-Funktionen LAG, LEAD, FIRST_VALUE, LAST_VALUE und NTH_VALUE unterstützen jetzt die Klausel IGNORE NULLS. Damit lassen sich NULL-Werte beim Durchlaufen des Fensters überspringen. Bislang musste man dafür auf Unterabfragen zurückgreifen. Auch der COPY-Befehl wurde ausgebaut. So lassen sich Daten beispielsweise einfacher importieren oder direkt im JSON-Format exportieren.

Wie viel Tipparbeit diese Komfortfunktionen im Alltag ersparen, zeigt sich besonders bei GROUP BY ALL:

-- Bisheriges SQL:
SELECT kunde, standort, region, SUM(umsatz) 
FROM sales 
GROUP BY kunde, standort, region;

-- Neu in PostgreSQL 19:
SELECT kunde, standort, region, SUM(umsatz) 
FROM sales 
GROUP BY ALL; 

Zusätzlich bringt PostgreSQL 19 ein weiteres Highlight für die Applikationsentwicklung: INSERT … ON CONFLICT DO SELECT RETURNING. Diese Neuerung beim „Upsert“ erlaubt es, bei einem auftretenden Konflikt die bereits existierenden Zeilen als Ergebnis direkt zurückzugeben und optional mit FOR UPDATE/SHARE für weitere Transaktionen zu sperren: 

INSERT INTO users (user_id, name) 
VALUES (1, 'Felix')
ON CONFLICT (user_id) DO SELECT
RETURNING *;[SH5.1]
user_id  | name  
---------+-------
       1 | Alice
(1 row) 

Performance-Optimierungen

Neben den sichtbaren Neuerungen enthält PostgreSQL 19 zahlreiche Verbesserungen im Hintergrund. Der Query Planner wurde an verschiedenen Stellen optimiert und kann Abfragen in bestimmten Fällen effizienter ausführen. Zusätzlich profitieren unter anderem Join-Operationen, Fremdschlüsselprüfungen und Datenimporte von weiteren Optimierungen. 

Fazit

PostgreSQL 19 bringt keine einzelne spektakuläre Neuerung mit, überzeugt aber durch die Vielzahl an Verbesserungen im Detail. Auch wenn sich PostgreSQL 19 derzeit noch in der Beta-Phase befindet, lohnt sich bereits jetzt ein Blick auf die neue Version.

Weitere Informationen zu PostgreSQL gibt es in unserem Seminar „PostgreSQL - Administration“.

Seminarempfehlung

Ähnliche Beiträge

 

Kommentare

Derzeit gibt es keine Kommentare. Schreibe den ersten Kommentar!
Dienstag, 22. September 2026

Sicherheitscode (Captcha)