Timelines и модель хранения

В SPG99 durable‑состояние базы живёт не в локальном PGDATA конкретного compute, а в storage‑контуре платформы.

Из чего состоит durable‑модель

Вокруг базы работают три ключевых слоя:

• Safekeeper — принимает WAL и обеспечивает её надёжность через quorum;
• Pageserver — обслуживает bootstrap, историю данных и remote read‑through;
• Object Storage — хранит manifest, layers и связанные storage‑артефакты.

Вместе они образуют durable‑основу базы.

Что изменилось на pod’е

В новой модели на поде остаются не “почти все пользовательские файлы”, а только минимальные данные для быстрого запуска PostgreSQL.

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

• startup идёт через soft basebackup;
• системные каталоги и relmap материализуются локально;
• пользовательские relation files не обязаны лежать локально целиком;
• на local miss Compute дочитывает нужные страницы через Pageserver;
• локальный диск работает как write‑back cache, а не как главный storage‑том.

Роль compute в этой модели

Compute нужен для исполнения SQL, но его локальный PGDATA — это рабочий слой:

• он ускоряет горячую работу;
• может быть заново собран;
• не является единственной durable‑копией базы.

Поэтому потеря pod/worker или пересоздание Compute не равны потере данных, если storage‑контур в порядке.

Что такое timeline

Timeline — это долговечная история состояния базы. На пользовательском уровне достаточно помнить две вещи:

• база привязана к своему timeline;
• новый writer запускается под конкретный timeline, а не “с чистого листа”.

Почему эта схема надёжна и быстра

Главная гарантия записи в SPG99 — WAL quorum Safekeeper. Именно поэтому serverless‑модель не превращается в “ненадёжный ephemeral PostgreSQL”.

А скорость достигается тем, что:

• под стартует от тонкого startup‑образа;
• не нужно тащить лишний локальный пользовательский слой;
• Pageserver обслуживает ленивое дочитывание данных;
• write‑back cache оставляет горячую работу быстрой.

Что это означает пользователю

• stopped‑compute не означает потерю базы;
• compute можно быстро запускать и останавливать;
• надёжность заложена глубже, чем уровень одного worker;
• на поде теперь хранится только то, что действительно нужно для быстрого старта PostgreSQL.