Architecture Overview

The SPG99 architecture is built around one very important principle: compute and durable storage are separated. This allows the platform to start PostgreSQL quickly on demand without turning every database into a “permanent stateful pod.”

Main components

• Control Plane — the resource catalog, API keys, database lifecycle, leases, autoscaler, and orchestration.
• Console — the user-facing web interface on top of the Control Plane API.
• Gateway — the single PostgreSQL entry point over TLS, a built-in pooler, and a safe router to the current writer.
• Provisioner — materializes the decision “a writer must be started” into a real compute pod.
• Compute / Agent — starts PostgreSQL and executes SQL.
• Pageserver — stores history and serves soft basebackup / startup state.
• Safekeeper — the WAL reliability layer; it is what makes confirmed writes durable.
• Object Storage — stores layers and related storage artifacts.
• Prometheus / Grafana / Loki — metrics, logs, and operational diagnostics.

What changed in the current contract

In the new platform version, compute is no longer the place where an almost complete working set of user files lives locally. Now only the minimum required for a fast PostgreSQL startup remains on the pod.

In practice, this means:

• writer startup goes through soft basebackup;
• Pageserver serves a thin startup image;
• user relation pages are fetched lazily on local misses;
• the local compute disk is a fast write-back cache, not durable storage.

What this looks like to the user

Console / API client
    -> Control Plane
    -> Gateway
    -> Compute
    -> Pageserver + Safekeeper

This scheme leads to four practical SPG99 properties:

1. A database can be in stopped, and that is normal.
   It only means compute is not consuming resources right now.

2. The first connection after idle may be a bit slower.
   The platform must bring the writer up and reach ready.

3. Stopping compute does not mean losing data.
   The durable state of the database lives deeper in the platform — in Pageserver + Safekeeper + object storage.

4. Writer profile changes happen through a safe handoff, not a risky live resize.
   The platform prepares a new candidate and then moves traffic to it through a controlled cutover.

Why this architecture is convenient

• the create/connect scenario stays fast;
• idle compute does not consume resources permanently;
• cold start is accelerated by soft basebackup and the thin startup image;
• the autoscaler works predictably without breaking durability;
• security and observability are centralized at the platform level.

That is why SPG99 is well suited to serverless scenarios, dev/test, bursty workloads, and production operations where startup speed, transparency, and reliability matter.