Serverless Postgres cold start explained

A cold start occurs when the compute that runs your database has been put to sleep by inactivity, and a new query must first restart it before running. This is not the usual network latency of a typical TCP/TLS connection: this is the time to spin up a new Postgres process and restore its state, even before the first request starts executing.

The term comes from serverless computing broadly, where a zeroed execution environment must restart before processing a request, whether it is a server function or a WebAssembly runtime at the edge. We detail this mechanism on the edge functions side in our article on cold start WebAssembly facingcontainers. For a database, the mechanics differ: it is not a compiled binary that starts, but a complete Postgres server which must reopen its files, validate its state, then accept new connections.

1. Customer Login

A request arrives on a project whose compute is suspended.

2. Sleep detection

The platform notices that the compute is no longer active.

3. Restarting the compute

The Postgres process restarts, the necessary state is restored.

4. Request processed

The connection is successful, the request executes normally.

Illustration of the cold start mechanism, simplified sequence, without measured time value.

Neon separates its database architecture into two distinct layers: persistent storage that keeps the data, and compute, the Postgres process itself, which can be stopped and restarted independently. This separation allows Neon to suspend the compute of an inactive project without touching the data, then restart it on demand, according to its official documentation.

On the free plan, Neon documents a default inactivity timeout of 5 minutes before putting the compute to sleep. Paid plans allow you to configure this threshold, or even significantly increase it for use with constant traffic. This type of default changes with product updates: check the Neon documentation up to date at the time of reading rather than this isolated figure.

This design serves a specific purpose, ephemeral environments. A database per Git branch, a preview environment by pull request, a test database which is only used for a few minutes per day: running a compute continuously for these uses is expensive with no real benefit. Suspending the compute between two uses reduces the bill without deleting the data, this is the central argument of Neon's serverless model.

Neon indicates in its documentation a compute restart typically on the order of a few hundred milliseconds to a few seconds, depending on the size of the project and the volume of transaction logs to be replayed before the compute is ready. This is a figure published by the publisher itself, not an independent audit: treat it as a documented order of magnitude, not as a contractual guarantee.

For real-world measurement, a public community tool, neon-latency-benchmarks.vercel.app, polls suspended Neon projects at regular intervals and displays the observed wake-up latency. This is the type of methodology that matters more than a bare documentation figure: test conditions remain visible, not hidden behind a marketing average. We apply the same principle in our own backend benchmark methodology: publish the protocol before publishing a figure.

Vercel has built its Postgres database offering based on Neon infrastructure, a partnership made public in 2024. At the time of writing, this Postgres integration is offered in the Vercel Marketplace as a storage option alongside other providers. Check the updated Vercel product page: this type of partnership evolves quickly in a market that changes every quarter.

Concretely, the sleep and wake-up behavior of a Postgres database provisioned via Vercel follows the same mechanics as that described above for Neon directly. It's not a separate engine with its own cold start model, it's the same infrastructure exposed behind a Vercel integration.

No, not in the same way. Supabase provisions a dedicated Postgres instance per project rather than a serverless compute suspended per connection. There is therefore no wake-up delay added to each new session after a few minutes of inactivity, unlike the Neon model.

A different mechanism, however, exists on the free plan: Supabase documents an automatic pause of inactive projects after an extended period, of the order of a week according to its documentation, with manual restoration from the dashboard rather than an automatic wake-up on the first request. It's a threshold measured in days, not minutes, and an explicit action rather than a transparent recovery: two structural differences with the Neon cold start, not a simple variation of the same mechanism. For a complete architecture comparison, our detailed Aurabase vs Supabase comparison documents other discrepancies.

Aurabase does not offer a serverless model like Neon. Verified in the provisioner code (aura-provisioner, open source on github.com/daylami555/aurabase): each project receives either a dedicated Postgres cluster managed by CloudNativePG, the Kubernetes CNPG operator, or a dedicated base on a CNPG cluster shared between several projects of the same organization, depending on the chosen plan. In both cases, it is not a single compute that suspends and wakes up at each connection: it is a complete Postgres cluster, with primary and possible replicas.

A hibernation mechanism does exist on the Aurabase side, but it serves a different purpose. On prolonged inactivity, 7 days by default and configurable via an environment variable, threshold verified in the code, the provisioner puts inactive instances to sleep to free up resources, not to optimize the latency of intermittent use. Waking up a sleeping CNPG cluster recreates its pods from persistent volumes, a structurally heavier mechanism than a simple serverless process restart.

This dedicated architecture has a direct counterpart in terms of isolation and performance predictability: a project does not share its compute with another project, unlike a poorly sized shared cluster. We detail this arbitration in a dedicated article: dedicated vs shared base, real impact on performance and isolation.

The Neon serverless model serves a specific use case: many ephemeral environments or environments with very intermittent traffic, where paying for a compute that runs continuously does not make economic sense. A database per Git branch, a preview environment by pull request, a prototype tested a few times a week: the occasional cold start becomes an acceptable compromise against an invoice proportional to actual use.

Conversely, a dedicated, always-on Postgres architecture becomes preferable whenever first connection latency needs to remain predictable: a production API with regular traffic, a backend that cannot afford an occasional latency spike on a user request, or a system where p99 matters more than the cost of an isolated test branch.

Neon Alarm Clock: order of magnitude documented by the publisher, not independently audited. Aurabase hibernation threshold: checked in aura-provisioner, variable HIBERNATE_INACTIVITY_DAYS, default 7 days.

The Postgres serverless cold start is not a universal concept: it is a direct consequence of the Neon architecture, which separates storage and calculation to suspend the latter between two uses. Vercel Postgres inherits it directly via its partnership with Neon. Supabase and Aurabase, which provision dedicated Postgres instances, expose a different mechanism, measured in days rather than minutes, not designed for the same purpose.

Before choosing a provider on this criterion alone, check three things: the actual inactivity threshold documented by the provider, whether it is configurable on your plan, and whether your application traffic justifies computing that suspends. For use with real intermittent traffic, test branches or previews, the serverless model has a clear economic benefit. For production with regular traffic, a dedicated architecture simply eliminates the question.