Three core states
For everyday operations, three states are enough:
| State | What happens | What the application sees |
|---|---|---|
active | compute is running and serving connections | normal PostgreSQL behavior |
idle | no active compute, durable state is preserved | the database is sleeping until a new request arrives |
wake-up | the platform is bringing compute back on the first request | the first connection may take longer |
This model is simple, but it answers almost every operational question: when compute spend exists, when a cold start is expected, and when retry is part of normal behavior.
What the application should handle
The application does not need a separate “serverless PostgreSQL mode”, but a few standard practices help a lot:
- a sensible
connect_timeout; - retry for the first connection after idle;
- pool and timeout settings that do not assume compute is always warm;
- logging for failed first connection attempts.
This is not unique to SPG99. It is normal engineering discipline for systems that move through lifecycle states.
1. open connection
2. if timeout or transient connect error -> retry
3. after successful connect -> continue normally
4. do not rotate DSN or request a new endpointOperational rules worth defining early
To keep the model predictable, teams should define a few rules ahead of time:
- which environments are safe to put into auto-stop;
- which SLO is acceptable for the first connection after idle;
- which migrations and batch jobs should start only after wake-up succeeds;
- which dashboards and alerts show wake-up frequency and real idle windows.
Once those rules exist, lifecycle transitions stop looking like magic and become a normal part of database operations.
When auto-stop should be constrained
If a database participates in long-running integration tests with no tolerance for extra delay on the first request, or if a scenario needs continuously warm compute, auto-stop should be tuned more carefully or disabled for that database.
The goal is not to stop everything by default. The goal is to stop compute where it is both safe and economically useful. Mature operations therefore start with environment classification rather than with a single global rule for every database.
Further reading
SPG99 webinar: PostgreSQL without paying for idle in dev/test, preview, and internal services
This will not be a generic cloud talk or an interface walkthrough. Live on air, SPG99 will create a database in Console, connect through psql, show stopped → booting → ready, let the database return to idle, and then explain the controlled handoff between L1 and L2 writer profiles.
How SPG99 keeps one DSN and preserves durable state when compute stops
From the outside, SPG99 looks like regular PostgreSQL behind one DSN. Internally, the platform separates Gateway, Control Plane, worker, and durable storage, so compute can stop without changing the endpoint or losing data.