Войти

Обзор архитектуры

Stable

Основные компоненты SPG99 и их роли: кто управляет ресурсами, кто принимает подключения, где живут данные и как работает новый autoscaler.

Обновлено: 21 марта 2026 г.

Архитектура SPG99 построена вокруг очень важного принципа: compute и durable storage разделены. Это позволяет платформе быстро запускать PostgreSQL по требованию и при этом не превращать каждую базу в “вечный stateful pod”.

Главные компоненты

  • Control Plane — каталог ресурсов, API‑ключи, lifecycle базы, leases, autoscaler и orchestration.
  • Console — пользовательский web‑интерфейс поверх Control Plane API.
  • Gateway — единая PostgreSQL‑точка входа по TLS, встроенный pooler и безопасный роутер к текущему writer.
  • Provisioner — материализует решение “нужно поднять writer” в реальный compute‑pod.
  • Compute / Agent — поднимает PostgreSQL и исполняет SQL.
  • Pageserver — хранит историю и отдаёт soft basebackup / startup‑состояние.
  • Safekeeper — контур WAL‑надёжности; именно он делает подтверждённые записи durable.
  • Object Storage — хранение layers и служебных storage‑артефактов.
  • Prometheus / Grafana / Loki — метрики, логи и эксплуатационная диагностика.

Что изменилось в текущем контракте

В новой версии платформы compute перестал быть местом, где локально лежит почти полный рабочий набор пользовательских файлов. Теперь на pod остаётся только минимум для быстрого старта PostgreSQL.

Практически это означает:

  • старт writer идёт через soft basebackup;
  • Pageserver отдаёт тонкий startup‑образ;
  • пользовательские relation pages дочитываются лениво при локальном miss;
  • локальный диск compute — это быстрый write‑back cache, а не долговечное хранилище.

Как это выглядит для пользователя

Console / API client
    -> Control Plane
    -> Gateway
    -> Compute
    -> Pageserver + Safekeeper

Из этой схемы следуют четыре практических свойства SPG99:

  1. База может быть в stopped, и это нормально.
    Это означает только то, что compute сейчас не расходует ресурсы.

  2. Первое подключение после простоя может быть чуть дольше.
    Платформа должна поднять writer и довести его до ready.

  3. Остановка compute не равна потере данных.
    Durable‑состояние базы живёт глубже — в Pageserver + Safekeeper + object storage.

  4. Смена профиля writer идёт через безопасный handoff, а не через рискованный live resize.
    Платформа готовит новый candidate, затем переводит на него трафик через controlled cutover.

Почему эта архитектура удобна

  • create/connect‑сценарий остаётся быстрым;
  • простаивающий compute не расходует ресурсы постоянно;
  • cold start ускоряется за счёт soft basebackup и тонкого startup‑образа;
  • автоскейлер работает предсказуемо и не ломает durability;
  • безопасность и наблюдаемость централизованы на уровне платформы.

Именно поэтому SPG99 хорошо подходит для serverless‑сценариев, dev/test, bursty‑нагрузки и production‑эксплуатации, где важны скорость запуска, прозрачность и надёжность.

Почему SPG99АрхитектураПлан развитияДокументацияБлог