Обзор объектной модели

Пользовательская объектная модель SPG99 достаточно компактна. Важно понимать несколько уровней.

Account
  ├─ API keys
  └─ Tenants
       ├─ pg_user / pg_password / dsn_template
       └─ Databases
            ├─ state / status
            ├─ size
            ├─ timeline
            ├─ current_scale / target_scale
            ├─ current_profile / target_profile / scale_state
            ├─ worker_id / backend_addr / active_connections
            └─ timestamps / usage

Account

Верхний уровень клиента. Через него группируются контактные данные, API‑ключи, tenants и часть usage.

API key

Bearer‑токен для доступа к Control Plane. У ключа есть scope (global, account, tenant) и permissions (can_create_tenant, can_create_db, can_scale, can_delete и т. п.).

Tenant

Главная пользовательская единица изоляции. У tenant есть:

• имя;
• свои PostgreSQL credentials;
• template DSN;
• набор баз внутри.

Database

Конкретная PostgreSQL‑база внутри tenant. Для неё важны:

• имя;
• size;
• state;
• timeline;
• runtime‑поля вроде worker_id, active_connections, current_scale, target_scale.

Что нового в runtime‑модели базы

Теперь у базы есть и новые profile/autoscaler‑поля:

• current_profile
• target_profile
• candidate_profile
• scale_state
• freeze_new_checkouts

Это позволяет видеть не только “запущена база или нет”, но и то, идёт ли controlled handoff между поколениями writer.

Timeline

Timeline — durable‑история состояния базы на стороне storage‑контура. Для пользователя важно помнить только одно: новый compute всегда поднимается под конкретный timeline, а не “с нуля без памяти”.

Worker и runtime‑поля

Когда база активна, пользователь может видеть:

• worker_id;
• backend_addr;
• backend_port;
• active_connections;
• last_used_at.

Это полезно для диагностики, но не стоит воспринимать такие поля как стабильный бизнес‑контракт.

Практический вывод

Вся модель SPG99 по‑прежнему сводится к очень понятной цепочке:

account -> tenant -> database -> connect through gateway

Но для production‑наблюдаемости теперь особенно полезно помнить ещё одну связку:

database -> current_profile / target_profile / scale_state

Именно она показывает, что writer уже живёт не только в lifecycle‑модели, но и в profile handoff‑модели.