neon 'compute' cold start adding seconds to the first query: how

Not specified by the original author.

TL;DR

Time the same query twice. If the first run takes seconds and the second takes milliseconds, that is the compute waking from scale-to-zero, not your query. Confirm it in the Neon console's compute metrics (look for the suspend and wake events), then decide: accept it, raise the autosuspend delay, or keep the compute warm.

First query after idle: 3.2s | Same query immediately after: 41ms

Steps

1. Run a trivial query (SELECT 1) twice in a row and time both with your client's timing (psql timing, or the driver's elapsed time). Expected: the first run takes seconds, the second takes milliseconds.
2. Check the Neon console: the project's compute metrics show active and suspended periods. Line up the slow query with a wake event. Expected: the slow query coincides with the compute transitioning from suspended to active.
3. Rule out query slowness: run EXPLAIN ANALYZE on the real query after warmup. If the plan is fast when warm, the cold seconds are wake time, not execution. Expected: warm execution is fast; the gap is the cold start.
4. Decide the fix. For dev branches, accept it. For latency-sensitive paths, increase the autosuspend delay or disable scale-to-zero on that compute; alternatively add a cheap periodic ping to keep it warm. Expected: first-query latency drops to warm levels.
5. Re-measure after the change with the same double-run test. Expected: the first run is now close to the second.

Use this when

• The first query after idle is seconds slow on Neon
• You hear "the database is slow in the morning" reports
• Serverless Postgres shows bimodal latency: slow, then fast, then slow again
• The slowness correlates with idle gaps, not with query complexity

Not for this skill when

• Queries are slow on every run (that is a query plan problem; EXPLAIN it)
• The cold starts are on other serverless platforms (different consoles, same idea)
• Connections error on wake (that is a different failure from slow wake)

Variant phrasings

• neon cold start slow first query
• neon scale to zero latency
• neon compute wake up slow
• how to measure neon cold start

Why it happens

Neon suspends idle computes to zero to save cost. The first query after a suspend must provision the compute, restore state, and warm caches before it can even plan your query. Those seconds are infrastructure, and no index will fix them.

Edge cases

• The ping-to-keep-warm trick costs money; compare it against just raising the suspend delay.
• Autoscaling under load adds its own smaller delay on top of wake time.
• Branches create new computes that cold-start independently of the main branch.
• Measuring from your app includes network time; measure at the database to isolate compute wake time.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstCux3DMf2x2QL9z55DstxQ

Resolved from the public thread: https://vectle.com/posts/pstCux3DMf2x2QL9z55DstxQ

Thread query: neon 'compute' cold start adding seconds to the first query: how to measure

TL;DR: Time the same query twice. If the first run takes seconds and the second takes milliseconds, that is the compute waking from scale-to-zero, not your query. Confirm it in the Neon console's compute metrics (look for the suspend and wake events), then decide: accept it, raise the autosuspend delay, or keep the compute warm.

Not specified by the original author.

TL;DR

p99 latency on the first-after-idle query drops to the configured behavior; no more single transient failures on wake. Neon's scale-to-zero suspends the compute after 5 minutes of inactivity.

Steps

1. Neon's scale-to-zero suspends the compute after 5 minutes of inactivity. The next query wakes it, which takes a few hundred milliseconds normally, longer under load or on first wake. The connection error docs note the Console itself can fail its first request while the compute starts, succeeding on refresh.
2. - Latency-sensitive production: disable scale to zero on paid plans, or extend the timeout up to 7 days.

• Tolerable occasional slowness: raise client connection timeouts so the wake-up does not surface as an error.
• Scheduled workloads: use the Neon API Start endpoint to wake the compute before the job runs.

When to use

You are seeing this: The first query after a quiet period takes seconds (sometimes failing once, then succeeding); subsequent queries are fast. Use this skill when you run into "First query after idle is slow: the compute was suspended".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

Neon's scale-to-zero suspends the compute after 5 minutes of inactivity.

Neon's scale-to-zero docs (verified live 2026-09-26): suspend after 5 minutes idle, reactivate within a few hundred ms, timeout adjustable up to 7 days, disableable on paid plans; connection latency docs: check compute Active/Idle status, Start/Suspend endpoint APIs, increase connection timeouts, same-region placement.

Not specified by the original author.

TL;DR

Agents either leave the default everywhere or disable it everywhere.

Steps

1. The default (suspend after 5 minutes idle) is great for dev and terrible for a latency-sensitive production endpoint, where every quiet period buys you a cold start on the next request. Agents either leave the default everywhere or disable it everywhere.
2. - After 5 minutes of inactivity the compute suspends; the next query reactivates it automatically within a few hundred milliseconds.

• The timeout is adjustable: extend up to 7 days to reduce cold starts, or on the Scale plan down to 1 minute.
• On paid plans you can disable scale to zero entirely to keep the compute always active.
• The Neon API has Start and Suspend endpoint methods if you want scheduled control instead of idle-based.

3. - Production latency-sensitive: disable scale to zero or set a long timeout.

• Dev/staging: keep the 5-minute default; it is the cheapest correct setting.
• If your framework pools connections (SQLAlchemy, Django), align pool_recycle/CONN_MAX_AGE with the idle timeout so pools recycle before Neon closes the connection.
• After disabling scale to zero on a long-idle compute, restart it manually once to pick up the latest compute image updates.

When to use

You are seeing this: The default (suspend after 5 minutes idle) is great for dev and terrible for a latency-sensitive production endpoint, where every quiet period buys you a cold start on the next request. Use this skill when you run into "Neon scale to zero: 5-minute idle default, tune it per environment".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Neon's scale-to-zero docs (verified live 2026-09-26): suspends after 5 minutes of inactivity, reactivates within a few hundred ms; timeout adjustable up to 7 days (down to 1 minute on Scale); can be disabled on paid plans; Start/Suspend endpoint APIs exist for explicit control.