PostgreSQL 18 — стоит ли уже переходить или ждать 18.1?

[terraform91]

Вышел PostgreSQL 18 (25 сентября 2025), у нас сейчас прод на 16.9. Смотрю на фичи: асинхронный I/O, skip scan на B-tree индексах, uuidv7(), virtual generated columns, поддержка OR в WHERE через индекс. Звучит вкусно. Кто уже щупал в проде или хотя бы на стейджинге? Стоит ли прыгать сразу или подождать пока 18.x поживёт подольше? У нас ~500 GB OLTP-база, около 800 коннектов через pgbouncer, PostgreSQL крутится на своём железе (не облако).

[pythonfan]

Мы переехали на 18.0 в феврале, сейчас на 18.2. Субъективно — прирост на чтении заметен, особенно на bitmap heap scan. Асинхронный I/O реально даёт эффект если у вас NVMe — в нашем случае latency на тяжёлых аналитических запросах упала примерно на 30-35%. OLTP особо не изменился, там и так всё было быстро. pg_upgrade прошёл штатно, флаг --jobs 8 сильно ускорил процесс. Единственный сюрприз: несколько расширений из apt-репозитория на 18 ещё не были в момент выхода, пришлось ждать пакеты неделю.

[marianna]

Я бы не спешил. 18.0 вышел в сентябре, первые патчи уже были (18.1, 18.2). Если прод критичный — дождитесь хотя бы 18.3, это обычная разумная политика. Фича с сохранением статистики планировщика через major upgrade — реально полезная, мы на 17 после апгрейда неделю ловили план-регрессии пока статистика не набралась заново.

[readsho]

@pythonfan, uuidv7() это лучшее что придумали за последние годы. Выбрасываем наконец gen_random_uuid() и uuid_generate_v4(). Монотонно растущий UUID — индексы больше не фрагментируются как бешеные. Проверил: на таблице 200M строк новые INSERT стали на 18% быстрее просто за счёт меньшей фрагментации B-tree. Советую хотя бы под новые таблицы сразу использовать uuidv7.

[matguyvr]

Насчёт OR через индекс — это огонь. У нас был запрос вида WHERE status = 'active' OR status = 'pending' который всегда делал seq scan на 50M строк несмотря на индекс по status. PostgreSQL 18 наконец начал использовать index scan для такого. Время запроса с 4.2 секунды упало до 80 мс. Буквально одно обновление без изменения кода.

[Farkle]

Для вашего сценария (своё железо, pgbouncer, 800 коннектов) — асинхронный I/O даст больше всего если диски быстрые. На обычных SATA SSD разница небольшая, на NVMe — существенная. Проверьте через pg_test_timing и смотрите на checkpoint_completion_target и wal_compression, их в 18 тоже немного докрутили. Ещё: OAuth-аутентификация наконец нативная, если у вас SSO на подходе — приятный бонус.

[postgres2]

Мы в июне переехали с 16 на 18.4 — всё прошло чисто. Главный совет: запускайте pg_upgrade с --check сначала, он сейчас работает параллельно и быстро находит проблемы. У нас нашёл один deprecated тип данных в одной вьюхе, поправили за 5 минут. Downtime составил 40 минут на базе 380 GB. Skip scan действительно работает — проверяйте explain analyze после миграции, некоторые запросы могут получить новый, более быстрый план.

[juniorphoenix]

Добавлю момент, который тут не прозвучал: асинхронный I/O в 18 по умолчанию работает через io_method = worker, а io_uring надо включать руками и он требует свежего ядра. Те самые красивые 30% на чтении люди обычно получают именно на io_uring + NVMe, на дефолтном worker эффект скромнее. Так что перед миграцией проверьте версию ядра на своём железе и погоняйте оба режима на стейджинге с реальным профилем нагрузки. И отдельно: с 800 коннектами через pgbouncer посмотрите на поведение idle_in_transaction — в 18 поменяли пару дефолтов вокруг таймаутов, после апгрейда стоит сверить конфиг построчно, а не тащить старый как есть.

[peopelle]

@readsho, uuidv7 топ, но одна оговорка: в нём первые 48 бит — это timestamp создания записи, то есть любой, кто видит ID, видит и когда сущность создана, плюс по двум ID можно прикинуть темп вставок. Для внутренних ключей плевать, а вот если UUID торчит наружу в URL — подумайте, не палите ли вы бизнес-метрики. Мы у себя так и разрулили: v7 в качестве PK, а наружу отдаём отдельный непрозрачный публичный идентификатор.

[FpgaDev]

@marianna, про перенос статистики через pg_upgrade — да, в 18 это спасает от той самой недели план-регрессий, но переносится только базовая статистика таблиц. Расширенная (CREATE STATISTICS на корреляции колонок) после апгрейда всё равно пустая, пока не прогонишь ANALYZE. Если у вас планы держатся на extended statistics — закладывайте окно на пересбор сразу после миграции, иначе наступите на те же грабли, что и на 17-й, просто в меньшем масштабе.