Neon Auto-Suspend

In short: A Neon-specific feature where the database compute instance automatically “falls asleep” (shuts down) after a period without requests — saves money, but means the very first request after an idle period takes longer because the instance has to start up again first (“cold start”).

In more detail: How long the inactivity lasts before it falls asleep (auto-suspend timeout) and whether it can be switched off at all (“Always Active”) depends on the Neon plan — higher plans allow this behaviour to be disabled.

Our context: Identified as a possible contributing cause of Emzett’s occasional outages, but not fixable in code — it’s a Neon project setting (Dashboard → Settings → Compute) or a question of the plan, not an open technical item in the repo itself.

In Depth

Why the cold start happens

The cold start after waking up happens because Neon stops the compute instance (the actual Postgres process) completely, not just pauses it — on the next request this process has to be restarted and rebuild its state (shared buffers/caches, connection pool, possibly temporary objects) before it can answer the first query. On most Neon plans this cold start is in the range of a few hundred milliseconds up to one or two seconds — noticeable, but usually not dramatic, as long as several users don’t hit the same waking process at once and cause requests to pile up (Neon queues incoming connections while waking up instead of rejecting them immediately with an error — so requests become slower rather than failing completely).

Because the data itself lives separately from the compute layer on its own storage system (see Neon), an auto-suspend is risk-free with regard to data loss — only the compute process is ended, not the place where the data is stored.

Comparison with other “scale-to-zero” systems

A related concept from the same “save money by scaling to zero” category is serverless compute in general (e.g. Vercel Functions or AWS Lambda itself) — there are cold starts there too, for similar reasons (a process/container has to be started before it can answer requests). The difference with Neon: with a typical serverless function, a cold start usually only affects ONE request (each request potentially gets a fresh function instance), whereas with a waking database the delay potentially affects ALL simultaneously arriving requests waiting on the same database connection — after all, there’s only one compute instance per database (branch), not arbitrarily many parallel instances as with serverless functions.

Other cloud databases with a similar principle: AWS Aurora Serverless v2 scales compute capacity dynamically but, compared to Neon, usually doesn’t shut down completely to zero (a minimum capacity stays active — correspondingly smaller savings, but also no real cold start). PlanetScale (MySQL-compatible via Vitess) has a different scaling model with no direct equivalent to auto-suspend.

Dealing with it in practice

Anyone who wants/needs to avoid cold starts (e.g. for latency-critical applications or frequent short usage pauses that keep triggering the timeout) essentially has three options: extend the auto-suspend timeout in the dashboard (postpones the problem but doesn’t solve it), upgrade to a plan with an “Always Active” option (disables auto-suspend completely in exchange for higher base costs), or keep the database artificially “warm” with a periodic health-check request (e.g. running a trivial query every few minutes via a cron job) — the latter, however, undermines the actual cost advantage of auto-suspend and isn’t really recommended by Neon itself.

See also: Neon, React.cache()