Database Lifecycle and Auto-Start

In SPG99, a database lives in a serverless model: the logical database and durable storage exist continuously, while compute starts only when it is actually needed.

What happens immediately after creation

A new database is created as a catalog record and as a storage entity for a timeline. At the same time, a permanently running writer is not started automatically.

This gives two advantages:

• the database is created faster;
• the platform does not spend compute resources without real workload.

The first connection

When a client first connects to a stopped database:

1. the client comes to Gateway;
2. Gateway requests a lease from the Control Plane;
3. if the database is not yet active, the Control Plane coordinates startup through Provisioner;
4. Compute receives a soft basebackup from Pageserver and starts PostgreSQL;
5. Gateway routes the client connection to the ready backend.

That is why the first connection to a sleeping database is usually slower than a connection to an already warm one. This is a normal cold start.

Active work

While the database is in use:

• Gateway holds the lease;
• the lease is renewed;
• the Control Plane sees that the database is active and does not stop it.

Idle and auto-stop

When activity ends:

• active leases end;
• the database becomes a candidate for auto-stop;
• the Control Plane stops the writer.

Important: this is normal operating behavior, not an error. The durable state of the database is not lost, because SPG99 reliability relies on the storage chain rather than on the local compute disk.

The new autoscaler in the database lifecycle

The Control Plane is now responsible not only for create/start/stop/delete, but also for profile handoff of the active writer.

It looks like this:

• the need for a profile transition is determined;
• a candidate writer generation is created;
• Gateway receives freeze_new_checkouts;
• the system waits for drain of active load;
• the old writer is stopped;
• the new writer is promoted;
• the catalog and control state switch to the new generation;
• cooldown is enabled.

The important point is this: this is not a live resize of a running pod, but a safe generation change of the writer.

What limits seamless handoff

The platform must not switch aggressively if session-heavy traffic is present:

• pinned sessions;
• long transactions;
• idle in transaction;
• or other signs that the old writer still cannot be removed safely.

That is why handoff may be postponed until a safer window.

Database states

In practice, these state values are the most common:

• creating — the catalog and storage are still being prepared;
• booting — the writer is starting;
• ready — the database is ready to accept connections;
• stopping — the writer is stopping;
• stopped — the writer is off; the next connection can wake the database again;
• deleting — deletion is in progress;
• error — an error occurred and logs/monitoring are needed.

In addition, it is now useful to look at scale_state if you want to understand whether an autoscale handoff is in progress.

What current_scale and target_scale mean

In the current SPG99 writer model, these fields are essentially binary:

• 0 — the writer is stopped;
• 1 — the writer is running.

For the writer profile, other fields have become more important:

• current_profile
• target_profile
• candidate_profile
• scale_state
• freeze_new_checkouts

Important nuance: manual start/stop/scale is disabled

The Control Plane code contains start, stop, and scale routes, but in the current public user scenario they are intentionally disabled. The practical conclusion is very simple:

create a database -> connect -> the platform starts it on its own -> after idle, it stops it on its own

And if a different writer profile is needed, the platform now performs a controlled handoff between compute generations on its own.