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()