Databases: Overview

Stable

How the user-facing database model works in SPG99: writer lifecycle, durable storage, and the new profile/autoscaler fields.

Updated: March 21, 2026

In SPG99, a database is not only an SQL entity inside PostgreSQL, but also a managed platform resource with its own lifecycle.

What a database includes in SPG99

For the user, a database is usually associated with the following parameters:

  • name;
  • size;
  • state (state);
  • timeline and storage binding;
  • runtime fields such as worker_id, current_scale, target_scale, and active_connections.

In the new model, it is also useful to look at:

  • current_profile;
  • target_profile;
  • candidate_profile;
  • scale_state;
  • freeze_new_checkouts.

The main difference from “a regular VM with PostgreSQL”

In SPG99, the durable state of the database lives in the platform storage chain, while compute starts on demand. Therefore:

  • the database can be in stopped, and that is normal;
  • on the first connection, the platform starts the writer automatically;
  • after inactivity, the writer can be stopped again;
  • this does not mean data loss.

What changed on the compute side

In the new platform version, the local pod keeps only the minimal data needed to start PostgreSQL. Startup goes through soft basebackup, and user relation pages are fetched lazily when needed.

For the user, this means:

  • cold start has become lighter and cleaner;
  • the local writer disk is a working cache, not the “main home” of the database;
  • durability is still provided by the platform storage chain.

Basic lifecycle

In simplified form, the user sees something like this:

create -> stopped / booting -> ready -> idle -> stopped -> deleting

But now an active database may also have an additional profile lifecycle:

STEADY -> PREPARING -> FREEZING -> DRAINING -> ... -> COOLDOWN

What matters in day-to-day work

  • state shows the database lifecycle;
  • size shows the user-facing resource class;
  • current_scale / target_scale help you understand whether the writer is active;
  • current_profile / target_profile show the writer profile;
  • scale_state shows whether a controlled handoff is in progress;
  • worker_id is useful for diagnostics, but it is not a stable business identifier.

Practical meaning

The SPG99 user model provides a good balance:

  • the database is created quickly;
  • an idle writer does not consume resources forever;
  • startup and shutdown happen automatically;
  • durable data does not depend on the life of one worker;
  • profile handoff is performed safely and transparently through the autoscaler.

That is why stopped, and even a temporary freeze_new_checkouts, should be treated as part of normal serverless operation rather than as an outage.