Autoscaler and Scaling Policies

In SPG99, the word scale must now be understood correctly. For a normal user, this is not manual autoscaling in the sense of “start one more writer,” and it is not a hot resource change for an already running pod.

What scaling means today

A database now has two different runtime axes.

1. Whether the writer is running

This is reflected by the fields:

• current_scale
• target_scale

In the current contract, these are essentially binary:

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

2. Which profile the writer is running on

This is reflected by the fields:

• current_profile
• target_profile
• candidate_profile
• scale_state

That is where the new autoscaler lives.

How the writer autoscaler works

The current active scheme is a generation handoff, not a live resize.

In simplified form, it looks like this:

current writer
  -> prepare candidate writer for the new profile
  -> freeze new checkouts
  -> drain
  -> stop old writer
  -> promote new writer
  -> switch state
  -> cooldown

Practical meaning:

• the active writer is not changed in place;
• the new profile gets a new writer generation;
• Gateway helps perform a safe cutover;
• WAL and session correctness are preserved.

What the autoscaler fields mean

scale_state

Shows the transition stage. The main values are:

• STEADY — the database is in a normal steady state;
• PREPARING — the platform is preparing a candidate writer;
• FREEZING — new checkouts are temporarily frozen;
• DRAINING — the system is waiting for active load to finish;
• STOPPING_OLD — the old writer is stopping;
• STARTING_NEW — the new generation is starting or being brought to readiness;
• SWITCHING — the platform is switching control state to the new writer;
• COOLDOWN — a protective pause after handoff completes;
• FAILED — the transition failed and needs investigation.

freeze_new_checkouts

Shows that Gateway must no longer issue new checkouts to the old writer. This is a normal part of a controlled cutover.

candidate_worker_id and candidate_writer_term

These are diagnostic fields of the prepared new writer generation.

scale_failure_reason

If the handoff failed, this field provides the best short diagnosis.

Why the platform does not do live resize

Live resize would carry too many risks:

• session state on active connections;
• races while changing resources under a live writer;
• higher correctness complexity on the write path;
• more risk for production workloads.

Generation handoff may look slower on paper, but in real operations it is more reliable, more transparent, and easier to diagnose.

What blocks seamless cutover

The most important limiter is pinned or session-heavy traffic.

If the workload uses:

• named prepared statements;
• temp tables;
• LISTEN/UNLISTEN;
• SET or other session state;
• long session-dependent connections,

the platform must not perform an aggressive handoff “through the head” of that traffic. In such a case, cutover is delayed or cancelled until a safe window appears.

What the user should do

• Use Gateway as the single entry point for normal work.
• Look not only at state, but also at scale_state.
• Do not build a workflow around manual POST /scale.
• For the smoothest autoscale handoff, minimize session-heavy patterns where they are not truly needed.
• Remember that the current active handoff contract works for L1/L2 profiles.

Practical conclusion

In SPG99, writer scaling is no longer just a “0/1 switch,” but a controlled safe handoff between compute generations. For the user, that means more reliable behavior under load, better predictability, and clearer diagnostics.