Production Launch Checklist

Before moving an application to production, it is useful to go through a short checklist. It helps eliminate the most common operational mistakes before the first real traffic arrives.

1. Secrets and access

• the API key is stored separately from the PostgreSQL DSN;
• pg_user / pg_password are stored in Secret Manager or CI secrets;
• the application does not embed the API key where only the DSN is needed;
• token permissions are minimal and match the task.

2. Connection and TLS

• the application uses the Gateway host from Console or the DSN;
• the connection string includes sslmode=require at minimum;
• connect_timeout is not too small;
• a test connection has been verified from the same environment where the application will run.

3. Cold start behavior

• the driver can retry connections;
• the overall connection deadline accounts for the fact that a sleeping database may not wake up instantly;
• for critical peaks, there is a prewarming scenario based on a normal test connection;
• the team understands that startup now uses soft basebackup and a thin startup image, not a full local restore.

4. Profile and autoscaler

• the correct starting size has been chosen;
• if autoscale handoff matters, the team accounts for the fact that the active runtime contract today is L1/L2;
• long-lived session state and pinned connections are not used where the smoothest possible handoff is required;
• the team understands that when the writer profile changes, the platform does candidate/freeze/drain/promote rather than “live-resizing” the pod.

5. Observability

• the team has a quick path to Metrics and Logs;
• the required actions for state=error, prolonged booting, and TLS problems are understood;
• the team knows how to read scale_state, current_profile, target_profile, and freeze_new_checkouts;
• it is defined in advance which signals count as incidents: long cold starts, connection errors, FAILED autoscale transitions, or a rise in pinned sessions.

6. Migration and rollback

• the cutover scenario is documented;
• the rollback or re-switch plan is preserved;
• maintenance windows are agreed if you are moving production data.

7. Final check

Before real traffic, it is advisable to run a short end-to-end test:

1. open the application from the production environment;
2. verify that it connects to SPG99;
3. perform several reads and writes;
4. check the logs, state, and runtime fields of the database in Console.

If this cycle passes without surprises, day-to-day operations usually reduce to normal PostgreSQL work within the normal SPG99 serverless model.