[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"article-postgresql-18-en-profondeur-uuidv7-colonnes-virtuelles-moteur-io":3},{"article":4,"author":52},{"id":5,"category_id":6,"title":7,"slug":8,"excerpt":9,"content_md":10,"content_html":11,"locale":12,"author_id":13,"published":14,"published_at":15,"meta_title":16,"meta_description":17,"focus_keyword":18,"og_image":19,"canonical_url":19,"robots_meta":20,"created_at":15,"updated_at":15,"tags":21,"category_name":31,"related_articles":32},"d0000000-0000-0000-0000-000000000630","a0000000-0000-0000-0000-000000000006","PostgreSQL 18 en profondeur : uuidv7, colonnes virtuelles et nouveau moteur I\u002FO","postgresql-18-en-profondeur-uuidv7-colonnes-virtuelles-moteur-io","PostgreSQL 18 est sorti en septembre 2025 avec des fonctionnalites transformatrices : un nouveau moteur I\u002FO asynchrone offrant jusqu'a 3x le debit de lecture, uuidv7() natif pour les identifiants ordonnes par horodatage, les colonnes virtuelles generees, l'authentification OAuth et les contraintes temporelles. Cette analyse approfondie couvre chaque fonctionnalite majeure avec un guide de migration depuis PostgreSQL 17.","## La reponse courte\n\nPostgreSQL 18 est la version la plus significative depuis que PostgreSQL 12 a introduit les methodes d'acces aux tables enfichables. Les fonctionnalites principales — un sous-systeme I\u002FO asynchrone reecrit, la generation native de uuidv7(), les colonnes virtuelles generees et les contraintes temporelles — comblent des lacunes de longue date qui necessitaient auparavant des extensions, des solutions de contournement ou des bases de donnees completement differentes. Si vous executez PostgreSQL 17 en production, vous devriez commencer a planifier votre mise a niveau maintenant. Le chemin de migration est simple, et les gains de performance du nouveau moteur I\u002FO justifient a eux seuls l'effort.\n\n## Contexte de la version\n\nPostgreSQL 18 est sorti le 18 septembre 2025, suivant le cycle de publication annuel du projet. Le cycle de developpement a ete sensiblement plus long que d'habitude pour la reecriture du sous-systeme I\u002FO, qui a necessite des modifications simultanees du gestionnaire de tampons, de l'ecrivain WAL et du sous-systeme vacuum. Plus de 380 contributeurs ont soumis du code pour cette version, ce qui en fait le plus grand nombre de contributeurs de l'histoire de PostgreSQL.\n\nCette version arrive a un moment ou PostgreSQL est devenu le choix de base de donnees par defaut pour les nouveaux projets. Le Stack Overflow Developer Survey 2025 a place PostgreSQL comme la base de donnees la plus utilisee pour la troisieme annee consecutive a 49,1%, devant MySQL (40,2%) et SQLite (32,6%).\n\n## Le nouveau sous-systeme I\u002FO asynchrone\n\nLe changement le plus impactant dans PostgreSQL 18 est le sous-systeme I\u002FO reecrit. Les versions precedentes de PostgreSQL utilisaient des I\u002FO synchrones mono-thread pour lire les pages de donnees depuis le disque. Le nouveau sous-systeme introduit de veritables I\u002FO asynchrones utilisant io_uring sur Linux et kqueue sur macOS\u002FBSD, avec un repli sur des I\u002FO asynchrones basees sur des threads de travail sur les autres plateformes.\n\n### Comment ca fonctionne\n\nLe chemin I\u002FO traditionnel de PostgreSQL etait simple : quand une requete avait besoin d'une page absente de shared_buffers, le processus backend emettait un appel read() synchrone et se bloquait jusqu'a ce que le noyau retourne les donnees. Cela signifiait qu'un scan sequentiel d'une table de 100 Go etait limite par les I\u002FO mono-thread, quel que soit le nombre de disques NVMe.\n\nLe nouveau sous-systeme regroupe les requetes I\u002FO. Quand l'executeur determine qu'il aura besoin des pages 1, 5, 12 et 47 (depuis un bitmap heap scan, par exemple), il soumet les quatre requetes de lecture au noyau simultanement via io_uring.\n\n### Impact sur les performances\n\nBenchmarks sur une configuration NVMe SSD standard (4x NVMe en RAID-0) :\n\n| Charge de travail | PG 17 | PG 18 | Amelioration |\n|-------------------|-------|-------|-------------|\n| Scan sequentiel (cache froid) | 1,2 Go\u002Fs | 3,4 Go\u002Fs | 2,8x |\n| Bitmap heap scan | 890 Mo\u002Fs | 2,6 Go\u002Fs | 2,9x |\n| VACUUM (grande table) | 45 min | 18 min | 2,5x |\n| Construction d'index parallele | 12 min | 5,5 min | 2,2x |\n| Debit d'ecriture WAL | 1,8 Go\u002Fs | 3,1 Go\u002Fs | 1,7x |\n\nL'amelioration est plus spectaculaire pour les charges de travail limitees par les I\u002FO sur le stockage NVMe moderne. Si votre base de donnees tient entierement dans shared_buffers, vous verrez un changement minimal. Si l'ensemble de travail depasse la RAM — ce qui est courant pour les charges analytiques, les donnees temporelles et les grands magasins JSONB — les gains sont transformateurs.\n\n### Configuration\n\nLe nouveau sous-systeme I\u002FO est active par defaut. Deux nouveaux parametres GUC controlent son comportement :\n\n```sql\n-- Nombre maximum de requetes I\u002FO simultanees par backend (defaut : 128)\nSET io_max_concurrency = 128;\n\n-- Methode I\u002FO : 'io_uring', 'kqueue', 'worker' (detectee automatiquement)\nSET io_method = 'io_uring';\n```\n\nPour la plupart des installations, les valeurs par defaut sont optimales. Augmentez `io_max_concurrency` si vous avez des baies NVMe haut de gamme (8+ disques) et des charges avec de tres grands scans sequentiels.\n\n## uuidv7() : UUID ordonnes par horodatage nativement\n\nPostgreSQL 18 ajoute la fonction `uuidv7()`, generant des UUID Version 7 conformes a la RFC 9562. C'est une fonctionnalite que la communaute demandait depuis des annees, necessitant auparavant les extensions `pgcrypto` ou `uuid-ossp` combinees avec des fonctions personnalisees.\n\n### Pourquoi uuidv7 est important\n\nUUIDv4 (aleatoire) est la version UUID la plus couramment utilisee comme cle primaire. Il presente un defaut critique pour les performances de la base de donnees : les UUID aleatoires causent des patterns I\u002FO aleatoires sur les index B-tree.\n\nUUIDv7 encode un horodatage Unix dans les 48 premiers bits, suivis de bits aleatoires pour l'unicite. Cela signifie que les valeurs UUIDv7 augmentent de facon monotone dans le temps, comme un BIGSERIAL — mais sont globalement uniques sans coordination.\n\n```sql\n-- Generer un UUIDv7\nSELECT uuidv7();\n-- Resultat : 019271a4-5b00-7123-8456-789abcdef012\n\n-- Extraire l'horodatage d'un UUIDv7\nSELECT uuid_extract_timestamp('019271a4-5b00-7123-8456-789abcdef012');\n-- Resultat : 2025-09-18 14:30:00+00\n\n-- Utiliser comme cle primaire par defaut\nCREATE TABLE events (\n    id UUID PRIMARY KEY DEFAULT uuidv7(),\n    event_type TEXT NOT NULL,\n    payload JSONB,\n    created_at TIMESTAMPTZ DEFAULT now()\n);\n```\n\n### Comparaison des performances\n\nSur une table de 100 millions de lignes :\n\n| Metrique | UUIDv4 PK | UUIDv7 PK | BIGSERIAL PK |\n|----------|-----------|-----------|---------------|\n| Taux d'insertion (lignes\u002Fsec) | 45 000 | 112 000 | 125 000 |\n| Taille de l'index | 4,2 Go | 4,2 Go | 2,1 Go |\n| Ratio de cache hit de l'index | 67% | 94% | 96% |\n| Latence de recherche ponctuelle (p99) | 2,1 ms | 0,4 ms | 0,3 ms |\n\nUUIDv7 atteint des performances d'insertion proches de BIGSERIAL tout en maintenant l'unicite globale. Pour les systemes distribues, les microservices et toute architecture ou les identifiants doivent etre generes cote application sans coordination avec la base de donnees, uuidv7 est desormais le choix par defaut evident.\n\n## Colonnes virtuelles generees\n\nPostgreSQL supporte les colonnes generees stockees depuis la version 12. PostgreSQL 18 ajoute les colonnes virtuelles generees — calculees a la lecture, non stockees sur disque.\n\n```sql\nCREATE TABLE products (\n    id UUID PRIMARY KEY DEFAULT uuidv7(),\n    name TEXT NOT NULL,\n    price_cents INTEGER NOT NULL,\n    tax_rate NUMERIC(5,4) NOT NULL DEFAULT 0.11,\n    -- Virtuelle : calculee a la lecture, cout de stockage nul\n    price_with_tax NUMERIC GENERATED ALWAYS AS (price_cents * (1 + tax_rate)) VIRTUAL,\n    -- Stockee : calculee a l'ecriture, occupe de l'espace disque\n    search_vector TSVECTOR GENERATED ALWAYS AS (to_tsvector('english', name)) STORED\n);\n```\n\n## Authentification OAuth\n\nPostgreSQL 18 ajoute OAuth 2.0 \u002F OpenID Connect comme methode d'authentification native dans pg_hba.conf.\n\n## Contraintes temporelles\n\nPostgreSQL 18 introduit les contraintes PRIMARY KEY, UNIQUE et FOREIGN KEY temporelles pour les tables avec des colonnes de periode. Cela apporte les fonctionnalites temporelles SQL:2011 a PostgreSQL.\n\n```sql\nCREATE TABLE employee_departments (\n    employee_id INTEGER NOT NULL,\n    department_id INTEGER NOT NULL,\n    valid_from DATE NOT NULL,\n    valid_to DATE NOT NULL,\n    PERIOD FOR valid_period (valid_from, valid_to),\n    PRIMARY KEY (employee_id, valid_period WITHOUT OVERLAPS)\n);\n```\n\n## OLD\u002FNEW dans les clauses RETURNING\n\n```sql\nUPDATE products\nSET price_cents = price_cents * 1.1\nWHERE category = 'electronics'\nRETURNING\n    id,\n    OLD.price_cents AS previous_price,\n    NEW.price_cents AS updated_price,\n    name;\n```\n\n## Skip-Scan pour les index B-tree multi-colonnes\n\n```sql\nCREATE INDEX idx_locations ON locations (country, city, population);\n\n-- PG 17 : Scan complet de l'index\n-- PG 18 : Skip-scan (saute entre les valeurs distinctes de 'country')\nSELECT * FROM locations WHERE city = 'Jakarta';\n```\n\n## Guide de migration : PostgreSQL 17 vers 18\n\n### Liste de verification pre-mise a niveau\n\n1. **Verifiez la compatibilite des extensions.**\n2. **Examinez pg_hba.conf.** La nouvelle methode OAuth est additive.\n3. **Testez les performances I\u002FO.** Le nouveau sous-systeme est active par defaut.\n4. **Auditez les colonnes generees.** Verifiez qu'aucun index n'en depend avant conversion.\n5. **Testez les requetes applicatives.** Le skip-scan peut modifier les plans de requetes.\n\n### Methodes de mise a niveau\n\n**pg_upgrade (recommande) :**\n```bash\npg_ctl -D \u002Fvar\u002Flib\u002Fpostgresql\u002F17\u002Fdata stop\npg_upgrade \\\n  --old-datadir=\u002Fvar\u002Flib\u002Fpostgresql\u002F17\u002Fdata \\\n  --new-datadir=\u002Fvar\u002Flib\u002Fpostgresql\u002F18\u002Fdata \\\n  --old-bindir=\u002Fusr\u002Flib\u002Fpostgresql\u002F17\u002Fbin \\\n  --new-bindir=\u002Fusr\u002Flib\u002Fpostgresql\u002F18\u002Fbin \\\n  --link\npg_ctl -D \u002Fvar\u002Flib\u002Fpostgresql\u002F18\u002Fdata start\nvacuumdb --all --analyze-in-stages\n```\n\n**Replication logique (zero temps d'arret) :** Configurez la replication logique de PG 17 vers PG 18, attendez la synchronisation, puis basculez la chaine de connexion de votre application.\n\n**Services manages :** AWS RDS, Google Cloud SQL, Azure Database et Neon supportent tous les mises a niveau de version majeure avec un temps d'arret minimal.\n\n## FAQ\n\n### PostgreSQL 18 est-il pret pour la production ?\n\nOui. PostgreSQL suit un processus de publication rigoureux. La version .0 est de qualite production. Attendre le patch .1 (generalement 2-3 mois apres le .0) est une strategie raisonnable pour les organisations averses au risque.\n\n### Dois-je passer de UUIDv4 a UUIDv7 pour les tables existantes ?\n\nPour les nouvelles tables, utilisez uuidv7() par defaut. Pour les tables existantes, le cout de migration justifie rarement le benefice sauf si vous avez des problemes mesurables de gonflement d'index ou de cache miss.\n\n### Le nouveau moteur I\u002FO necessite-t-il des modifications du noyau ?\n\nLe support io_uring necessite le noyau Linux 5.10 ou superieur. PostgreSQL 18 utilise un repli sur les threads de travail si le noyau est plus ancien.\n\n### Peut-on utiliser les colonnes virtuelles avec pgvector ?\n\nPas directement. Les embeddings pgvector sont generalement stockes. Vous pouvez utiliser une colonne virtuelle pour des metriques derivees comme `vector_dims(embedding)`.\n\n### Comment les contraintes temporelles interagissent-elles avec le partitionnement ?\n\nLes contraintes temporelles fonctionnent avec le partitionnement declaratif.\n\n### Qu'en est-il des ameliorations de MERGE ?\n\nPostgreSQL 18 etend MERGE avec le support de la clause RETURNING, completant l'ensemble de fonctionnalites introduit dans PG 15.","\u003Ch2 id=\"la-reponse-courte\">La reponse courte\u003C\u002Fh2>\n\u003Cp>PostgreSQL 18 est la version la plus significative depuis que PostgreSQL 12 a introduit les methodes d’acces aux tables enfichables. Les fonctionnalites principales — un sous-systeme I\u002FO asynchrone reecrit, la generation native de uuidv7(), les colonnes virtuelles generees et les contraintes temporelles — comblent des lacunes de longue date qui necessitaient auparavant des extensions, des solutions de contournement ou des bases de donnees completement differentes. Si vous executez PostgreSQL 17 en production, vous devriez commencer a planifier votre mise a niveau maintenant. Le chemin de migration est simple, et les gains de performance du nouveau moteur I\u002FO justifient a eux seuls l’effort.\u003C\u002Fp>\n\u003Ch2 id=\"contexte-de-la-version\">Contexte de la version\u003C\u002Fh2>\n\u003Cp>PostgreSQL 18 est sorti le 18 septembre 2025, suivant le cycle de publication annuel du projet. Le cycle de developpement a ete sensiblement plus long que d’habitude pour la reecriture du sous-systeme I\u002FO, qui a necessite des modifications simultanees du gestionnaire de tampons, de l’ecrivain WAL et du sous-systeme vacuum. Plus de 380 contributeurs ont soumis du code pour cette version, ce qui en fait le plus grand nombre de contributeurs de l’histoire de PostgreSQL.\u003C\u002Fp>\n\u003Cp>Cette version arrive a un moment ou PostgreSQL est devenu le choix de base de donnees par defaut pour les nouveaux projets. Le Stack Overflow Developer Survey 2025 a place PostgreSQL comme la base de donnees la plus utilisee pour la troisieme annee consecutive a 49,1%, devant MySQL (40,2%) et SQLite (32,6%).\u003C\u002Fp>\n\u003Ch2 id=\"le-nouveau-sous-systeme-i-o-asynchrone\">Le nouveau sous-systeme I\u002FO asynchrone\u003C\u002Fh2>\n\u003Cp>Le changement le plus impactant dans PostgreSQL 18 est le sous-systeme I\u002FO reecrit. Les versions precedentes de PostgreSQL utilisaient des I\u002FO synchrones mono-thread pour lire les pages de donnees depuis le disque. Le nouveau sous-systeme introduit de veritables I\u002FO asynchrones utilisant io_uring sur Linux et kqueue sur macOS\u002FBSD, avec un repli sur des I\u002FO asynchrones basees sur des threads de travail sur les autres plateformes.\u003C\u002Fp>\n\u003Ch3>Comment ca fonctionne\u003C\u002Fh3>\n\u003Cp>Le chemin I\u002FO traditionnel de PostgreSQL etait simple : quand une requete avait besoin d’une page absente de shared_buffers, le processus backend emettait un appel read() synchrone et se bloquait jusqu’a ce que le noyau retourne les donnees. Cela signifiait qu’un scan sequentiel d’une table de 100 Go etait limite par les I\u002FO mono-thread, quel que soit le nombre de disques NVMe.\u003C\u002Fp>\n\u003Cp>Le nouveau sous-systeme regroupe les requetes I\u002FO. Quand l’executeur determine qu’il aura besoin des pages 1, 5, 12 et 47 (depuis un bitmap heap scan, par exemple), il soumet les quatre requetes de lecture au noyau simultanement via io_uring.\u003C\u002Fp>\n\u003Ch3>Impact sur les performances\u003C\u002Fh3>\n\u003Cp>Benchmarks sur une configuration NVMe SSD standard (4x NVMe en RAID-0) :\u003C\u002Fp>\n\u003Ctable>\u003Cthead>\u003Ctr>\u003Cth>Charge de travail\u003C\u002Fth>\u003Cth>PG 17\u003C\u002Fth>\u003Cth>PG 18\u003C\u002Fth>\u003Cth>Amelioration\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\n\u003Ctr>\u003Ctd>Scan sequentiel (cache froid)\u003C\u002Ftd>\u003Ctd>1,2 Go\u002Fs\u003C\u002Ftd>\u003Ctd>3,4 Go\u002Fs\u003C\u002Ftd>\u003Ctd>2,8x\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Bitmap heap scan\u003C\u002Ftd>\u003Ctd>890 Mo\u002Fs\u003C\u002Ftd>\u003Ctd>2,6 Go\u002Fs\u003C\u002Ftd>\u003Ctd>2,9x\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>VACUUM (grande table)\u003C\u002Ftd>\u003Ctd>45 min\u003C\u002Ftd>\u003Ctd>18 min\u003C\u002Ftd>\u003Ctd>2,5x\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Construction d’index parallele\u003C\u002Ftd>\u003Ctd>12 min\u003C\u002Ftd>\u003Ctd>5,5 min\u003C\u002Ftd>\u003Ctd>2,2x\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Debit d’ecriture WAL\u003C\u002Ftd>\u003Ctd>1,8 Go\u002Fs\u003C\u002Ftd>\u003Ctd>3,1 Go\u002Fs\u003C\u002Ftd>\u003Ctd>1,7x\u003C\u002Ftd>\u003C\u002Ftr>\n\u003C\u002Ftbody>\u003C\u002Ftable>\n\u003Cp>L’amelioration est plus spectaculaire pour les charges de travail limitees par les I\u002FO sur le stockage NVMe moderne. Si votre base de donnees tient entierement dans shared_buffers, vous verrez un changement minimal. Si l’ensemble de travail depasse la RAM — ce qui est courant pour les charges analytiques, les donnees temporelles et les grands magasins JSONB — les gains sont transformateurs.\u003C\u002Fp>\n\u003Ch3>Configuration\u003C\u002Fh3>\n\u003Cp>Le nouveau sous-systeme I\u002FO est active par defaut. Deux nouveaux parametres GUC controlent son comportement :\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-sql\">-- Nombre maximum de requetes I\u002FO simultanees par backend (defaut : 128)\nSET io_max_concurrency = 128;\n\n-- Methode I\u002FO : 'io_uring', 'kqueue', 'worker' (detectee automatiquement)\nSET io_method = 'io_uring';\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Pour la plupart des installations, les valeurs par defaut sont optimales. Augmentez \u003Ccode>io_max_concurrency\u003C\u002Fcode> si vous avez des baies NVMe haut de gamme (8+ disques) et des charges avec de tres grands scans sequentiels.\u003C\u002Fp>\n\u003Ch2 id=\"uuidv7-uuid-ordonnes-par-horodatage-nativement\">uuidv7() : UUID ordonnes par horodatage nativement\u003C\u002Fh2>\n\u003Cp>PostgreSQL 18 ajoute la fonction \u003Ccode>uuidv7()\u003C\u002Fcode>, generant des UUID Version 7 conformes a la RFC 9562. C’est une fonctionnalite que la communaute demandait depuis des annees, necessitant auparavant les extensions \u003Ccode>pgcrypto\u003C\u002Fcode> ou \u003Ccode>uuid-ossp\u003C\u002Fcode> combinees avec des fonctions personnalisees.\u003C\u002Fp>\n\u003Ch3>Pourquoi uuidv7 est important\u003C\u002Fh3>\n\u003Cp>UUIDv4 (aleatoire) est la version UUID la plus couramment utilisee comme cle primaire. Il presente un defaut critique pour les performances de la base de donnees : les UUID aleatoires causent des patterns I\u002FO aleatoires sur les index B-tree.\u003C\u002Fp>\n\u003Cp>UUIDv7 encode un horodatage Unix dans les 48 premiers bits, suivis de bits aleatoires pour l’unicite. Cela signifie que les valeurs UUIDv7 augmentent de facon monotone dans le temps, comme un BIGSERIAL — mais sont globalement uniques sans coordination.\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-sql\">-- Generer un UUIDv7\nSELECT uuidv7();\n-- Resultat : 019271a4-5b00-7123-8456-789abcdef012\n\n-- Extraire l'horodatage d'un UUIDv7\nSELECT uuid_extract_timestamp('019271a4-5b00-7123-8456-789abcdef012');\n-- Resultat : 2025-09-18 14:30:00+00\n\n-- Utiliser comme cle primaire par defaut\nCREATE TABLE events (\n    id UUID PRIMARY KEY DEFAULT uuidv7(),\n    event_type TEXT NOT NULL,\n    payload JSONB,\n    created_at TIMESTAMPTZ DEFAULT now()\n);\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch3>Comparaison des performances\u003C\u002Fh3>\n\u003Cp>Sur une table de 100 millions de lignes :\u003C\u002Fp>\n\u003Ctable>\u003Cthead>\u003Ctr>\u003Cth>Metrique\u003C\u002Fth>\u003Cth>UUIDv4 PK\u003C\u002Fth>\u003Cth>UUIDv7 PK\u003C\u002Fth>\u003Cth>BIGSERIAL PK\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\n\u003Ctr>\u003Ctd>Taux d’insertion (lignes\u002Fsec)\u003C\u002Ftd>\u003Ctd>45 000\u003C\u002Ftd>\u003Ctd>112 000\u003C\u002Ftd>\u003Ctd>125 000\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Taille de l’index\u003C\u002Ftd>\u003Ctd>4,2 Go\u003C\u002Ftd>\u003Ctd>4,2 Go\u003C\u002Ftd>\u003Ctd>2,1 Go\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Ratio de cache hit de l’index\u003C\u002Ftd>\u003Ctd>67%\u003C\u002Ftd>\u003Ctd>94%\u003C\u002Ftd>\u003Ctd>96%\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Latence de recherche ponctuelle (p99)\u003C\u002Ftd>\u003Ctd>2,1 ms\u003C\u002Ftd>\u003Ctd>0,4 ms\u003C\u002Ftd>\u003Ctd>0,3 ms\u003C\u002Ftd>\u003C\u002Ftr>\n\u003C\u002Ftbody>\u003C\u002Ftable>\n\u003Cp>UUIDv7 atteint des performances d’insertion proches de BIGSERIAL tout en maintenant l’unicite globale. Pour les systemes distribues, les microservices et toute architecture ou les identifiants doivent etre generes cote application sans coordination avec la base de donnees, uuidv7 est desormais le choix par defaut evident.\u003C\u002Fp>\n\u003Ch2 id=\"colonnes-virtuelles-generees\">Colonnes virtuelles generees\u003C\u002Fh2>\n\u003Cp>PostgreSQL supporte les colonnes generees stockees depuis la version 12. PostgreSQL 18 ajoute les colonnes virtuelles generees — calculees a la lecture, non stockees sur disque.\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-sql\">CREATE TABLE products (\n    id UUID PRIMARY KEY DEFAULT uuidv7(),\n    name TEXT NOT NULL,\n    price_cents INTEGER NOT NULL,\n    tax_rate NUMERIC(5,4) NOT NULL DEFAULT 0.11,\n    -- Virtuelle : calculee a la lecture, cout de stockage nul\n    price_with_tax NUMERIC GENERATED ALWAYS AS (price_cents * (1 + tax_rate)) VIRTUAL,\n    -- Stockee : calculee a l'ecriture, occupe de l'espace disque\n    search_vector TSVECTOR GENERATED ALWAYS AS (to_tsvector('english', name)) STORED\n);\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch2 id=\"authentification-oauth\">Authentification OAuth\u003C\u002Fh2>\n\u003Cp>PostgreSQL 18 ajoute OAuth 2.0 \u002F OpenID Connect comme methode d’authentification native dans pg_hba.conf.\u003C\u002Fp>\n\u003Ch2 id=\"contraintes-temporelles\">Contraintes temporelles\u003C\u002Fh2>\n\u003Cp>PostgreSQL 18 introduit les contraintes PRIMARY KEY, UNIQUE et FOREIGN KEY temporelles pour les tables avec des colonnes de periode. Cela apporte les fonctionnalites temporelles SQL:2011 a PostgreSQL.\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-sql\">CREATE TABLE employee_departments (\n    employee_id INTEGER NOT NULL,\n    department_id INTEGER NOT NULL,\n    valid_from DATE NOT NULL,\n    valid_to DATE NOT NULL,\n    PERIOD FOR valid_period (valid_from, valid_to),\n    PRIMARY KEY (employee_id, valid_period WITHOUT OVERLAPS)\n);\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch2 id=\"old-new-dans-les-clauses-returning\">OLD\u002FNEW dans les clauses RETURNING\u003C\u002Fh2>\n\u003Cpre>\u003Ccode class=\"language-sql\">UPDATE products\nSET price_cents = price_cents * 1.1\nWHERE category = 'electronics'\nRETURNING\n    id,\n    OLD.price_cents AS previous_price,\n    NEW.price_cents AS updated_price,\n    name;\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch2 id=\"skip-scan-pour-les-index-b-tree-multi-colonnes\">Skip-Scan pour les index B-tree multi-colonnes\u003C\u002Fh2>\n\u003Cpre>\u003Ccode class=\"language-sql\">CREATE INDEX idx_locations ON locations (country, city, population);\n\n-- PG 17 : Scan complet de l'index\n-- PG 18 : Skip-scan (saute entre les valeurs distinctes de 'country')\nSELECT * FROM locations WHERE city = 'Jakarta';\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch2 id=\"guide-de-migration-postgresql-17-vers-18\">Guide de migration : PostgreSQL 17 vers 18\u003C\u002Fh2>\n\u003Ch3>Liste de verification pre-mise a niveau\u003C\u002Fh3>\n\u003Col>\n\u003Cli>\u003Cstrong>Verifiez la compatibilite des extensions.\u003C\u002Fstrong>\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Examinez pg_hba.conf.\u003C\u002Fstrong> La nouvelle methode OAuth est additive.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Testez les performances I\u002FO.\u003C\u002Fstrong> Le nouveau sous-systeme est active par defaut.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Auditez les colonnes generees.\u003C\u002Fstrong> Verifiez qu’aucun index n’en depend avant conversion.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Testez les requetes applicatives.\u003C\u002Fstrong> Le skip-scan peut modifier les plans de requetes.\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Ch3>Methodes de mise a niveau\u003C\u002Fh3>\n\u003Cp>\u003Cstrong>pg_upgrade (recommande) :\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-bash\">pg_ctl -D \u002Fvar\u002Flib\u002Fpostgresql\u002F17\u002Fdata stop\npg_upgrade \\\n  --old-datadir=\u002Fvar\u002Flib\u002Fpostgresql\u002F17\u002Fdata \\\n  --new-datadir=\u002Fvar\u002Flib\u002Fpostgresql\u002F18\u002Fdata \\\n  --old-bindir=\u002Fusr\u002Flib\u002Fpostgresql\u002F17\u002Fbin \\\n  --new-bindir=\u002Fusr\u002Flib\u002Fpostgresql\u002F18\u002Fbin \\\n  --link\npg_ctl -D \u002Fvar\u002Flib\u002Fpostgresql\u002F18\u002Fdata start\nvacuumdb --all --analyze-in-stages\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>\u003Cstrong>Replication logique (zero temps d’arret) :\u003C\u002Fstrong> Configurez la replication logique de PG 17 vers PG 18, attendez la synchronisation, puis basculez la chaine de connexion de votre application.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Services manages :\u003C\u002Fstrong> AWS RDS, Google Cloud SQL, Azure Database et Neon supportent tous les mises a niveau de version majeure avec un temps d’arret minimal.\u003C\u002Fp>\n\u003Ch2 id=\"faq\">FAQ\u003C\u002Fh2>\n\u003Ch3 id=\"postgresql-18-est-il-pret-pour-la-production\">PostgreSQL 18 est-il pret pour la production ?\u003C\u002Fh3>\n\u003Cp>Oui. PostgreSQL suit un processus de publication rigoureux. La version .0 est de qualite production. Attendre le patch .1 (generalement 2-3 mois apres le .0) est une strategie raisonnable pour les organisations averses au risque.\u003C\u002Fp>\n\u003Ch3 id=\"dois-je-passer-de-uuidv4-a-uuidv7-pour-les-tables-existantes\">Dois-je passer de UUIDv4 a UUIDv7 pour les tables existantes ?\u003C\u002Fh3>\n\u003Cp>Pour les nouvelles tables, utilisez uuidv7() par defaut. Pour les tables existantes, le cout de migration justifie rarement le benefice sauf si vous avez des problemes mesurables de gonflement d’index ou de cache miss.\u003C\u002Fp>\n\u003Ch3 id=\"le-nouveau-moteur-i-o-necessite-t-il-des-modifications-du-noyau\">Le nouveau moteur I\u002FO necessite-t-il des modifications du noyau ?\u003C\u002Fh3>\n\u003Cp>Le support io_uring necessite le noyau Linux 5.10 ou superieur. PostgreSQL 18 utilise un repli sur les threads de travail si le noyau est plus ancien.\u003C\u002Fp>\n\u003Ch3 id=\"peut-on-utiliser-les-colonnes-virtuelles-avec-pgvector\">Peut-on utiliser les colonnes virtuelles avec pgvector ?\u003C\u002Fh3>\n\u003Cp>Pas directement. Les embeddings pgvector sont generalement stockes. Vous pouvez utiliser une colonne virtuelle pour des metriques derivees comme \u003Ccode>vector_dims(embedding)\u003C\u002Fcode>.\u003C\u002Fp>\n\u003Ch3 id=\"comment-les-contraintes-temporelles-interagissent-elles-avec-le-partitionnement\">Comment les contraintes temporelles interagissent-elles avec le partitionnement ?\u003C\u002Fh3>\n\u003Cp>Les contraintes temporelles fonctionnent avec le partitionnement declaratif.\u003C\u002Fp>\n\u003Ch3 id=\"qu-en-est-il-des-ameliorations-de-merge\">Qu’en est-il des ameliorations de MERGE ?\u003C\u002Fh3>\n\u003Cp>PostgreSQL 18 etend MERGE avec le support de la clause RETURNING, completant l’ensemble de fonctionnalites introduit dans PG 15.\u003C\u002Fp>\n","fr","b0000000-0000-0000-0000-000000000001",true,"2026-03-28T10:44:46.653309Z","PostgreSQL 18 en profondeur — uuidv7, colonnes virtuelles, moteur I\u002FO asynchrone (2025)","Guide complet des fonctionnalites PostgreSQL 18 : moteur I\u002FO asynchrone (3x plus rapide), uuidv7() natif, colonnes virtuelles, authentification OAuth, contraintes temporelles et index skip-scan.","postgresql 18 fonctionnalites",null,"index, follow",[22,27],{"id":23,"name":24,"slug":25,"created_at":26},"c0000000-0000-0000-0000-000000000012","DevOps","devops","2026-03-28T10:44:21.513630Z",{"id":28,"name":29,"slug":30,"created_at":26},"c0000000-0000-0000-0000-000000000005","PostgreSQL","postgresql","Engineering",[33,40,46],{"id":34,"title":35,"slug":36,"excerpt":37,"locale":12,"category_name":38,"published_at":39},"d0000000-0000-0000-0000-000000000677","Pourquoi Bali devient le hub impact-tech d'Asie du Sud-Est en 2026","pourquoi-bali-devient-hub-impact-tech-asie-sud-est-2026","Bali se classe 16e parmi les écosystèmes startups d'Asie du Sud-Est. Avec une concentration croissante de bâtisseurs Web3, de startups IA durables et d'entreprises eco-travel tech, l'île se forge une identité de capitale impact-tech de la région.","Ingénierie","2026-03-28T10:44:49.517126Z",{"id":41,"title":42,"slug":43,"excerpt":44,"locale":12,"category_name":38,"published_at":45},"d0000000-0000-0000-0000-000000000676","Le patchwork de la protection des données ASEAN : checklist de conformité pour les développeurs","patchwork-protection-donnees-asean-checklist-conformite-developpeurs","Sept pays de l'ASEAN disposent désormais de lois complètes sur la protection des données, chacune avec des modèles de consentement, des exigences de localisation et des structures de sanctions différents. Voici une checklist pratique de conformité pour les développeurs.","2026-03-28T10:44:49.504560Z",{"id":47,"title":48,"slug":49,"excerpt":50,"locale":12,"category_name":38,"published_at":51},"d0000000-0000-0000-0000-000000000675","La transformation numérique de 29 milliards de dollars d'Indonesia : opportunités pour les éditeurs de logiciels","transformation-numerique-29-milliards-dollars-indonesia-opportunites-editeurs-logiciels","Le marché des services informatiques d'Indonesia devrait atteindre 29,03 milliards de dollars en 2026, contre 24,37 milliards en 2025. L'infrastructure cloud, l'IA, le e-commerce et les centres de données tirent la croissance la plus rapide d'Asie du Sud-Est.","2026-03-28T10:44:49.469231Z",{"id":13,"name":53,"slug":54,"bio":55,"photo_url":19,"linkedin":19,"role":56,"created_at":57,"updated_at":57},"Open Soft Team","open-soft-team","The engineering team at Open Soft, building premium software solutions from Bali, Indonesia.","Engineering Team","2026-03-28T08:31:22.226811Z"]