Первая в России Serverless PostgreSQL‑платформа
spg99 поднимает и останавливает compute-узлы автоматически, хранит данные в S3-совместимом хранилище в РФ и управляет жизненным циклом БД через единый Control Plane. Вы создаёте БД одной командой — инфраструктура на нашей стороне.
| Tenant | DB | State | Last used | Timeline | Scale |
|---|---|---|---|---|---|
| t1 | d1 | READY | 10s ago | 00000001 | 1 |
| t1 | d2 | STOPPED | 2h ago | 00000002 | 0 |
Compute поднимается по запросу, данные хранятся в S3
Хранение — в S3-совместимом хранилище через связку Pageserver/Safekeeper, compute-узлы — одноразовые VM в Яндекс.Облаке. Control Plane ведёт каталог БД, управляет жизненным циклом compute и предоставляет единое API для операторов и CLI.
- Данные лежат в S3 + Pageserver/Safekeeper, а не на диске VM.
- Compute поднимается по запросу (auto start) и останавливается по idle (auto stop).
- Вы работаете с одной CLI-утилитой spgctl и REST API v2.
- Приложения видят один Gateway-endpoint и стандартный PostgreSQL-протокол.
spg99 решает задачи продуктовых команд, SaaS-платформ и внутренних сервисов с требованиями по размещению в РФ
Продуктовые команды и стартапы
Не нужно держать отдельного DBA и разбираться в тонкостях WAL, бэкапов и жизненного цикла VM. CLI + API — и готовая БД.
SaaS-платформы с десятками/сотнями БД
Для каждого клиента — отдельная БД/tenant, при этом compute не простаивает: idle-инстансы автоматически останавливаются.
Внутренняя аналитика и сервисы с требованиями по РФ
Размещение данных и бэкапов внутри РФ, инфраструктура — в Яндекс.Облаке, S3-совместимое хранилище.
Control Plane берёт на себя всю рутину вокруг PostgreSQL и инфраструктуры
- –Поднятие, обновление и патчинг PostgreSQL на VM.
- –Настройка WAL-стриминга, резервных копий и S3-хранилища.
- –Восстановление БД после падения compute.
- –Расчёт стоимости: отделяем оплату storage от compute, compute можно гасить по idle и не платить за простаивающие инстансы.
Платформа, построенная вокруг разделения storage и compute, auto start/stop и единого Control Plane
Storage и compute разделены по-взрослому
Данные лежат в S3 через Pageserver/Safekeeper. Compute-узлы — одноразовые VM: их можно пересоздавать сколько угодно, timeline при этом сохраняется.
Auto start/stop по подключению и idle
Первое подключение через Gateway автоматически поднимает VM. При отсутствии трафика Control Plane останавливает compute по политике idle.
Одна команда для создания БД
spgctl db create … или POST /v2/tenants/{t}/dbs. Профиль YC, образ, зону и размер подберёт Control Plane.
Единый Gateway-адрес для приложений
Приложения подключаются как к обычному Postgres по стандартному DSN. Gateway занимается маршрутизацией и оркестрацией scale.
Российская инфраструктура по умолчанию
Компоненты крутятся в Яндекс.Облаке, данные и WAL-архивы лежат в S3-совместимом хранилище в РФ.
Каноничная архитектура компонентов
Control Plane, Provisioner, Agent, Safekeeper, Pageserver, Gateway — роли разделены, операции стандартизированы, всё прозрачно для операторов.
Создание и запуск БД — простые команды в spgctl или REST-запросов к Control Plane. Приложение видит обычный PostgreSQL-DSN, а не детали Yandex.Cloud и S3.
# Логин под своим tenant
export SPG99_CP_URL=https://provisioner.spg99.ru
export SPG99_TOKEN=<acme-token>
# Создать tenant t1 (один раз)
spgctl tenant create t1
# Создать БД d1 в t1 без немедленного старта compute
spgctl db create \
--tenant t1 \
--name d1 \
--size dev-small \
--start-immediately=false
# Явно запустить compute
spgctl db scale --tenant t1 --db d1 --to 1
# Посмотреть состояние
spgctl db describe --tenant t1 --db d1
Исходники CLI spgctl: репозиторий с кодом, инструкциями по сборке и установке. Открывайте PR или берите готовый релиз.
curl -sS -X POST "$CP_URL/v2/tenants/t1/dbs" \
-H "Authorization: Bearer $ACME_TOKEN" \
-H "Content-Type: application/json" \
-d '{"name":"d1","size":"dev-small","start_immediately":false}' | jq .
Как работает spg99 под капотом
Восемь сервисов, одна платформа. Control Plane управляет жизненным циклом БД, Pageserver/Safekeeper отвечают за storage, Gateway — за входной PostgreSQL-протокол.
Control Plane — источник истины по tenants, db, timelines, state, scale и DSN.
Safekeeper/Pageserver превращают S3 в надёжный слой хранения WAL и page-слоёв для PostgreSQL.
Ведёт каталог БД (SQLite catalog.sqlite), хранит состояние (STOPPED/READY/…), реализует REST API v2 и управляет операциями scale 0↔1. Генерирует DSN, register-token и X.509 для воркеров.
Адаптер к Yandex.Cloud API. По командам CP создаёт и останавливает VM под compute, не общается напрямую с приложениями.
VM с PostgreSQL 17 и расширением spg99 (remote storage manager + WAL-sender) и Agent. Agent принимает bootstrap от CP, настраивает Postgres и репортит состояние.
Принимает WAL от spg99_walsender, пишет локальный лог и выгружает сегменты в S3. Обеспечивает надёжное хранение WAL.
Подписывается на Safekeeper, применяет WAL и создаёт page-слои в S3. Отвечает за чтения для remote storage manager в PostgreSQL.
Слушает :5432 с TLS, реализует PostgreSQL-протокол для клиентов. По первому коннекту запрашивает lease у CP и, при необходимости, триггерит auto start.
Bucket spg99-data с иерархией tenants/{tid}/db/{dbid}/timeline/{tl}/…. Там живут WAL и page-слои.
Инструмент разработчиков, ходит только в Control Plane REST v2. Никаких прямых вызовов YC API и ручной работы с S3.
От создания БД до остановки по idle
Наглядный путь запроса через компоненты spg99 — от CLI до S3.
spgctl db create или POST /v2/tenants/{t}/dbs — Control Plane заводит запись в каталоге, создаёт timeline в Pageserver и готовит storage.
Клиент идёт на Gateway, который запрашивает lease у Control Plane и, если compute не запущен, инициирует auto start через Provisioner.
PostgreSQL пишет WAL в Safekeeper. Safekeeper пакует сегменты в S3, Pageserver подписывается на WAL, применяет его и хранит page-слои в S3.
Control Plane отслеживает active_connections и last_used_at. При простое отправляет команду stop_db в Provisioner — VM гасится, данные остаются в S3.
Кейсы использования spg99
Сценарии, где разделённые storage/compute и auto start/stop дают максимальный эффект.
Мульти-тенант SaaS
Отдельная БД на tenant. Базы поднимаются по первому запросу, простои не стоят денег — compute выключен.
Preview / staging-окружения
Временные БД под каждую ветку или PR. После тестов compute останавливается, storage остаётся для отладки.
Внутренние сервисы со sporadic-нагрузкой
Админки, внутренние API и ETL, которые включаются по расписанию или руками. Платите только за время работы.
Аналитика и долгие запросы
Выделенные профили compute, которые живут только во время тяжёлых задач и не мешают боевой нагрузке.
Простая модель: storage отдельно, compute отдельно
Storage — долгосрочно в S3, compute — только когда нужен. Никаких сюрпризов от простаивающих VM.
Pay-as-you-go для продакшена
- · Оплата за GiB в S3.
- · Почасовая оплата compute по профилям (dev-small, prod-medium и т.д.).
- · Auto start/stop включены по умолчанию.
Отдельный контур и расширенные SLO
- · Выделенные профили compute и storage.
- · VPC-подключение, расширенная безопасность.
- · Индивидуальные SLO и поддержка.
Куда развивается spg99
Мы начинаем с надёжного ядра — внешнего хранилища данных на базе российской облачной инфраструктуры и Control Plane — и развиваем платформу вглубь и вширь.
MVP ядро платформы
- · Внешнее хранилище данных (S3 + Pageserver/Safekeeper).
- · Auto start/stop compute через CP и Gateway.
- · CLI spgctl и REST API v2.
- · Развёртывание в Яндекс.Облаке (ru-central1).
Наблюдаемость, безопасность и web-консоль
- · Pay as you go: готовые дашборды в Grafana и логи в Kibana по cold start, состояниям compute и auto start/stop без ручной настройки.
- · Web-консоль для управления tenants/БД и выдачи DSN/кредов без CLI.
- · Новые профили compute и ускорение cold start за счёт оптимизации bootstrap и подгрузки page-слоёв.
Масштабирование и интеграции
- · Расширенное масштабирование (multi-AZ, гибкие политики auto scale).
- · Шаблоны окружений dev/stage/prod поверх compute-профилей.
- · Дополнительные интеграции и SDK.
Документация spg99
Быстрый старт с spgctl, описание REST API v2, схемы bootstrap compute и storage, модель данных и каталог БД.
- 1. Обзор spg99
- 2. Быстрый старт (CLI + REST)
- 3. Концепции: tenants, db, timeline, state, scale
- 4. Control Plane API v2 (полная спецификация)
- 5. Архитектура компонентов (CP, Provisioner, Agent, Gateway, Safekeeper, Pageserver, S3)
- 6. Операции: создание/удаление, scale, восстановление
- 7. Настройка безопасности (TLS, токены, сертификаты)
- 8. Наблюдаемость и метрики
- 9. Roadmap / Release notes
Ответы на частые вопросы
Если чего-то не хватает — это отличный повод поговорить с инженером spg99.
spg99 отделяет compute от storage. Данные и WAL хранятся в S3 через Pageserver/Safekeeper, VM с PostgreSQL одноразовая и управляется Control Plane. Вы не настраиваете кластеры, репликацию и бэкапы вручную.
Данные не лежат на диске VM. WAL и page-слои уже находятся в S3. Control Plane поднимет новый compute-узел, подключит его к Safekeeper/Pageserver и восстановит состояние по timeline.
Первое подключение к DSN приходит в Gateway. Gateway спрашивает Control Plane, есть ли живой compute. Если нет — CP через Provisioner поднимает VM. По idle Control Plane отправляет команду на остановку.
Да, через логическую или физическую репликацию и/или pg_dump/pg_restore. Детали зависят от исходной версии и объёма данных.
В S3-совместимом объектном хранилище в РФ. Safekeeper пишет WAL в S3, Pageserver хранит там page-слои, организованные по tenants/db/timeline.
Storage оплачивается помесячно за GiB в S3, compute — по часам фактической работы VM. Auto start/stop не даёт простаивать инстансам без трафика.