Как SPG99 удерживает один DSN и не теряет состояние при остановке compute

Главный принцип — приложение не должно замечать внутренние переходы жизненного цикла. Поэтому снаружи у базы есть один стабильный DSN, через который она доступна и в активном состоянии, и после периода idle.

SPG99 держит эту точку входа отдельно от worker, который реально исполняет PostgreSQL-процессы. Для клиента это означает, что строка подключения не меняется каждый раз, когда compute был остановлен и затем поднят заново.

Если бы состояние базы жило только внутри текущего compute-узла, любая остановка worker означала бы риск потери данных или сложный процесс восстановления. Поэтому в SPG99 долговечное состояние базы отделено от текущего исполняющего узла.

Worker можно безопасно остановить, пересоздать или заменить, потому что источник истины для данных находится отдельно. Именно это делает auto-stop штатным состоянием архитектуры, а не опасным трюком для экономии бюджета.

Когда приходит первое подключение после периода idle, платформа не меняет DSN и не просит клиента искать новый endpoint. Вместо этого Gateway принимает соединение, Control Plane поднимает нужный compute, а затем трафик переводится в рабочее состояние.

С точки зрения приложения это выглядит как привычное подключение к PostgreSQL с тем лишь отличием, что после простоя нужно учитывать разумный connect_timeout и retry. Это ожидаемое поведение для любой системы с cold start.

Разделение entrypoint, lifecycle compute и durable storage даёт сразу несколько эффектов:

• для приложения сохраняется обычная модель подключения к PostgreSQL;
• команде не нужно вручную включать и выключать временные базы;
• worker можно останавливать без смены DSN;
• восстановление после idle становится управляемым и предсказуемым;
• архитектура остаётся пригодной для automation через Console и API.

Именно поэтому SPG99 подходит не только как способ сэкономить, но и как способ убрать ручную эксплуатацию временных окружений.