PostgreSQL 18: п’ять змін, які варто перевірити на вашій базі

PostgreSQL 18 вийшов 25 вересня 2025 року. Його release notes поєднують кілька незалежних напрямків: asynchronous I/O для частини операцій читання і vacuum, B-tree skip scan, timestamp-ordered uuidv7(), virtual generated columns, OAuth support та temporal constraints. [1] Це не одна велика функція, яку можна увімкнути чекбоксом. Це набір нових можливостей, кожну з яких треба зіставити зі схемою, планами запитів і операційним середовищем.

Найгірший спосіб оцінити оновлення звучить як «Postgres 18 у три рази швидший». PostgreSQL Project повідомляє про до 3× прискорення в окремих I/O-сценаріях, але це результат конкретних умов читання зі сховища. [2] Запит, який упирається в CPU, блокування, мережу, поганий індекс або повільний upstream, від цього автоматично не зміниться.

Хороший привід оновитися інший: у вас є чіткий клас болю, який реліз потенційно зачіпає. Наприклад, великі scans і vacuum, random UUID як primary key у таблиці з активними insert, запити за не-першою колонкою складеного B-tree, або потреба під’єднати клієнт до корпоративного OAuth-потоку.

Кожна можливість нижче має зрозумілий тест. Якщо такого тесту немає, її краще не робити головною причиною для upgrade.

UUIDv4 зручний як розподілений ідентифікатор, проте його випадковий порядок розкидає нові записи по всьому B-tree. uuidv7() додає часову складову, тому нові значення переважно рухаються в одному напрямку. PostgreSQL 18 постачає цю функцію з коробки. [1] Це часто кращий default для нових зовнішніх ідентифікаторів, ніж самостійна extension або прикладний генератор UUIDv7.

Слово «переважно» тут важливе. UUIDv7 не дає гарантію абсолютної послідовності за кожного паралельного запису, не вирішує contention на гарячому індексі та не замінює продуманий partitioning. Він просто дає ключ, у якому порядок часу краще узгоджується з порядком вставок. Виграш слід шукати в реальних метриках write path, а не в красивому форматі ID.

Для старої системи найспокійніший варіант часто гібридний: історичні UUID лишаються, а нові таблиці або нові сутності використовують UUIDv7. Масова заміна primary key зачіпає foreign keys, кеші, API-контракти, реплікацію й резервні процеси. Реліз бази сам по собі не створює причини брати цей ризик.

PostgreSQL вказує три основні шляхи переходу між major versions: dump/restore, pg_upgrade або logical replication. [1] Вибір залежить від допустимого downtime, розміру даних і вимог до rollback.

PostgreSQL 18 додає OAuth support, а libpq реалізує optional Device Authorization client flow. [3] Це корисно для середовищ, де доступ до бази має проходити через корпоративну ідентичність, scopes і короткоживучі токени. Але не кожен драйвер і спосіб підключення отримає цю підтримку одночасно, тому compatibility test є обов’язковим.

Паралельно реліз продовжує рух від md5 password authentication: підтримку MD5 планують прибрати в одному з майбутніх major releases. [1] Для команд це гарний момент перевірити, чи всі клієнти працюють зі SCRAM, де лежать credentials, як ротується доступ і які сервісні акаунти досі обходять звичайні правила.

PostgreSQL 18 дає достатньо причин поставити upgrade у roadmap. Найсильніші з них будуть різними для різних систем: десь це I/O та maintenance, десь UUIDv7 для нових write-heavy таблиць, десь складені індекси, а десь OAuth. Жодна з цих причин не скасовує потребу в staging і baseline.

Після пілоту результат має бути конкретним: оновлюємося, бо критичні scans стали дешевшими; беремо UUIDv7 лише для нових таблиць; лишаємо поточні індекси; відкладаємо OAuth до готовності клієнтів. Такий список рішень корисніший за загальний висновок, що нова версія «швидша».