How SPG99 Works: Request Processing Flow

Below is a typical scenario where a database has been stopped and must be awakened on the first connection.

Step-by-step path

1. The client connects to Gateway using a normal PostgreSQL DSN and sends pg_user / pg_password.
2. Gateway determines which tenant and which database the connection belongs to.
3. Gateway requests a lease from the Control Plane and checks whether an active writer already exists.
4. If the database is in stopped, the Control Plane initiates its startup through Provisioner.
5. Provisioner starts or assigns a new compute pod.
6. Compute receives the runtime contract: tenant, db, timeline, writer term, compute profile, Pageserver address, and the Safekeeper list.
7. Compute requests a soft basebackup from Pageserver — a thin startup image for PostgreSQL startup.
8. Pageserver prepares the startup minimum: system catalogs, relmap, service state, and sparse placeholders instead of a full local set of user relation files.
9. Compute starts PostgreSQL, while user relation pages are fetched lazily through Pageserver on local misses when needed.
10. Before entering ready, Compute checks critical storage dependencies, including WAL quorum.
11. Gateway receives the backend address and switches the client connection to the already running PostgreSQL instance.

What happens next

While the database is in use:

• Gateway holds the lease;
• the lease is renewed regularly;
• the Control Plane does not consider the database safe for idle stop.

When activity ends:

• the lease is released;
• the database becomes a candidate for auto-stop;
• the Control Plane moves compute into an inactive state.

How the autoscaler participates here

If the platform decides to change the writer profile, the path is different. It does not modify the live pod in place, but performs a controlled handoff:

prepare candidate -> freeze new checkouts -> drain -> stop old -> promote new -> unfreeze

This is especially important for production workloads:

• data and writer term remain consistent;
• Gateway knows when it must stop taking new checkouts;
• long-lived pinned or session traffic is not cut over blindly.

What is important for the user to understand

• from the client point of view, everything still looks like a normal PostgreSQL connection;
• the real orchestration logic is hidden inside the platform;
• the first connection to a sleeping database may be a bit slower;
• the durable state of the database is not tied to the life of one worker;
• when scaling, the platform changes the compute generation of the writer, not just a number in the UI.

Why this is convenient

This chain gives a good compromise between cost and speed:

• compute does not stay enabled without load;
• the user does not manage workers manually;
• soft basebackup accelerates cold start;
• the storage chain provides reliability independently of a specific compute instance.