Gateway

Stable

How Gateway accepts connections, wakes the database, holds the lease, and helps perform the autoscaler freeze/drain cutover safely.

Updated: March 21, 2026

Gateway is the public PostgreSQL entry point of SPG99. Applications, psql, BI tools, and standard PostgreSQL drivers connect to it.

For the user, Gateway is one stable external address behind which there may be an already running writer, or a database that must be started automatically on the first connection.

What Gateway does

Gateway plays several roles at once:

  • accepts TLS connections over the PostgreSQL wire protocol;
  • authenticates the client by tenant credentials;
  • acquires and renews the lease for the database;
  • wakes a sleeping database;
  • routes traffic to the current writer;
  • pools backend connections internally.

What is especially important in the new model

After the writer autoscaler was introduced, Gateway became a key participant in the controlled cutover.

When the platform prepares a handoff between writer profiles:

  • the Control Plane raises freeze_new_checkouts;
  • Gateway stops issuing new checkouts to the old writer;
  • the system waits for drain of active load;
  • only after that does it switch to the new generation.

This is a very important part of autoscaler reliability: handoff is not managed blindly, but through the same layer that carries real client traffic.

Why this is convenient for the user

  • the DSN remains the same even when the writer changes;
  • the connection still looks like regular PostgreSQL;
  • the database can wake up automatically;
  • pooling is built into Gateway itself;
  • freeze/drain remains transparent for stateless transaction workloads.

When Gateway will not be able to do a seamless cutover

If the workload holds session-dependent connections, for example:

  • temp tables;
  • LISTEN/UNLISTEN;
  • SET and other session state;
  • named prepared statements;
  • long pinned sessions,

then Gateway should not perform a “magical” seamless migration of that traffic. In that case, handoff is delayed until a safer window.

Practical recommendations

  • Use the standard DSN from the platform and do not try to bypass Gateway.
  • Keep the workload as stateless as possible at the SQL-session level.
  • Do not keep many “forever idle” connections without a real need.
  • Do not be alarmed by freeze_new_checkouts=true during autoscale: it is a normal controlled phase.

Short summary

In SPG99, Gateway is a public PostgreSQL entry point, a secure router, and a built-in pooler in one service. After the autoscaler was introduced, it also became a key participant in the safe freeze/drain handoff between writer generations.