The size cap
The free plan includes 500 MiB per project database and Pro includes 8 GiB. The cap exists to keep backups and restores predictable.
The operational size cap for a project database is 500 MiB on the free plan and 8 GiB on Pro.
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 handles larger databases. The cap is about restore time.
Backups carry only the commits made since the previous one, so taking one costs what you wrote. Restoring replays that chain in order, so it costs the size of the database you are bringing back. The cap is where a restore stays comfortably inside the time and memory reserved for it — which is what keeps a restore predictable on any plan.
Checking your current usage
runlot usageThe same number is shown on the database tab of the dashboard, with the cap for your plan.
Compared with other services
| Service | Size |
|---|---|
| runlot Free | 500 MiB |
| runlot Pro | 8 GiB |
| Cloudflare D1 | 5 GB free, 10 GB per database on paid plans |
| Supabase | about 500 MB free, 8 GB on Pro |
The database runs on the same machine as your app, so env.db calls involve no network round trip.
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. Treat it 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 10 GiB.