Timelines and the Storage Model

In SPG99, the durable state of a database lives not in the local PGDATA of a specific compute instance, but in the platform storage chain.

What the durable model consists of

Three key layers work around the database:

• Safekeeper — accepts WAL and provides reliability through quorum;
• Pageserver — serves bootstrap, data history, and remote read-through;
• Object Storage — stores the manifest, layers, and related storage artifacts.

Together, they form the durable foundation of the database.

What changed on the pod

In the new model, the pod no longer keeps “almost all user files,” but only the minimal data needed to start PostgreSQL quickly.

In practice, this means:

• startup goes through soft basebackup;
• system catalogs and relmap are materialized locally;
• user relation files do not have to exist locally in full;
• on a local miss, Compute fetches the required pages through Pageserver;
• the local disk works as a write-back cache, not as the main storage volume.

The role of compute in this model

Compute is needed for SQL execution, but its local PGDATA is a working layer:

• it accelerates hot work;
• it can be rebuilt;
• it is not the only durable copy of the database.

That is why losing a pod/worker or recreating Compute does not equal data loss, as long as the storage chain is healthy.

What a timeline is

A timeline is the durable history of the database state. At the user level, two things matter:

• the database is bound to its own timeline;
• a new writer starts for a specific timeline, not “from scratch.”

Why this scheme is reliable and fast

The main write guarantee in SPG99 is WAL quorum in Safekeeper. That is exactly why the serverless model does not turn into “unreliable ephemeral PostgreSQL.”

And speed is achieved because:

• the pod starts from a thin startup image;
• there is no need to pull an unnecessary local user-data layer;
• Pageserver serves lazy read-through of data;
• the write-back cache keeps hot work fast.

What this means for the user

• stopped compute does not mean a lost database;
• compute can be started and stopped quickly;
• reliability is built deeper than the level of one worker;
• the pod now stores only what is truly needed for a fast PostgreSQL startup.