The message usually shows up on a Tuesday. Somebody's app has been live for six weeks, users are uploading things, and the Cloud usage bar in Lovable is suddenly orange. They search "lovable supabase storage quota", find three forum threads that disagree with each other, and email us.
So this is the post we keep half-writing in those emails.
Lovable Cloud is Supabase you can't see
Worth getting straight first, because it explains everything else. Lovable Cloud runs on Supabase. Your tables, auth users, storage buckets and edge functions live in a real Supabase project. You just don't own that project. There's no Supabase dashboard login, no service role key, no database connection string, and usage comes out of your Lovable Cloud balance instead of a Supabase bill.
That's a fine deal for a weekend build. It gets awkward once the app has users, because the two things you need when storage fills up (seeing exactly what is taking the space, and choosing a bigger plan) are exactly the two things you don't get.
Lovable also doesn't publish a per-GB price for Cloud storage or database size. You see a balance going down. You don't see a rate card.
Where the space actually goes
In the apps we've opened up, it's almost never the database rows. A Postgres table with 40,000 orders is a few megabytes. The usual suspects:
Original-size images. A profile photo upload with no resizing means every iPhone picture lands as a 3 to 5 MB HEIC or JPEG. One client had a "post a photo of your meal" feature. 900 users, 11,000 photos, a little over 30 GB, and the app only ever displayed them at 400 pixels wide.
Files nobody deletes. The user replaces their avatar, the app writes a new file, the old one stays in the bucket forever. Same with abandoned uploads, draft attachments, and the PDF invoices regenerated every time someone opens the billing page.
Logs in a table. This one's sneaky. Lovable will happily build an activity_log or ai_requests table that stores the full prompt and the full response for every call. We found one at 2.1 GB on an app with 300 users. Nobody had ever queried it.
Run this in the SQL editor Lovable gives you to see your biggest tables:
select relname as table_name,
pg_size_pretty(pg_total_relation_size(relid)) as total_size
from pg_catalog.pg_statio_user_tables
order by pg_total_relation_size(relid) desc
limit 10;
Storage buckets are harder to size from inside Lovable. You can count objects per bucket with select bucket_id, count(*) from storage.objects group by 1; and the metadata->>'size' column on storage.objects gives you bytes per file if you want to sum them.
Fixes that buy you time
Resize on upload. Seriously, do this before anything else. Ask Lovable to compress images client-side to around 1600 pixels on the long edge before they hit storage. On the meal-photo app that one change cut new uploads by roughly 85%.
Then clean up. Delete orphaned files by comparing storage.objects against the URLs your tables actually reference. Truncate or archive log tables older than 30 days. Stop storing full AI responses unless you genuinely read them later. Most people don't.
None of this is glamorous, and honestly a lot of apps can stay on Lovable Cloud for months after a cleanup like this.
When it stops making sense
There's a point where you're fighting the setup instead of the problem. For us the signs are pretty consistent:
- you need a bigger database or more storage and want to pick the plan yourself
- you want backups you can download, or point-in-time recovery
- a contractor or a second developer needs real database access
- you're paying for Cloud usage and can't tell which feature is causing it
At that point moving to your own Supabase project is usually cheaper and calmer. Supabase's free tier gives you 1 GB of file storage and a 500 MB database, and the Pro plan at $25 a month includes 100 GB of storage and an 8 GB database, billed by Supabase directly, with a dashboard that shows you every table and every bucket.
Lovable now has an official way out. Under Cloud, then Overview, then Advanced settings, you can export your project data and remove Lovable Cloud, then connect the same Lovable project to a Supabase project you own. You keep building in Lovable like before.
The catch is what the export leaves behind. Storage files have to be downloaded and re-uploaded. Secrets come across as names without values. OAuth settings get recreated by hand. And passwords are the one that bites: the standard export can't carry them in a usable form, so depending on how you migrate, your users may need a reset email. Plan that message before you flip the switch, not after the support inbox fills up.
You can absolutely do this yourself with an afternoon and some patience. If you'd rather not, this is the exact job we do every week. Our Lovable Cloud to Supabase migration is a fixed price based on how many tables you have, and the first step is just giving us access to your Supabase organization.
Originally published on lovable2live.com. Aakash Verma, software developer and founder of Lovable 2 Live.
Top comments (0)