Compute: Overview

Compute is the working PostgreSQL execution layer in SPG99. It is exactly what starts PostgreSQL, accepts client connections through Gateway, and executes SQL queries.

The main point of the current service model is this: Compute is not a “permanent pod with a full set of user files on the local disk.” In SPG99, it acts as a managed compute layer above a fault-tolerant storage chain.

What is inside Compute

Inside Compute, you have:

• PostgreSQL 17;
• the spg99 extension;
• a management agent that prepares bootstrap, TLS, managed configuration, readiness, and integration with the control plane.

What changed in the new model

Previously, it was easier to think of compute as a worker that pulled “almost the whole database” on startup. The contract is now more precise:

• PGDATA on compute is ephemeral;
• the local disk is a write-back cache;
• the durable state lives in Pageserver + Safekeeper + object storage;
• startup goes through soft basebackup;
• only the startup minimum for fast PostgreSQL launch remains local.

This means the pod no longer contains an unnecessary user-data disk layer “just in case.” The database starts faster, and the local disk behaves exactly as a fast operational cache.

The role of Compute in the SPG99 chain

In simplified form, the path looks like this:

Application / psql
    -> Gateway
    -> Control Plane
    -> Provisioner
    -> Compute
    -> Pageserver + 3 Safekeeper

The roles of services in this chain are:

• Console — shows database states, DSNs, logs, metrics, and available actions.
• Gateway — the single PostgreSQL entry point and built-in pooler.
• Control Plane — manages lifecycle and autoscaler state.
• Provisioner — starts the compute pod.
• Compute — runs PostgreSQL, serves SQL, uses the local cache, writes WAL to Safekeeper, and reads data through Pageserver.
• Pageserver — the source of soft basebackup and remote read-through.
• Safekeeper — the WAL reliability layer.

How a normal startup works

In a normal scenario, the Compute lifecycle looks like this:

1. The user creates a database or connects to an existing one.
2. The Control Plane determines that the database needs an active writer.
3. Provisioner starts or assigns a compute worker.
4. Compute receives soft basebackup and configuration.
5. PostgreSQL enters ready.
6. Gateway forwards the client connection to the ready backend.

How Compute participates in the autoscaler

In the new profile autoscaler model, the platform does not perform a live resize of an already running writer. Instead:

• a candidate generation is started for the new profile;
• the candidate may be prepared in prepare_only mode;
• the platform waits for a safe window;
• Gateway freezes new checkouts and helps perform drain;
• the writer handoff completes only after the new generation is promoted.

For the user, this means:

• the writer profile changes safely;
• the system does not risk session state or WAL correctness for the sake of a “hot resize”;
• it is more important to look at current_profile, target_profile, and scale_state than to think of “scale” as a count of pods.

What is important for the user to remember

• stopped is a normal part of the serverless model, not an outage.
• The first connection after idle may take longer because of cold start.
• The local Compute disk is there for speed, but it is not the only source of reliability.
• The correct application entry point is Gateway, not a direct worker/pod address.
• During profile changes, the platform creates a new compute generation of the writer, rather than “stretching” the old one.