PostgreSQL 18 : E/S asynchrones, uuidv7, colonnes générées et pourquoi les développeurs devraient s’y intéresser

PostgreSQL continue de faire cette chose rare dans le logiciel : s’améliorer chaque année sans jamais régresser. La version 18 est une livraison consistante et, fait inhabituel pour une mise à jour de base de données, plusieurs de ses nouveautés phares concernent directement les développeurs d’applications, pas seulement les administrateurs. Un nouveau sous-système d’entrées-sorties asynchrones, un générateur natif d’UUID ordonnés dans le temps, des colonnes générées plus souples et une indexation plus intelligente répondent chacun à des difficultés concrètes du quotidien. Ce guide passe en revue les évolutions qui comptent pour ceux qui écrivent les requêtes, et explique pourquoi elles justifient une mise à niveau.

Entrées-sorties asynchrones : des lectures plus rapides en charge

Historiquement, PostgreSQL émettait les lectures disque une par une et attendait la fin de chacune: un comportement acceptable sur du stockage rapide avec des jeux de travail réduits, mais bien moins quand une requête doit lire de nombreuses pages non mises en cache. La version 18 introduit un sous-système d’entrées-sorties asynchrones qui permet à la base de données d’avoir plusieurs requêtes de lecture en cours simultanément, réduisant ainsi le temps d’attente du stockage. Pour les charges à dominante de lecture, les grands parcours séquentiels et les requêtes analytiques, cela peut améliorer sensiblement le débit, surtout lorsque les données ne tiennent pas toutes en mémoire.

uuidv7() : la bonne façon d’utiliser des clés UUID

Les développeurs adorent les UUID comme clés primaires : uniques globalement, générables côté client, sans séquence centrale. Mais les UUID aléatoires traditionnels (v4) ont un fâcheux effet de bord : parce qu’ils sont aléatoires, leur insertion disperse les écritures dans l’index, ce qui provoque fragmentation et mauvais comportement du cache à mesure que les tables grossissent. UUIDv7 corrige cela en intégrant un horodatage, de sorte que les valeurs sont ordonnées dans le temps : les nouvelles lignes se regroupent dans l’index comme le feraient des entiers auto-incrémentés, tout en conservant l’unicité des UUID. PostgreSQL 18 ajoute une fonction nativeuuidv7() , vous n’avez donc plus besoin d’une extension ou d’une bibliothèque côté client pour en obtenir.

-- Time-ordered UUID keys, built in — unique AND index-friendly.
CREATE TABLE orders (
    id          uuid PRIMARY KEY DEFAULT uuidv7(),
    customer_id bigint NOT NULL,
    created_at  timestamptz NOT NULL DEFAULT now()
);

-- New rows cluster at the "end" of the index like serial ids,
-- avoiding the write scattering that random uuidv4 causes.

Des colonnes générées plus souples

Les colonnes générées permettent à la base de données de calculer automatiquement une colonne à partir d’autres colonnes. Auparavant, PostgreSQL ne prenait en charge que les colonnes générées stockées : la valeur est calculée à l’écriture et sauvegardée sur disque. La version 18 ajoute les colonnes générées virtuelles, calculées à la volée lors de la lecture, de sorte qu’elles ne coûtent aucun stockage et ne se périment jamais. C’est idéal pour les valeurs dérivées que vous souhaitez interroger comme une colonne normale mais sans les persister physiquement.

CREATE TABLE products (
    price_cents   int  NOT NULL,
    tax_rate      numeric NOT NULL,
    -- computed on read: no storage, always current with its inputs
    total_cents   int GENERATED ALWAYS AS
                  (price_cents + round(price_cents * tax_rate)) VIRTUAL
);

Skip scan : davantage de requêtes utilisent vos index

Un piège classique : vous avez un index multicolonne sur (a, b), mais une requête filtre uniquement sur b. PostgreSQL ne peut alors pas utiliser l’index efficacement et bascule sur un parcours plus lent. La version 18 améliore cela avec le skip scan, qui permet au planificateur d’exploiter un tel index même lorsque la colonne de tête n’est pas contrainte, en « sautant » efficacement à travers ses valeurs distinctes. Concrètement, davantage de vos requêtes existantes peuvent s’appuyer sur les index que vous possédez déjà, sans que vous ayez à en ajouter de nouveaux.

Un chemin de mise à niveau plus fluide

Les mises à niveau majeures de PostgreSQL ont longtemps eu un coût caché : après la mise à niveau, les statistiques du planificateur de requêtes de la base de données n'étaient pas conservées, de sorte que le système fraîchement mis à niveau pouvait fonctionner avec des plans médiocres jusqu'à ce que ces statistiques soient reconstruites, provoquant parfois une baisse de performance désagréable au pire moment. La version 18 améliore ce point pour que les mises à niveau risquent moins de vous laisser avec une base temporairement ralentie, réduisant ainsi le risque et le stress liés au passage à une version majeure.

Faut-il passer à la version 18 ?