How on-demand databases pause and resume

Most databases that agents create are busy for a few minutes and then sit idle: a preview environment nobody is looking at, a scratch database for one task, a test run that finished an hour ago. On-demand databases are built for this pattern. They pause when nothing is connected and resume when a client connects again, with no API call in between.

When a database pauses

An on-demand database pauses after about 10 minutes without connections. Any open connection counts as activity, including idle connections that an application pool keeps around.

While a database is paused, you are not charged for compute. Storage is still billed for the capacity you provisioned. See Pricing for current rates. If a database should stay running, turn off automatic pausing for it.

If your application should let its database pause, make sure the pool closes idle connections. With node-postgres, for example:

import pg from "pg";

const pool = new pg.Pool({
  connectionString: process.env.DATABASE_URL,
  idleTimeoutMillis: 30_000, // close connections idle for 30 seconds
  connectionTimeoutMillis: 15_000, // allow time for the database to resume
});

What happens on the next connection

A new connection wakes the database. You do not need to call the API first. In our measurements, the first connection to a paused database completes in about 7 seconds. During that time, the connection waits rather than failing, and the client sees a normal, if slow, connection.

The only setting that usually needs attention is the client’s connect timeout. Set it to at least 15 seconds so that the first connection after a pause does not time out:

• node-postgres: connectionTimeoutMillis: 15000, as shown above.
• libpq-based clients such as psql: add connect_timeout=15 to the connection string, or set PGCONNECT_TIMEOUT=15.
• Prisma: add connect_timeout=15 to the connection string.

Connections made after the database is running are as fast as usual.

How compute scales while it runs

While it runs, an on-demand database scales its compute between a minimum and a maximum that you set, measured in compute units (CU). The minimum can be as low as 0.5 CU, and the maximum can be up to 14 CU, depending on the region. New databases start with a range of 0.5–2 CU, which suits most agent workloads; you can change it at any time.

When to choose always-on instead

On-demand databases are a good fit when idle time is common and a few seconds on the first connection are acceptable. Choose an always-on database when:

• Every connection must be fast, including the first one after a quiet period.
• You need high availability with replicas.
• Your application relies on a connection pooler. Always-on databases include a PgBouncer pool on port 6432; on-demand databases accept direct connections on port 5432.
• The workload needs permissions beyond owner, pg_monitor, and pg_signal_backend, which are the roles on-demand databases currently support.

Both options run standard PostgreSQL, so you can start with on-demand and move a project to always-on with pg_dump and pg_restore when it grows.