How SPG99 keeps one DSN and preserves durable state when compute stops

The main rule is that the application should not have to care about internal lifecycle transitions. That is why the database keeps one stable DSN whether compute is already active or needs to wake up after idle.

SPG99 keeps this entrypoint separate from the worker that actually executes PostgreSQL processes. For the client, that means the connection string stays the same even if compute had been stopped and later recreated.

If database state lived only inside the current compute node, stopping the worker would create either data-loss risk or a complicated recovery path. SPG99 avoids that by keeping durable state separate from the currently running worker.

The worker can therefore stop, be recreated, or be replaced because the source of truth for data exists outside compute. That is what makes auto-stop a normal architectural state rather than a dangerous budget trick.

When the first connection arrives after idle, the platform does not rotate the DSN or ask the client to discover a new endpoint. Gateway accepts the request, Control Plane brings the required compute back, and traffic is switched into the active path.

For the application, that still looks like a normal PostgreSQL connection with the only practical difference being that post-idle wake-up should be handled with a sensible connect_timeout and retry policy.

Separating the entrypoint, compute lifecycle, and durable storage creates several direct benefits:

• applications keep the normal PostgreSQL connection model;
• teams do not need to start and stop temporary databases by hand;
• workers can stop without rotating the DSN;
• post-idle recovery becomes controlled and predictable;
• the platform stays automation-friendly through Console and API.

That is why SPG99 is not only about savings. It is also about removing manual operations from temporary database environments.