Configure sleep on inactivity

By default, Netlify Database pauses automatically after a set period of inactivity, and resumes the next time a query arrives. This capability is commonly known as scale to zero.

The default inactivity period is 5 minutes. If you have a Pro or Enterprise plan, you can configure a longer time period or disable this behavior completely, so the database stays always on.

Changing this setting is a direct performance vs. cost tradeoff:

• Pausing sooner reduces credit usage when traffic is light or intermittent, so that you don’t pay for compute the database isn’t using.
• Staying on longer (or always) eliminates the added latency associated with resuming the database (a.k.a. cold start), so the first request after an idle period is just as fast as any other - at the cost of paying for compute even while the database is idle.

The typical latency added during a cold start (when resuming a database) is well under a second, but this is not guaranteed. The right choice depends on how predictable your traffic is and whether occasional cold-start latency is acceptable.

For details on how compute time is billed, see Billing and usage.

Configure the timeout

1. Open the database dashboard.

2. Locate Sleep on inactivity in the stats area at the top of the page.

3. Pick one of the following options:

   • After 5 minutes (default)
   • After 15 minutes
   • After 1 hour
   • After 3 hours
   • Always on - the database never pauses

4. Save your changes.

Choosing a value

The options form a spectrum from “optimize for cost” to “optimize for performance”:

• After 5 minutes (default): a good default for most projects: short enough that an idle database isn’t burning compute, long enough that bursts of activity don’t repeatedly hit a cold start. Best for development environments and apps with bursty or unpredictable traffic.
• After 15 minutes / After 1 hour / After 3 hours: useful for workloads with intermittent but latency-sensitive traffic, where a cold start once an hour is acceptable but once every five minutes isn’t. For example, an internal dashboard that’s queried every 30 minutes.
• Always on: the database remains ready to serve requests immediately. This is the right choice for production workloads where any cold start is unacceptable, or for high-traffic apps that would rarely hit the timeout anyway. The tradeoff is that the database always consumes compute (and therefore credits), even during idle periods.

If you’re not sure where to start, leave it at the default and watch your usage. You can revisit the setting at any time as your traffic patterns become clearer.