Postgres 18 : ce qui change vraiment

[khalilbenaz]

---

lede: Postgres 18 continue d'affiner l'essentiel — I/O asynchrone, améliorations du planificateur et opérations plus fluides — confirmant sa place de base de données par défaut en 2026.
lede_en: Postgres 18 keeps refining the essentials — async I/O, planner improvements and smoother operations — cementing its place as the default database in 2026.
title_en: Postgres 18: what really changes

Pourquoi Postgres reste le défaut

En 2026, la question « quelle base de données » revient trop souvent à une réponse évidente : Postgres, sauf raison impérieuse de faire autrement. Ce n'est pas de la paresse — c'est une stratégie de réduction de risque. Une seule base sait faire du relationnel strict, du JSON documentaire (jsonb), du plein texte, du vectoriel (via pgvector), du géospatial (PostGIS) et de la file de messages (SKIP LOCKED). Chaque version majeure resserre cet avantage sans casser la compatibilité.

Postgres 18 s'inscrit exactement dans cette continuité : peu de fonctionnalités spectaculaires, beaucoup de raffinements qui comptent en production.

• Extensibilité — l'écosystème d'extensions reste l'arme secrète.
• Fiabilité — MVCC éprouvé, écosystème de réplication mûr.
• Standard SQL — un support parmi les plus rigoureux du marché.

Le changement structurant : l'I/O asynchrone

L'évolution la plus profonde de cette génération est l'introduction d'un sous-système d'I/O asynchrone. Historiquement, Postgres lisait ses pages de manière largement synchrone, laissant le CPU attendre le disque. Le nouveau modèle permet d'émettre plusieurs requêtes d'I/O en vol simultanément, en s'appuyant sur les mécanismes modernes du kernel Linux.

• Lectures anticipées plus efficaces — les scans séquentiels et certains parcours bénéficient d'un débit disque mieux exploité.
• Meilleure utilisation du matériel — sur SSD NVMe et stockage cloud à forte latence, le gain est le plus visible.
• Fondation pour l'avenir — c'est une infrastructure sur laquelle d'autres optimisations viendront se greffer.

Le message honnête : les gains dépendent fortement de votre charge et de votre stockage. Ne promettez pas un chiffre — mesurez sur votre workload.

Améliorations quotidiennes

Au-delà de l'I/O, la 18 apporte des raffinements qu'on apprécie au quotidien.

• Planificateur — meilleures estimations sur certaines jointures et sous-requêtes, réduisant les plans catastrophiques.
• UUID v7 — génération native d'identifiants ordonnés dans le temps, bien plus favorables aux index B-tree que l'aléatoire v4.

-- Identifiants ordonnés, meilleurs pour la localité d'index
CREATE TABLE events (
    id uuid DEFAULT uuidv7() PRIMARY KEY,
    payload jsonb,
    created_at timestamptz DEFAULT now()
);

• Observabilité — statistiques d'exécution enrichies, utiles pour diagnostiquer les requêtes lentes.
• Confort opérationnel — améliorations autour des mises à niveau et de la maintenance qui réduisent les fenêtres de risque.

Comparaison : quand ne pas prendre Postgres

Besoin	Postgres	Alternative
Relationnel + polyvalence	idéal	—
Analytique colonne massive	correct	DuckDB, ClickHouse
Cache clé-valeur chaud	possible	Redis
Séries temporelles extrêmes	via extensions	bases dédiées
Scale horizontal d'écriture	complexe	bases distribuées

Postgres n'est pas une réponse universelle. Pour de l'analytique colonne à très gros volume, une base colonne dédiée écrase le row-store. Pour du cache sub-milliseconde, Redis reste plus adapté. La sagesse : commencer par Postgres, et n'ajouter un système spécialisé que quand un besoin le prouve.

Pièges et limites

