Neon Auto-Suspend

Коротко: Специфічна для Neon функція, за якої обчислювальний екземпляр бази даних автоматично «засинає» (вимикається) після періоду без запитів — заощаджує гроші, але означає, що найперший запит після простою триває довше, бо екземпляр спершу має знову запуститися («холодний старт»).

Докладніше: Як довго триває бездіяльність до засинання (тайм-аут auto-suspend) і чи можна його взагалі вимкнути («Always Active»), залежить від плану Neon — вищі плани дають змогу вимкнути цю поведінку.

Наш контекст: Визначено як можливу сприяльну причину періодичних збоїв Emzett, але не виправляється в коді — це налаштування проєкту Neon (Dashboard → Settings → Compute) або питання плану, а не відкритий технічний пункт у самому репозиторії.

Подробиці

Чому відбувається холодний старт

Холодний старт після пробудження відбувається тому, що Neon повністю зупиняє обчислювальний екземпляр (власне процес Postgres), а не просто призупиняє його — за наступного запиту цей процес потрібно перезапустити, і він має відновити свій стан (спільні буфери/кеші, пул з’єднань, можливо, тимчасові об’єкти), перш ніж зможе відповісти на перший запит. На більшості планів Neon цей холодний старт становить від кількох сотень мілісекунд до однієї-двох секунд — помітно, але зазвичай не драматично, доки кілька користувачів одночасно не натраплять на один процес, що прокидається, і не спричинять накопичення запитів (Neon ставить вхідні з’єднання в чергу на час пробудження, а не відхиляє їх одразу з помилкою — запити стають повільнішими, а не повністю провалюються).

Оскільки самі дані живуть окремо від обчислювального шару у власній системі зберігання (див. Neon), auto-suspend безпечний з погляду втрати даних — завершується лише обчислювальний процес, а не місце зберігання даних.

Порівняння з іншими системами «масштабування до нуля»

Споріднене поняття з тієї самої категорії «заощаджувати, масштабуючись до нуля» — безсерверні обчислення загалом (наприклад, самі Vercel Functions чи AWS Lambda) — там теж є холодні старти зі схожих причин (перш ніж відповідати на запити, потрібно запустити процес/контейнер). Відмінність від Neon: у типової безсерверної функції холодний старт зазвичай зачіпає лише ОДИН запит (кожен запит потенційно отримує свіжий екземпляр функції), тоді як за бази даних, що прокидається, затримка потенційно зачіпає УСІ одночасно надходячі запити, які чекають на одному з’єднанні з базою даних — адже на базу даних (гілку) припадає лише один обчислювальний екземпляр, а не довільно багато паралельних, як у безсерверних функцій.

Інші хмарні бази даних зі схожим принципом: AWS Aurora Serverless v2 динамічно масштабує обчислювальну потужність, але на відміну від Neon зазвичай не вимикається повністю до нуля (мінімальна потужність лишається активною — відповідно заощадження менші, але й справжнього холодного старту немає). PlanetScale (сумісна з MySQL через Vitess) має іншу модель масштабування без прямого аналога auto-suspend.

Як із цим упоратися на практиці

Тому, хто хоче/мусить уникнути холодних стартів (наприклад, для чутливих до затримок застосунків чи частих коротких пауз використання, що постійно запускають тайм-аут), по суті доступні три варіанти: збільшити тайм-аут auto-suspend у панелі (відкладає проблему, але не розв’язує її), перейти на план з опцією «Always Active» (повністю вимикає auto-suspend за вищу базову вартість) або штучно тримати базу даних «теплою» періодичним запитом перевірки стану (наприклад, виконувати тривіальний запит раз на кілька хвилин через cron) — останнє, однак, підриває головну цінову перевагу auto-suspend і самим Neon по-справжньому не рекомендується.

Див. також: Neon, React.cache()