Холодный старт и поведение при idle

SPG99 оптимизирован под модель serverless compute: активный PostgreSQL‑исполнитель не нужно держать включённым постоянно, потому что durable‑состояние БД живёт отдельно от конкретного Compute.

Что такое cold start

Cold start происходит, когда для БД нет активного writer (state=stopped, target_scale=0) и клиент инициирует новое подключение через Gateway.

В этот момент выполняется полноценный платформенный сценарий:

• Gateway инициирует автозапуск через Control Plane;
• Provisioner поднимает Compute;
• Compute подготавливает TLS и managed‑конфиг;
• Pageserver отдаёт soft basebackup — тонкий startup‑образ вместо тяжёлого полного локального restore;
• PostgreSQL запускается на минимальном локальном наборе файлов;
• пользовательские relation pages дочитываются лениво по мере обращения;
• проверяется доступность storage‑зависимостей, включая Safekeeper quorum;
• БД выходит в ready.

Почему cold start теперь быстрее и ровнее

Ключевое изменение в новой модели такое: на поде больше не нужно держать почти полный рабочий набор пользовательских relation files.

Теперь локально остаются только:

• стартовый минимум для PostgreSQL;
• managed‑конфиги и служебное состояние;
• быстрый write‑back cache.

Практический эффект:

• под стартует быстрее;
• меньше локального дискового шума;
• restart‑path предсказуемее;
• storage‑контур остаётся единым источником истины.

Почему stopped — это нормально

В SPG99 локальный PGDATA Compute — это рабочий кэш, а не единственное место хранения данных. Поэтому stopped — штатное состояние serverless‑модели:

• Compute можно безопасно остановить;
• pod может быть пересоздан;
• при следующем запуске база восстанавливает рабочее состояние из storage‑контура;
• данные не теряются, если durable‑слой платформы в порядке.

Idle stop

Чтобы не держать Compute без нагрузки, платформа автоматически останавливает БД при простое.

Обычно это выглядит так:

• Gateway перестаёт удерживать lease;
• Control Plane видит, что активных сессий больше нет;
• после idle_timeout база переводится в stopped;
• следующая попытка подключения снова разбудит её автоматически.

Что важно сделать в приложении

1. Делайте retry на connect. Для первой попытки после stopped это обязательная практика.
2. Держите connect_timeout хотя бы 5–10s.
3. Закладывайте общий дедлайн на подключение с учётом retry примерно 20–30s.
4. Если нужен ровный пик latency, сделайте обычный прогревающий connect незадолго до нагрузки.
5. Не держите много “висящих” idle‑соединений — они мешают auto‑stop и ухудшают эффективность pooling.

Когда cold start может быть заметнее

Запуск может занять больше обычного, если:

• storage‑контур под нагрузкой;
• база давно не запускалась;
• одновременно стартуют несколько БД;
• идёт переходное autoscale‑состояние;
• есть pinned/session трафик, который мешает platform lifecycle в нужный момент.

В таких случаях правильная реакция — смотреть метрики, логи и scale_state, а не пытаться лечить проблему ручным start.