Жизненный цикл базы в SPG99: active, idle, wake-up

Для повседневной эксплуатации достаточно различать три состояния:

Эта модель проста, но она закрывает почти все реальные вопросы эксплуатации: когда платить за compute, когда ожидать cold start и в какой момент retry является штатным поведением.

Приложению не нужен отдельный режим «работы с serverless PostgreSQL», но полезно заложить несколько стандартных практик:

• разумный connect_timeout;
• retry на первое подключение после простоя;
• таймауты и pool-настройки без предположения, что compute активен всегда;
• корректное логирование неудачных первых попыток соединения.

Это не специфично только для SPG99 — это обычная инженерная дисциплина при работе с системами, у которых есть переходы жизненного цикла.

Чтобы модель оставалась предсказуемой, команде полезно заранее договориться о нескольких правилах:

• какие окружения действительно можно переводить в auto-stop;
• какие SLO допустимы для первого подключения после периода idle;
• какие migration и batch-job сценарии должны запускаться только после успешного wake-up;
• какие dashboards и алерты показывают частоту wake-up и фактическое время простоя.

Когда эти правила определены, lifecycle базы перестаёт быть «магией» и становится обычной частью эксплуатации.

Идея не в том, чтобы обязательно остановить всё подряд. Цель — отключать compute там, где это безопасно и выгодно. Поэтому зрелая эксплуатация всегда начинается с классификации окружений, а не с глобального правила для всех баз одновременно.