Чому Neon serverless PostgreSQL впирається в ліміти підключень
Serverless-модель Neon приваблює тим, що база сама підлаштовується під навантаження і не потребує ручного адміністрування.
Вузьке місце проявляється не в середньому режимі, а на піках: коли одночасно надходять запити від користувачів, фонової обробки та звітів, застосунок впирається в ліміт підключень до бази, хоча обчислювальних ресурсів у неї ще в запасі.
Пастка закладена в самому пулі з’єднань. Кожен екземпляр застосунку тримає свої сесії, і при горизонтальному масштабуванні їхня кількість зростає лінійно: десять інстансів по десять з’єднань — це вже сотня підключень.
Щойно сумарний пул перевищує допустиму межу, нові запити не відкривають сесію, а падають з помилкою підключення — при повністю працездатному сервісі.
Другий сценарій — пауза бази даних при простої. Уночі або в міжсезоння трафік падає, обчислювальний вузол переходить у сплячий режим, і перший запит після паузи чекає на пробудження замість відповіді. Користувач отримує помилку або помітну затримку, а підтримка — хибну тривогу «база недоступна».
Обидва сценарії спрацьовують в одні й ті самі години — у пік, коли від секунди відповіді залежить виручка. Нестача з’єднань у застосунку запускає повторні спроби, ті підсилюють навантаження, і частина запитів обривається через час очікування.
Розбираємо, як це закривається налаштуванням пулу, режиму пробудження та розмежуванням ролей — без відмови від serverless-підходу.
Гілки Neon: ізольовані бази для розробки, тестів і перевірок
Гілка бази даних у Neon — це клон за принципом копіювання при записі: при гілкуванні переносяться не самі рядки, а посилання на сторінки, тому дочірня база з’являється за секунди незалежно від обсягу.
Далі зміни пишуться тільки в неї, а видалення гілки звільняє лише ті сторінки, які в ній реально правилися.
Така модель дає ізольовані середовища розробки на кожну задачу, перевірку або експеримент. Міграції та важкі вибірки проганяються на копії бойових даних, не зачіпаючи основну базу, а стан на потрібний момент відтворюється повторним гілкуванням від будь-якої точки.
Час підготовки середовища падає з годин на розгортання дампа до секунд: розробник і тестувальник отримують копію з актуальною схемою, не чекаючи, поки звільниться спільний стенд. Паралельні перевірки йдуть одночасно і не блокують одна одну.
Прогрів бази перед навантаженням перестає бути окремою процедурою: гілку піднімають заздалегідь, проганяють типові запити, щоб плани виконання та кеш сторінок вийшли в робочий стан, і тільки потім знімають заміри. Без прогріву перші звернення йдуть за холодними планами і спотворюють картину.
Тривалість простою сервісу при випуску скорочується завдяки тому, що міграції відпрацьовані на реалістичному обсязі даних, а не на порожній схемі. Якщо щось пішло не так, відкат — це перемикання на попередню гілку, а не відновлення з резервної копії.
Порівняння варіантів підключення: пряме, через пул і через проксі
Serverless-функції та контейнери відкривають з’єднання на кожен запуск, а PostgreSQL обслуговує кожне з’єднання окремим процесом. На піку короткоживучі клієнти вичерпують ліміт підключень, і застосунок отримує відмову замість відповіді.
Вибір режиму підключення — це компроміс між кількістю одночасних клієнтів і сумісністю зі звичним кодом.
На практиці варіантів три: пряме підключення до бази, пул з’єднань і проміжний шар підключень. Вони не взаємовиключні — для міграцій і фонових задач розумно тримати окремий рядок підключення.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Пряме підключення до бази | Міграції, фонові задачі, довгі аналітичні запити, налагодження | Один клієнт — один процес на сервері; ліміт підключень вичерпується швидко |
| Пул з’єднань, транзакційний режим | Веб-запити та виклики serverless-функцій: багато коротких операцій | З’єднання закріплюється лише на час транзакції — недоступні підготовлені вирази, advisory locks, LISTEN/NOTIFY, тимчасові таблиці сесії |
| Пул з’єднань, режим сесії | Код, який тримає стан сесії та підготовлені вирази | З’єднання зайняте до відключення клієнта, тому виграш за кількістю клієнтів менший |
| Проміжний шар підключень | Периферійні обчислення, де дороге кожне нове з’єднання | Один запит на виклик, без інтерактивних транзакцій і курсорів |
Вибір режиму підключення задається профілем навантаження: довгим задачам — пряме підключення, прикладним запитам — пул у транзакційному режимі, коротким викликам на периферії — проміжний шар.
Рядки підключення розрізняються параметрами, тому перемикання режиму не вимагає переписувати код застосунку.
Порядок робіт: від аудиту запитів до передачі регламентів
Роботу починаємо з аудиту, а не з налаштування: знімаємо статистику за планами виконання запитів, шукаємо послідовні сканування на великих таблицях і з’єднання, які тримаються помітно довше за типовий запит застосунку.
Паралельно розбираємо схему даних — типи полів, обмеження цілісності, історію міграцій: частина просідань лежить не в запитах, а в структурі таблиць.
-
Аудит запитів і схеми даних. Збираємо топ запитів за часом і частотою, позначаємо ті, чий час зростає лінійно від обсягу даних, фіксуємо розміри таблиць та індексів, ліміти підключень.
-
Проєктування схеми бази. Приводимо типи до фактичних даних, додаємо відсутні індекси та обмеження, розносимо гарячі й аналітичні операції, щоб важкі вибірки не конкурували із запитами користувачів.
-
Налаштування середовища. Задаємо розмір обчислювального вузла та політику призупинення, пул підключень, репліки для читання; під розробку й тести заводимо окремі гілки бази в Neon — експерименти не торкаються робочої.
-
Перевірка на відмову. Проганяємо пікове навантаження, відмову вузла, обрив з’єднань і відновлення на момент часу; фіксуємо час відновлення та запити, які деградують першими.
-
Регламент міграцій. Описуємо застосування змін схеми без довгих блокувань, порядок відкату та перевірку цілісності після кожної міграції.
-
Передача в експлуатацію. Віддаємо конфігурації, схему, метрики для моніторингу, інструкції з відновлення та порядок ескалації, розбираємо все з командою замовника.
На виході у команди залишається відтворювана конфігурація та регламенти, а не ручні дії, які тримаються в голові одного інженера.
Що передаємо на руки: схеми, ролі, політики, регламенти
Передача бази — це не видача доступу до консолі, а комплект, за яким ваша команда сама підніме копію стенда, накотить міграцію та відновить дані без листування з нами.
Нижче — що саме фіксуємо в репозиторії проєкту та в документації: від опису схеми до регламенту резервного копіювання. Гілка в Neon для перевірки міграцій заводиться зі знімка — перевірка йде на копії бойових даних, а не на порожній базі.
- Схема даних і міграції — версіоновані SQL-файли в порядку застосування, окремі сценарії для чистого розгортання та для накочування на наявну базу, журнал застосованих версій у службовій таблиці.
- Конфігурація підключення застосунку — параметри рядка з’єднання для пулу та для службових підключень, розділення читання й запису, змінні середовища під кожен стенд, вимоги до таймаутів і повторних спроб при обриві.
- Політики доступу та ролі — перелік ролей: власник схеми, застосунок, аналітика лише на читання, черговий; межі прав на рівні таблиць і послідовностей, заборона спільних облікових записів.
- Регламент резервного копіювання — розклад знімків, термін зберігання, порядок перевірки відновлення та допустима точка втрати даних для кожного контуру.
- Документація щодо бази — опис сутностей і зв’язків, призначення службових таблиць, перелік важких запитів та індексів під них, відомі обмеження.
- Сценарій відновлення — покрокова інструкція з перевіркою цілісності та відкатом на попередній знімок, відпрацьована на стенді.
- Карта спостережуваності — які показники підключень, затримок і помилок на що сигналять і кому.
Кожен пункт ми приймаємо разом із вашим інженером: він проходить за списком, сам піднімає стенд із наших файлів і відновлює базу. Якщо щось не відтворюється за документацією — пункт не закритий.
Кейс: розділили середовища та прибрали відмови при піковому навантаженні
До розділення прод, тест і прев’ю-контури жили в одній базі: спільна схема, спільний ліміт обчислень, один пул з’єднань. Міграції тестової задачі змінювали таблиці, якими вже користувалися клієнти, а на вечірньому піку частина запитів відвалювалася за таймаутом.
За квартал набралося близько 40 інцидентів, а відновлення після невдалого релізу займало 40-60 хвилин: розгорнути дамп, звірити схему, наздогнати дані.
Що змінили
Налаштували Neon так, щоб кожне середовище отримало окрему гілку бази: прод, тест і гілка на кожну задачу в розробці. Гілка створюється копіюванням стану на рівні сховища — без вивантаження й завантаження дампа, тому середовище під перевірку піднімається за хвилини.
Обчислення масштабуються під навантаження і зупиняються на неактивних гілках, а пул підключень тримається на боці сервісу й не витрачається на короткі з’єднання.
Доступи розвели за ролями: прод-гілку бачить тільки чергова зміна, міграції йдуть через окремий контур із бекапом гілки перед прогоном.
Що вийшло
Через два місяці експлуатації: відмови за таймаутами на піку — нуль замість 5-6 на тиждень, частка успішних запитів зросла з 97,2% до 99,98%.
Час відновлення після збою скоротився приблизно у 20 разів — з 40-60 хвилин до 2-3: повернення до попереднього стану гілки замість розгортання дампа. Підготовка середовища під задачу — 5 хвилин замість двох днів очікування та ручного складання.
Середовище перевірки тепер повторює прод за даними та схемою, тому розбіжності між тестом і продом перестали бути джерелом сюрпризів. Схема витримала сезонний пік утричі вищий за звичайний трафік без розширення інфраструктури.
Чим керована база відрізняється від розгорнутого вручну екземпляра
Різниця не в самому PostgreSQL — движок той самий. Різниця в тому, хто тримає експлуатаційний контур: керована база бере на себе відмовостійкість, резервні копії, оновлення та масштабування під навантаження, а самостійний екземпляр залишає це команді.
Керований контур виграє там, де середовищ більше одного: гілкування бази дає окрему копію даних під кожну задачу, а неактивні середовища засинають самі. Наприклад, Neon у serverless-режимі знімає з інженера складання тестових стендів — вони створюються з гілки за хвилини.
| Варіант | Хто відповідає за інфраструктуру | Трудовитрати |
|---|---|---|
| Керований сервіс | постачальник: копії, відмовостійкість, оновлення | години на місяць |
| Екземпляр на орендованому сервері | команда: патчі, реплікація, копії, спостереження | чергування та планові вікна |
| Власний кластер | команда та інфраструктурний відділ | окрема роль у штаті |
Самостійне обслуговування бази — не разове налаштування, а постійний цикл: оновлення безпеки, перевірка відновлення з копії, контроль зростання таблиць і місця на диску, розбір деградації запитів. Окремо кожен пункт невеликий, разом це регулярне навантаження, яке не закінчується після запуску.
Зона відповідальності підрядника за будь-якого варіанта одна: схема даних, індекси, повільні запити, міграції без простою, права доступу. Змінюється тільки те, хто відповідає за шар нижче — сервіс і залізо. Вибір тут не про якість, а про те, де команда готова тримати постійну відповідальність.
Сумніви при переході: сумісність, міграція, відкат
Сумніви при перенесенні рідко пов’язані з самим serverless-підходом — важливіше не втратити робочі дані та мати передбачуваний шлях назад. До перемикання фіксуємо три речі: як переноситься база, що з розширеннями і які права залишаються у застосунку.
Як перенести робочу базу з мінімальним простоєм?
Основний шлях — логічна реплікація: цільова база включається в потік змін і наздоганяє джерело, трафік перемикається тільки після цього. Відставання контролюємо до секунд, потім звіряємо кількість рядків у ключових таблицях і контрольні суми. Запис зупиняється на хвилини — на фінальний догін і зміну рядків підключення.
Чи підтримуються потрібні розширення?
Набір доступних розширень у керованому сервісі вужчий, ніж на власному сервері. До міграції звіряємо встановлені розширення зі списком підтримуваних: що не підтримано — переносимо в застосунок або залишаємо на керованому кластері. Окремо перевіряємо повнотекстовий пошук і типи, які розширення підміняють своїми.
Чи залишаться у застосунку права змінювати схему?
Права розділяємо: застосунок працює під роллю з доступом до даних, схему змінює окрема міграційна роль. Міграції застосовуються версіоновано і проганяються на копії бази до продакшену — сервіс не править таблиці при старті й не ламає сумісність із попередньою версією коду.
Що як доведеться повернутися назад?
План відкату фіксується до початку робіт: вихідна база залишається робочою, зворотна реплікація живе, поки нова платформа не відпрацює повний цикл навантаження.
Точка неповернення — відключення зворотного потоку: до неї повернення займає стільки ж, скільки пряме перемикання, після — відновлення з копії.
Обговоримо задачу: зберемо схему й повернемося з оцінкою та планом
Щоб повернутися з оцінкою термінів і планом робіт по базі, нам не потрібен повний доступ до всього проєкту — достатньо вхідних даних, які визначають архітектуру зберігання. Нижче короткий перелік: якщо якийсь пункт поки не сформульовано, обговоримо задачу й додамо відсутнє разом.
- Схема даних і обсяг: основні таблиці, зв’язки між ними, оціночна кількість рядків у найбільших і швидкість їхнього зростання.
- Профіль навантаження: пікова та середня частота запитів на читання й запис, кількість одночасних з’єднань, вимоги до часу відповіді на критичних екранах.
- Сценарії доступу: звідки йдуть підключення — серверний застосунок, фонові задачі, звітність, адміністративні скрипти; чи потрібна роздільна ізоляція ролей і прав.
- Робота з версіями схеми: де живуть міграції, як застосовуються, чи є відпрацьований порядок повернення до попереднього стану.
- Вимоги до збереженості даних: глибина відновлення на довільний момент, регулярність перевірки резервних копій, допустиме вікно недоступності при відновленні.
- Розміщення та доступи: де знаходяться користувачі й сервіси, чи потрібні окремі копії бази під розробку, передрелізну перевірку та розбір інцидентів.
Повертаємося не оцінкою «на словах»: показуємо схему розміщення, налаштування пулу з’єднань і режиму призупинення простоюючої бази, план міграцій та порядок перевірки після перемикання.
Для проєктів на Neon окремо проговорюємо, як гілки бази й автомасштабування лягають на ваш профіль навантаження — від цього залежать і схема, і терміни.
Опишіть задачу — повернемося з оцінкою та планом робіт.
