Мінорні оновлення (17.4 → 17.6) - лише виправлення помилок: досить оновити пакет і перезапустити сервер. Формат даних не змінюється.
Мажорні (16 → 17 → 18) змінюють внутрішній формат зберігання, тож файли даних старої версії нова прочитати не може. Є три способи:
1. pg_dump + відновлення - найпростіше й найнадійніше:
pg_dump -Fc -d app > app.dump
# новий сервер
pg_restore -d app app.dump
Простій - на весь час дампу й відновлення з перебудовою індексів. Для бази в кілька гігабайтів - нормально, для терабайтів - години.
2. pg_upgrade - перетворює каталог даних «на місці»:
pg_upgrade --old-datadir ... --new-datadir ... --old-bindir ... --new-bindir ... --link
З --link файли даних не копіюються, а використовуються жорсткі посилання - оновлення займає хвилини навіть для великих баз. Обов'язково спершу --check (сухий прогін). Після оновлення потрібна статистика для планувальника (vacuumdb --analyze-in-stages); з PostgreSQL 18 pg_upgrade уміє переносити її сам.
3. Логічна реплікація - майже без простою: новий сервер на новій версії підписується на зміни старого, наздоганяє його, і застосунок перемикається за секунди. Найскладніше в налаштуванні: послідовності й зміни схеми не реплікуються, їх переносять окремо.
Як підготуватися:
- Прочитати release notes усіх мажорних версій між поточною й цільовою - розділи про несумісності.
- Перевірити, що розширення (PostGIS, pgvector тощо) доступні для нової версії.
- Прогнати тести застосунку на новій версії, відрепетирувати оновлення на копії продакшн-даних, виміряти час.
- Мати свіжий бекап і план відкату.
На керованих сервісах (RDS, Cloud SQL) мажорне оновлення - кнопка, але простій і перевірки сумісності ті самі - про них варто подбати заздалегідь.
