Storage limits and quotas

This page lists every limit that applies to Storage on SupaHost and how file storage is measured and billed. Limits that apply to the whole instance are shared by all projects on it.

Per-file and per-project limits

The 50 MB limit applies to every upload path: upload(), update(), signed upload URLs and Studio's Storage browser. An upload over the limit is rejected with a "maximum allowed size" error. See Upload file size limits.

File storage and egress by plan

File storage and egress are pooled across all projects on an instance.

Enterprise limits are agreed per contract. See Plans and limits.

If you need more:

Add-ons are set in Dashboard → Usage & billing → Add-ons. See Usage, quotas and add-ons.

How file storage is measured

File storage usage is the total size on disk of each project's storage directory, added up across the instance. A few things follow from that:

• Every file counts at its full size, whatever bucket it's in, public or private.
• Overwriting a file with upsert replaces it, so only the new version counts.
• Files deleted through the Storage API stop counting once they're removed from disk.
• Rows you delete from storage.objects with SQL don't remove the files on disk, so they keep counting. Always delete through the API (remove(), emptyBucket(), or Studio's Storage browser).
• A branch created with "Copy data, users and files" has its own copy of the files, which counts too.

To see which buckets use the most space, query the metadata in Studio's SQL editor:

select
  bucket_id,
  count(*) as files,
  pg_size_pretty(sum((metadata->>'size')::bigint)) as total_size
from storage.objects
group by bucket_id
order by sum((metadata->>'size')::bigint) desc;

This adds up the sizes Storage recorded for each object. The figure in the dashboard comes from the disk, so it can differ slightly, for example when files were left behind by direct SQL deletes. See Unexpectedly high storage usage.

How egress is measured

Egress is the size of responses your instance sends, measured from the gateway's access logs. For Storage that means every download, public URL request and signed URL request that the instance serves. Uploads don't count.

There's no CDN in front of Storage, so you lower egress by making sure browsers cache files. Set cacheControl when uploading and use unique paths for files that change. See Serving and downloading files and Egress on SupaHost explained.

Alerts and going over

SupaHost emails the instance owner as file storage and egress approach the plan amount plus add-ons. Alerts fire once per level per month, at the threshold you choose (80%, 90% or 100%) and at 100%. You can change the threshold or turn usage alerts off in Dashboard → Settings → Email notifications.

Usage beyond your plan and add-ons is billed at the overage rates above. Uploads aren't blocked when you pass the included amount. See Quota alert emails and going over.

Disk space

Storage files live on the instance's disk, next to the Postgres data. The disk grows automatically when it's 60% full, online and without a restart, so you don't need to manage disk size yourself. Disk size is separate from your billing quota: you're billed for file storage and database size, not for the disk.

Backups

Storage files are not included in the daily database backups or point-in-time recovery, and a restore doesn't roll files back. Bucket settings and object metadata live in the database, so they are backed up and restored with it.

To keep a copy of the files, use Dashboard → your project → Backups tab → Package files. It creates a .tar.gz of all files plus buckets.json and objects.json. The export needs free disk space of about 1.1 times the files' size plus 512 MB, and the download link lasts 24 hours. See Exporting your data and A restore didn't bring back Storage files.

Related

• Limits reference
• Storage on SupaHost
• Cleaning up failed or partial uploads