Start and Stop a Database

The title of this page may sound as if the user is expected to start and stop databases manually all the time. In the current managed SPG99 scenario, that is not the case.

What actually happens

For a user-facing database, the normal path is:

create db -> connect through Gateway -> the platform starts the writer on its own -> after idle, it stops it on its own

Why manual start/stop is not the main scenario

The public start, stop, and scale routes in the current Control Plane are intentionally disabled and return OperationDisabled.

This keeps the user path simple and predictable:

• the database starts on the first connection;
• active leases protect it from being stopped too early;
• after a period of inactivity, the writer is released automatically.

What changed after the autoscaler was introduced

The platform now has one more internal operation — a controlled handoff of the writer between profiles. But this still does not turn lifecycle into a manual user API.

The user still should not:

• start the writer manually before normal work;
• stop the writer manually after work;
• orchestrate the profile transition manually.

The platform does all of that on its own.

What the user sees in practice

• stopped — the writer is not running, but the database is not lost;
• booting — the platform is starting the writer;
• ready — you can work;
• stopping — the platform is stopping the writer after idle;
• scale_state != STEADY — a controlled profile handoff is in progress.

What the user should do

If the database is stopped

Simply connect to it through a normal PostgreSQL DSN. That is the normal startup mechanism.

If the database stays in booting for a long time

Wait, then open Monitoring / Logs and verify whether there is a problem on the compute or storage side.

If the database is currently in handoff

Look at current_profile, target_profile, scale_state, and freeze_new_checkouts. Do not try to “take control” with manual start/stop.

Practical meaning

In SPG99, stopped is not an outage, but part of the serverless model. The platform itself manages the writer lifecycle, while the user works with the database through the familiar DSN-based connection.