<!-- section: Data API · status: building · source: docs/data-api/06-sleeping.md -->

> Scale to zero, what the first query after a quiet spell costs, and what that saves.


# Sleeping and waking

A database with nothing connected to it **stops after five minutes** and starts
again on the next connection.

This is the single fact that makes a database per project affordable, and the
single thing that will surprise you.

## What it costs you

The first connection after a quiet spell waits **a second or two** while the
compute starts. Everything after that is a normal Postgres connection with no
penalty at all, and the compute stays up for five minutes past the last one.

An application with steady traffic never sees it. A staging environment nobody
touched since Friday sees it on Monday morning, once.

## What it saves you

Compute is billed only while it is awake. A project that gets a visitor an hour
pays for a few minutes of compute a day rather than for a server running all
night — which is the difference between a database costing pennies and costing
dollars.

Storage is unaffected: your data is held whether the compute is up or down, and
that is the part the [minimum](/docs/data-api) covers.

## Do not keep it awake

The obvious trick — a cron job pinging the database every four minutes — costs
more than it saves. It converts a few minutes of daily compute into twenty-four
hours of it, to avoid a delay measured in seconds, on requests nobody is waiting
for.

If a cold start genuinely hurts on a user-facing path, the honest fixes are:

- **Connect at the edge of the request, not lazily mid-render.** The wake happens
  in parallel with the rest of your page rather than after it.
- **Cache what does not need to be live.** A homepage that reads the same six
  rows every time should not be waking a database to do it.
- **Tell us.** The idle timeout is per project and adjustable; longer costs more
  and we will say by how much.

## Autoscaling, while it is awake

The compute moves between **0.25 and 4 CU** on its own, following what your
queries need. You are billed for what it actually used, per compute-hour, not
for the ceiling.

Neon's own default for a new project is a fixed 1 CU. Ours starts at a quarter
of that deliberately: a quiet site should not pay for a whole compute unit
because somebody visited it.

If your workload needs more than four CU, that is a conversation rather than a
limit — but it is usually a query that wants an index.
