Database size, connection and query limits per plan, and what happens when a database is full.
| Limit | Free | Pro | Scale | Enterprise |
|---|---|---|---|---|
| Database size | 500 MB | 10 GB | 20 GB | 20 GB |
| Direct database connections | 20 | 100 | 160 | 300 |
| Pooled client connections | 1,000 | 10,000 | 15,000 | 20,000 |
| Pooler database connections | 5 | 20 | 30 | 40 |
| API query timeout | 8 s | 30 s | 60 s | 60 s |
| Read replicas per project (paid add-on, up to) | 0 | 1 | 1 | 2 |
| Backup retention | No backups | 7 days | 14 days | 30 days |
| Point-in-time recovery | 1 days | 7 days | 14 days | 30 days |
The database size limit applies to each project on every plan (with the spend cap off, a project may go over and the extra GB-months are billed; see Spend cap and usage pricing). The API query timeout applies to REST requests; the SQL Editor allows up to 60 seconds.
#When the database is full
StitchDB checks database sizes every few minutes and e-mails you when a project reaches 80% and again when it goes over 100%. Over the limit the database becomes read-only, and nothing is deleted:
- REST API requests that write (including deletes) fail with This project is over its database size limit and is read-only (error code
25006). - New transactions on database connections are read-only by default.
- Reads keep working.
To free up space, run the setting together with your deletes in the SQL Editor (or in a session-mode connection):
set default_transaction_read_only = off;
delete from public.events where created_at < now() - interval '90 days';
vacuum public.events;truncate and drop table free space right away; space from deleted rows is reused after vacuum. Writes resume within a few minutes once the database is below the limit or your plan allows more.