Войти

Журнал изменений

Stable

Фактические изменения пользовательского контракта SPG99: soft basebackup, минимальный pod‑disk и новый writer autoscaler.

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

Журнал изменений нужен не только для “новостей продукта”, но и как рабочий источник информации перед обновлением приложения, automation и операторских процедур.

2026-03-21 — обновление serverless runtime

Это ключевое обновление текущего контракта SPG99.

1. Внедрён soft basebackup

Новый cold start и restart больше не опираются на восстановление полного локального пользовательского PGDATA.

Что изменилось:

  • pageserver отдаёт soft basebackup / thin startup image;
  • локально материализуется стартовый минимум для PostgreSQL;
  • пользовательские relation files не считаются обязательной частью стартового локального снимка;
  • недостающие страницы могут read‑through подгружаться из pageserver.

Что это даёт:

  • более короткий bootstrap path;
  • меньше данных для подготовки на старте;
  • более предсказуемый restart после idle и relocation.

2. Перераспределено хранение данных на pod’е

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

Практический смысл:

  • pod‑диск перестаёт выглядеть как “полная локальная durable‑копия базы”;
  • локальный PGDATA ещё сильнее соответствует роли рабочего cache‑слоя;
  • долговечность по‑прежнему обеспечивается storage‑цепочкой Pageserver + Safekeeper + object storage.

3. Введён новый writer autoscaler

В runtime заработал безопасный autoscale‑handoff между профилями.

Что важно:

  • текущий активный контракт autoscaler работает для L1 <-> L2;
  • платформа готовит candidate generation на новом профиле;
  • затем делает controlled handoff: prepare -> freeze -> drain -> promote -> switch -> cooldown;
  • это safer и предсказуемее, чем попытка live resize уже активного writer.

Что это даёт пользователю:

  • плавное изменение профиля без “ручного переезда”;
  • понятные runtime‑поля в API и Console;
  • быстрый handoff благодаря warm pool.

4. PAYG‑модель подготовлена шире текущего runtime‑контракта

На продуктовой стороне уже подготовлена размерная шкала L1–L5 и plan id standard_payg.

Важно честно разделять:

  • runtime autoscaler сегодня — L1/L2;
  • product/pay-as-you-go модель — уже подготовлена под L1–L5.

Как читать это изменение пользователю

Для обычного сценария главное теперь такое:

create db -> connect through Gateway -> платформа сама стартует writer ->
при необходимости меняет профиль через autoscale handoff ->
при idle снова освобождает compute

Это делает SPG99 быстрее на старте, экономичнее по локальному pod‑диску и заметно сильнее по управляемости writer‑профиля.

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