What is SPG99

SPG99 is a PostgreSQL platform with separated compute and durable storage. To the user, it looks like regular PostgreSQL over a standard DSN, but internally it is designed so that a database can start quickly, stop safely, and avoid depending on a single pod or one local disk.

Three things matter most in the current platform contract.

• Compute does not store the only copy of the data. The pod is needed for SQL execution and local caching, but it is not “the only place where the database lives.”
• Startup goes through soft basebackup. When compute starts, it receives a thin startup image from Pageserver: only the minimal state required for PostgreSQL to start quickly.
• Writer scaling uses a safe generation change. The platform does not try to “stretch” a live pod in place. It prepares a new candidate writer, then carefully moves traffic to it.

What this gives the user

1. Fast startup without a heavy local restore

The pod no longer receives a full working PGDATA. Locally, only the startup minimum remains: system catalogs, relmap, service state, and a fast write-back cache. User relation pages are pulled lazily through Pageserver as they are accessed.

Practical meaning:

• cold start is shorter and more predictable;
• the pod comes up faster;
• the local disk no longer has to hold an extra copy of user data.

2. Reliability does not depend on the fate of one pod

Confirmed writes rely on Safekeeper quorum, while history and bootstrap state are assembled through Pageserver. Because of that, recreating a pod, moving the writer, or stopping compute in the normal way does not equal data loss.

3. The autoscaler is safe for real traffic

The current writer profile autoscaler works through a generation handoff model:

prepare candidate -> freeze new checkouts -> wait for drain -> switch writer

This allows the compute profile to change without a risky live resize of the active writer.

How profiles are arranged today

In the active runtime contract, the autoscaler works for L1 and L2 profiles. That range is what is currently treated as production-ready and fully supported in the serverless chain.

For the product-side PAYG line, the platform is already prepared for the L1–L5 scale as the user-facing size model. But the current live autoscale handoff in the managed environment is designed specifically for L1 <-> L2.

How SPG99 differs from PostgreSQL on a regular VM

In a classic VM setup, PostgreSQL usually has a hard binding between:

• one server;
• one local disk;
• one PostgreSQL process;
• a heavily manual lifecycle.

In SPG99, the scheme is different:

Clients -> Gateway -> Control Plane -> Compute
                                   -> Pageserver + Safekeeper + Object Storage

This leads to clear advantages:

• the application DSN remains stable;
• a sleeping database can wake up automatically;
• compute can be replaced safely;
• the platform itself balances speed, cost, and reliability.

Short conclusion

SPG99 is not “Postgres in a container,” but a platform where:

• speed comes from local execution and thin soft bootstrap;
• reliability is provided by the storage chain, not by one pod;
• writer scaling is performed carefully and without risking data.