• Ne migrez pas pour l'I/O async seul — validez le gain sur votre charge avant de planifier une montée de version.
• Réglage requis — les nouvelles capacités demandent parfois d'ajuster la configuration pour se manifester.
• VACUUM reste un sujet — la maintenance du bloat MVCC n'est pas magiquement résolue ; surveillez-la.
• Extensions à vérifier — après une version majeure, confirmez la compatibilité de pgvector, PostGIS et consorts.

Verdict

Postgres 18 ne réinvente rien, et c'est précisément la force du projet : une évolution mesurée qui améliore le socle sans trahir la confiance. L'I/O asynchrone est la fondation la plus intéressante à long terme, uuidv7 un cadeau concret pour vos index. Mon conseil inchangé en 2026 : par défaut, prenez Postgres. Ajoutez un système spécialisé seulement quand vous pouvez nommer précisément la limite atteinte — pas par anticipation.

Why Postgres stays the default

In 2026 the question "which database" too often has an obvious answer: Postgres, unless there's a compelling reason otherwise. That's not laziness — it's a risk-reduction strategy. A single database can do strict relational, document JSON (jsonb), full-text, vector (via pgvector), geospatial (PostGIS) and message queuing (SKIP LOCKED). Every major release tightens that advantage without breaking compatibility.

Postgres 18 fits exactly into this continuity: few spectacular features, many refinements that matter in production.

• Extensibility — the extension ecosystem remains the secret weapon.
• Reliability — proven MVCC, a mature replication ecosystem.
• SQL standard — among the most rigorous support on the market.

The structural change: asynchronous I/O

The most profound evolution of this generation is the introduction of an asynchronous I/O subsystem. Historically Postgres read its pages largely synchronously, leaving the CPU waiting on disk. The new model lets it issue several in-flight I/O requests simultaneously, leaning on modern Linux kernel mechanisms.

• More efficient read-ahead — sequential scans and certain traversals benefit from better-exploited disk throughput.
• Better hardware utilization — on NVMe SSDs and high-latency cloud storage the gain is most visible.
• A foundation for the future — this is infrastructure other optimizations will build on.

The honest message: gains depend heavily on your workload and storage. Don't promise a number — measure on your workload.

Day-to-day improvements

Beyond I/O, 18 brings refinements you appreciate daily.

• Planner — better estimates on some joins and subqueries, reducing catastrophic plans.
• UUID v7 — native generation of time-ordered identifiers, far friendlier to B-tree indexes than random v4.

-- Ordered identifiers, better for index locality
CREATE TABLE events (
    id uuid DEFAULT uuidv7() PRIMARY KEY,
    payload jsonb,
    created_at timestamptz DEFAULT now()
);

• Observability — richer execution statistics, useful for diagnosing slow queries.
• Operational comfort — improvements around upgrades and maintenance that shrink risk windows.

Comparison: when not to pick Postgres

Need	Postgres	Alternative
Relational + versatility	ideal	—
Massive columnar analytics	fine	DuckDB, ClickHouse
Hot key-value cache	possible	Redis
Extreme time-series	via extensions	dedicated databases
Horizontal write scale	complex	distributed databases

Postgres is not a universal answer. For very-large-volume columnar analytics, a dedicated columnar database crushes the row-store. For sub-millisecond caching, Redis remains better suited. The wisdom: start with Postgres, and add a specialized system only when a need proves it.

Pitfalls and limits

• Don't migrate for async I/O alone — validate the gain on your workload before planning an upgrade.
• Tuning required — new capabilities sometimes need configuration adjustments to show up.
• VACUUM is still a topic — MVCC bloat maintenance isn't magically solved; watch it.
• Extensions to verify — after a major release, confirm compatibility of pgvector, PostGIS and friends.

Verdict

Postgres 18 reinvents nothing, and that's precisely the project's strength: a measured evolution that improves the base without betraying trust. Async I/O is the most interesting long-term foundation, uuidv7 a concrete gift for your indexes. My unchanged advice in 2026: by default, pick Postgres. Add a specialized system only when you can name precisely the limit you've hit — not in anticipation.