Database Profile and Autoscaler

In SPG99, the word scale must now be understood correctly. In the current user-facing managed scenario, this is not classic autoscaling “to multiple writer instances,” and it is not a public live-resize control.

What target_scale and current_scale mean

These fields are still binary:

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

That is why scale in the old sense is better treated as a runtime-state indicator, not as a full scaling control.

Which fields have become more important

For the new writer autoscaler model, it is more useful to look at:

• current_profile
• target_profile
• candidate_profile
• scale_state
• freeze_new_checkouts

These are the fields that show what the platform is doing with the writer profile right now.

How the profile actually changes

The writer profile changes through a generation handoff:

• the platform prepares a candidate writer;
• freezes new checkouts;
• waits for drain;
• switches the writer to the new generation.

This is safer than live-resizing a running writer.

What matters about the public API

Public manual scale is disabled in the current managed contract. Therefore, you should not build a workflow around POST /scale or expect it to hot-change the database size.

Practical conclusion

• if you want to know whether the database is active right now, look at current_scale / target_scale;
• if you want to know whether the writer profile is being changed, look at current_profile, target_profile, and scale_state;
• if you want production resilience, rely on the managed autoscaler rather than on manual lifecycle control.