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

[boris_null45]

Вышел 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 крутится на своём железе (не облако).

[ksenia_py40]

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

[lev_loop]

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

[egor9725]

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

[makar_root]

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

[devbyte8767]

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

[makar_app]

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