Compute lifecycle

A compute in Neon is a stateless Postgres process due to the separation of storage and compute. It has two main states: Idle and Active.

Generally, an idle compute has been suspended by Neon's scale to zero feature due to inactivity, while an Active compute has been activated by a connection or operation, indicating that Postgres is currently running.

If there are no active queries for 5 minutes, which is the scale to zero setting in Neon, your compute is automatically placed into an idle state. If you are on a paid plan, you can disable the scale to zero behavior so that a compute always remains active. This behavior is controlled by your compute's Scale to zero setting.

For information about configuring this setting, see Edit a compute.

When you connect to an idle compute, Neon automatically activates it. Activation generally takes a few hundred milliseconds. However, if your Neon project has been idle for more than 7 days, you may experience a slightly longer activation time.

Considering this activation time, your first connection may have a slightly higher latency than subsequent connections to an already-active compute. Also, Postgres memory buffers are cold after a compute wakes up from the idle state, which means that initial queries may take longer until the memory buffers are warmed.

After a period of time in the idle state, Neon occasionally activates your compute to check for data availability. The time between checks gradually increases if the compute does not receive any client connections over an extended period.

In the Branches widget in the Console nav, you can check if a compute is active or idle and watch as it transitions from one state to another.

When connections are closed due to a compute being suspended, anything that exists within a session context is forgotten and must be recreated before being used again. For example, Postgres parameters set for a specific session, in-memory statistics, temporary tables, prepared statements, advisory locks, and notifications and listeners defined using NOTIFY/LISTEN commands only exist for the duration of the current session and are lost when the session ends.

For more, see Session context.