Platform Infrastructure: Overview

SPG99 infrastructure is the platform layer that makes PostgreSQL in spg99.ru fast, reliable, and convenient for daily work. The user does not need to manage this layer manually, but it is useful to understand its role.

Main idea

SPG99 is built around separating two responsibilities:

• compute — executes SQL and serves active workload;
• the storage chain — stores the durable state and makes it safe to restart compute.

Because of this, a database can:

• start quickly on demand;
• avoid keeping compute enabled without load;
• survive worker stop and recreation without data loss.

What changed in the current contract

In the new platform version, three infrastructure decisions are especially important:

Soft basebackup

Pageserver gives Compute not a heavy full local snapshot, but a thin startup image for fast PostgreSQL startup.

Minimal local pod disk

The pod now keeps only the data required to start PostgreSQL and run the local cache. User relation files no longer have to be stored locally in full.

Writer autoscaler through generation handoff

The platform changes the writer profile not through live resize, but through a safe handoff between compute generations.

What matters to the user

The user usually sees only a few public entry points:

• the website and documentation;
• Console;
• the Control Plane API;
• Gateway for PostgreSQL;
• Grafana or other observability entry points, if they are provided.

Internal storage, startup, and routing services remain inside the platform and do not require manual user involvement.

What this infrastructure provides in practice

• a simple path from database creation to the first connection;
• a stable DSN even when the internal writer changes;
• fast cold start thanks to soft basebackup;
• no unnecessary local user-data disk layer on the pod;
• a safe autoscale handoff between profiles;
• built-in diagnostics through Console, metrics, and logs.

Why the user does not need extra details

Before changes are promoted to the main managed environment, they are validated in test and pre-production stages. In everyday user documentation, what matters more than the exact cluster composition is the resulting contract:

• where to connect;
• which scenarios are supported;
• how the database behaves during idle;
• where to inspect state, handoff, and errors.