Database Stuck in `creating` / `booting`

Stable

What to check if a database does not leave `creating`/`booting` for a long time: soft bootstrap, readiness, the storage chain, and autoscale state.

Updated: March 21, 2026

If a database is stuck in creating or booting, the problem is almost never that the database “does not exist,” but that the platform could not bring it to ready.

What this state means

  • creating — the platform is still preparing the catalog and storage entities;
  • booting — the writer is already starting, but PostgreSQL is not yet ready to accept real traffic.

On this path, the platform may be waiting for:

  • compute readiness;
  • soft bootstrap through Pageserver;
  • readiness to pass;
  • Safekeeper quorum availability;
  • completion or rollback of a profile handoff.

What to check first

  1. Open the database card or describe and look at:
    • state;
    • current_scale / target_scale;
    • current_profile / target_profile;
    • scale_state;
    • worker_id, if it already exists;
    • scale_failure_reason or error_reason, if present.
  2. Check Metrics and Logs.
  3. Make sure the problem is not just a client-side connect_timeout that is too short.
  4. If the issue affects several databases at once, look at Gateway and the Control Plane as the shared layer.

What the user should do

If the database is simply still in transition

Usually, you just need to wait a little and re-read the state.

If booting is taking too long

Inspect logs and metrics rather than trying to build a complex manual lifecycle around the database.

If the database moved to scale_state=FAILED

This means the autoscale handoff failed. In that case, it is especially important to save:

  • the tenant and database name;
  • the current scale_state;
  • current_profile and target_profile;
  • scale_failure_reason;
  • the time of the issue.

When to escalate

Escalation is needed if:

  • the database does not change state for a long time;
  • several databases are simultaneously stuck in booting;
  • the same database repeatedly falls into FAILED or error;
  • there are signs of problems in the storage chain or Gateway.

Practical conclusion

For the user, the main tool here is not manual start, but correct diagnostics through:

  • state;
  • scale_state;
  • Monitoring;
  • Logs.