PostgreSQL 19 : les graphes arrivent en SQL natif

PostgreSQL 19 débarque en septembre 2026 — les vraies nouveautés

PostgreSQL 19 n'est pas une rustine cosmétique. Trois fonctionnalités changent concrètement comment tu écris tes requêtes.

Les graphes : enfin de la recherche de chemins en SQL natif

Tu déclares un graphe sur tes tables existantes :

CREATE PROPERTY GRAPH social
  VERTEX TABLES (person KEY (id) LABEL person PROPERTIES (id, name))
  EDGE TABLES (follows KEY (follower, followee) SOURCE KEY (follower) REFERENCES person(id) DESTINATION KEY (followee) REFERENCES person(id) LABEL follows);

Pas de copie de données. C'est juste une vue qui dit "les lignes person sont des sommets, les lignes follows sont des arêtes".

Maintenant tu interroges avec de la recherche de chemins :

SELECT * FROM GRAPH_TABLE (
  social MATCH (a IS person) -[IS follows]-> (b IS person)
  COLUMNS (a.name AS follower, b.name AS followee)
);

Le vrai gain : les chemins multi-sauts. "Amis d'amis" sans auto-jointure :

SELECT * FROM GRAPH_TABLE (
  social MATCH (a IS person WHERE a.name = 'Ada') -[IS follows]-> () -[IS follows]-> (c IS person)
  COLUMNS (a.name AS start, c.name AS friend_of_friend)
);

PostgreSQL le réécrit en jointures classiques. Tes index, ton optimiseur, tout ce que tu connais fonctionne. Limitation : pas de chemins de longueur variable (-[]->{1,3}) pour l'instant.

Temporal : découper les périodes sans réécrire les lignes

Tu as une ligne avec une validité sur toute l'année. Tu veux changer le prix juste pour juillet :

UPDATE price FOR PORTION OF valid_at FROM '2026-07-01' TO '2026-08-01'
SET amount = 7.99;

PostgreSQL la scinde automatiquement en trois : avant juillet, juillet (modifié), après juillet. Le DELETE fonctionne pareil — tu le découpes sur une période.

C'est utile si tu gardes l'historique en colonnes de plage (range columns). Plus besoin de logique applicative pour ça.

Upsert qui te dit ce que tu as trouvé

INSERT ... ON CONFLICT a toujours eu un angle mort : les lignes qui entraient en conflit disparaissaient du résultat. Avec PostgreSQL 19 :

INSERT INTO inventory VALUES ('widget', 1), ('gadget', 3)
ON CONFLICT (sku) DO SELECT RETURNING sku, qty;

Tu récupères les lignes existantes sans les modifier. En prime : DO SELECT FOR UPDATE te les verrouille pour que tu décides après. Et le champ xmax = 0 te dit quelles lignes ont vraiment été insérées par opposition à celles qui existaient déjà.

À retenir

C'est du SQL pur, pas une nouvelle couche. L'optimiseur de PostgreSQL fait le boulot. La limite principale : pas encore de chemins de longueur variable dans les graphes. La sortie est prévue en septembre/octobre 2026, tu peux tester dès maintenant en bêta.