Plans, resizing and storage limits

1. Plan types

• High availability: two servers in different sites of the same region, automatic failover, a read replica endpoint and plan changes in place. See High availability and replication.
• Single node: the same sizes on one server, for 30% less. Same backups and 7-day restore; if the server fails, the database is restored from backup on another server.
• Dev: a small single-node database for development and testing, with a shared CPU (0.5 vCPU), 1 GB RAM and 5 GB of storage. Up to 2 per account, and no SLA.

On paid plans, every vCPU is reserved for your database: we do not overcommit CPU. Only Dev shares its CPU.

2. Connections and tuning

PostgreSQL settings are tuned to each plan's memory. The connection limit is 50 per GB of RAM, up to 400. For example, a plan with 4 GB of RAM allows 200 connections. If your application opens many short connections, use a connection pool in your application.

3. How to change plans without downtime

On high-availability plans, open the database and choose Change plan, or call POST /api/v1/databases/{id}/resize with the new plan_id. You can move to any other high-availability plan, bigger or smaller, as long as there is capacity for it in your database's region (if there is not, the request is refused and nothing changes).

What happens:

1. The standby is rebuilt at the new size from backups.
2. It takes over as primary.
3. The other server is rebuilt at the new size and becomes the standby.

The database stays online throughout, and the hostname, port and password do not change. At each switchover, open connections are closed and your application reconnects, so use a driver or pool that retries. Billing switches to the new price, prorated to the day.

Moving to a smaller plan

A plan with less storage only accepts your data if it is under 85% of the new plan's storage. For a 20 GB plan, that means under 17 GB. If your database is bigger, the change is refused before anything is touched; free space first, or pick a bigger plan.

Dev and single-node databases

These cannot be resized in place. To move to another plan, restore into a new database on the plan you want, switch your application over, then delete the old database. Resizing single-node plans is on our roadmap.

4. Storage limits: what happens when your database is full

Each plan includes a fixed amount of storage. It counts everything on the database's disk: tables, indexes and the write-ahead log (WAL) that PostgreSQL keeps for recovery and replication.

• At 85% and 95% of the plan's storage, you get an email and the database page shows a warning.
• At 100%, the database becomes read-only: reads keep working, and writes fail with cannot execute INSERT in a read-only transaction. You get an email when this happens.

Read-only protects your data: a database whose disk fills up completely can stop, and so can its standby.

To get writes back, either free space or change to a bigger plan. In a session, you can turn read-only off to clean up:

SET default_transaction_read_only = off;
DROP TABLE old_events;   -- or TRUNCATE, or DELETE followed by VACUUM

The database becomes writable again by itself, within about a minute, once its storage is 5% of the plan below where it stopped (and under 95%). The full guide, with queries to find what takes the space, is When your database is full.

5. Billing when you change plans

Billing is by the day. A day is billed at the largest plan the database had that day. Moving to a more expensive plan is charged from the start of today; moving to a cheaper one is credited from the start of tomorrow. Prices exclude VAT. See the Terms of Service for the billing terms.