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.

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.