1. Request to Clear Supabase Storage Due to Quota Restriction

[Falcon-Street77]

Hello Supabase Support,

My project has been restricted due to exceed_storage_size_quota.

My project is currently on the Free Plan, and I do not want to upgrade.

Storage details:

• Bucket: delivery_proofs
• Folder: deliveries
• Total files: 2,262
• Total storage: approximately 2.94 GB
• Free Plan limit: 1 GB

I have already downloaded and backed up all required patient records, delivery records, locations, and delivery proof images.

I want to permanently clear all files from the delivery_proofs bucket to bring my storage usage below the Free Plan limit.

However, I cannot access the Storage dashboard because the project is restricted.

Please help me temporarily restore Storage access or remove all objects from this bucket.

IMPORTANT: Please keep my database tables, patient records, delivery records, drivers, and project configuration intact. I only want to clear Storage files.

I do not wish to upgrade my plan.

Thank you.

[GaryAustin1]

You will need to contact their support thru the ticket system in upper right of dashboard under feedback.
There is no guarantee they will give you relief. They normally give a grace period to resolve this and if you did not resolve before then are stuck with what they decide. It will not reset at start of next period. I don't have a good feel for how often they give relief for this particular issue.

[tisankanj]

One detail to preserve in your support request: ask to empty only delivery_proofs, retaining the bucket and its configuration, rather than deleting the project or clearing database tables. Gary's support route is still necessary if the restriction blocks Storage operations.

Don't work around this with DELETE FROM storage.objects. Supabase's deletion guide explains that SQL removes metadata without deleting the underlying files, leaving orphaned objects. It won't accomplish the cleanup you want.

If support restores Storage access, use the Storage API/dashboard to empty the bucket. If you instead delete an explicit list with remove(), the documented limit is 1,000 paths per call, so 2,262 objects need at least three batches. Check each result and list the remaining objects afterward; don't assume the first page of a listing contains everything. Stop uploads while doing the cleanup so new files aren't mixed into the deletion set.

Before deleting, verify that your backup contains the actual image files, not just database rows or signed URLs. Keep the original object paths with the backup so delivery records can still be matched to the files. Emptying Storage will leave existing database links pointing to missing objects unless the application handles that state. None of this bypasses the restriction or guarantees that support will grant temporary access.