The 150 MB size cap
The same database size cap applies on every plan. It exists to keep backups fast.
The operational size cap for a project database is 150 MB, regardless of plan.
Do not estimate by row count
Indexes and page overhead outweigh the raw data. One measurement: 61,000 rows (5.5 MB as JSON) used 80 MB with nine indexes. Budget 10–15× the raw size, then confirm with runlot usage after loading.
Why there is a cap
The engine itself can handle larger databases. But with the current approach, backing up a 420 MB database takes 107 seconds and uses 4.57 GB of memory. During that time, that project's database requests have to wait.
To offer hourly backups, the cost of a single backup has to stay manageable. So for now the cap is set at 150 MB, the point where that holds.
Once incremental backups — backing up only changed data — are in place, this cap can be raised.
Checking your current usage
runlot usageThe same number is shown on the database tab of the dashboard.
Compared with other services
The current size cap is smaller than what other services include for free.
| Service | Size |
|---|---|
| runlot | 150 MB (all plans) |
| Cloudflare D1 | 5 GB free |
| Supabase | about 500 MB free |
In exchange, the database runs on the same machine as your app, so env.db calls involve no network round trip. This design prioritizes fast responses over large volumes of data for side projects.
As you approach the cap
When you reach 90% of the cap, we send a db_near_cap notification to the organization's admin. The alert comes ahead of time, not after you have already exceeded the cap.
Nothing rejects a write at the cap today. Two things degrade instead: each hourly backup takes longer in proportion to the database size, and above roughly 240MB a project that has gone cold can fail to resume (restore_too_large). Treat 150MB as the size we support, not as a wall that will stop you.
Store large binary data such as images and attachments in file storage rather than the database. The free tier includes 1 GiB.