API Changelog

Stable

The actual API v2 changes around the new autoscaler and database runtime fields.

Updated: March 21, 2026

The API changelog is a separate view of release notes for those who write integrations, CI/CD scenarios, and internal services on top of the Control Plane API.

2026-03-21 — new writer autoscaler runtime fields

In database descriptions (GET /v2/tenants/:tenant/dbs/:db, GET /v2/dbs/:id), new fields related to autoscale handoff now appear and/or became operationally significant.

New profile and candidate-generation fields

  • current_profile
  • target_profile
  • candidate_profile
  • candidate_worker_id
  • candidate_writer_term

New handoff-state fields

  • scale_state
  • freeze_new_checkouts
  • lease_control_epoch
  • autoscale_cooldown_until
  • scale_phase_started_at
  • scale_phase_deadline_at
  • scale_failure_reason

What this means for integrators

The API can now distinguish between:

  • a database that is simply running or stopped;
  • a database that is already changing profile;
  • a database where handoff is stuck in FREEZING, DRAINING, SWITCHING, or has fallen into FAILED.

Behavioral shift

This is an additive + behavioral change:

  • the basic create/list/get routes remain intact;
  • but the meaning of “scale” must now account not only for current_scale/target_scale, but also for the autoscaler profile axis.

Practical recommendation:

  • for logic that answers “is the writer running,” continue to look at current_scale/target_scale;
  • for logic that answers “is a profile handoff in progress,” you must look at current_profile/target_profile/scale_state.

What did not change

  • manual user start/stop/scale operations remain disabled in the managed contract;
  • start_immediately and initial_scale=1 do not become the recommended public path;
  • the basic workflow remains the same: create tenant -> create db -> connect through Gateway.

Size model

On the product and PAYG side, the L1–L5 line is already prepared, but the active autoscaler runtime contract is currently implemented for L1/L2.

This means:

  • integrations can already plan for the overall user size scale L1–L5;
  • but live autoscale handoff should be treated as production-active specifically for L1 <-> L2.