arrow_back Back to Blog
lovable cloudsupabasepricing

Lovable Cloud vs Supabase: Which Should Your App Run On?

·

Half the Reddit threads on Lovable Cloud vs Supabase are arguing about the wrong thing. People compare them like two databases. They’re the same database. Lovable Cloud is a Supabase project that Lovable creates and runs for you, inside their account, billed through your Lovable balance. Your own Supabase is a Supabase project in your account, billed by Supabase.

Same Postgres. Same auth. Same storage buckets and edge functions. What changes is who holds the keys and who sends the invoice, and that turns out to matter a lot more than people expect in week one.

What you actually give up on Cloud

When a founder sends us a Cloud project to look at, the first thing we ask for is the database connection string. They go looking for it, and there isn’t one. That’s the whole comparison in a nutshell.

On Lovable Cloud you don’t get:

  • the Supabase dashboard (no table editor outside Lovable, no logs explorer, no auth settings page you control)
  • the service_role key, which a lot of “how do I run a cron job” or “how do I connect Zapier” tutorials assume you have
  • a Postgres connection string, so no pgAdmin, no TablePlus, no pg_dump on a schedule
  • your own plan choice for compute, disk or point-in-time recovery

You do get a SQL editor inside Lovable, and the agent can create tables and write migrations for you. For building, that’s honestly enough. For running a business on it, it gets thin fast.

Pricing, as far as anyone can tell

Supabase publishes a rate card. Free tier: 500 MB database, 1 GB file storage, 50,000 monthly active users, and the project pauses after a week of inactivity, which is fine for experiments and terrible for anything with customers. Pro is $25 a month per organization and includes an 8 GB database, 100 GB of storage and 100,000 MAU, with usage billed beyond that. You can open the usage page and see exactly which line is growing.

Lovable Cloud is usage-based and drawn from your Lovable balance. What Lovable doesn’t give you is the same per-unit breakdown. You see the balance move. We’ve had two clients this year who were sure their AI features were eating their Cloud usage, and in both cases it was something boring (one was an edge function on a 1-minute schedule polling a third-party API that never changed, the other was image uploads at full resolution).

So “which is cheaper” depends on your app, and the honest answer for a small app is that nobody can tell you up front. For an app with real traffic, owning the Supabase project is almost always cheaper to reason about, which is what you actually want when you’re the one paying.

When we’d tell you to stay on Cloud

Plenty of cases. If you’re still validating the idea, if nobody else needs database access, if your data is small and you’d shrug at losing a day of it, stay. Cloud is genuinely faster to start with. One click and you have auth and a database, and you’re not juggling two dashboards.

We’d also say stay if the only reason you want to move is a vague feeling that “real apps use Supabase”. That’s not a reason. Move when you hit a wall.

The walls people actually hit

These are the ones we see, roughly in order of how often:

  1. A second developer needs access. A freelancer asks for the connection string or wants to run migrations from their own machine. On Cloud there’s nothing to hand over.
  2. Backups. Someone deletes a row they shouldn’t have and asks “can we restore yesterday?” On your own Pro project you have daily backups, and point-in-time recovery is an add-on. On Cloud you’re asking support.
  3. Integrations that need the service role key. n8n, Make, a cron worker on Railway, a nightly export to Google Sheets. All of them want a key with admin rights.
  4. The bill. Usually not the size of it, just not being able to explain it to a co-founder.
  5. Compliance questions. A B2B customer sends a security questionnaire asking where data is hosted and who has access. “Inside Lovable’s account” is an awkward answer.

If two of those are true for you, it’s time.

How hard is the move, really

Not hard, but fiddly. Lovable now lets you export your Cloud data and switch the project to a Supabase project you own, from the Cloud settings, and you keep building in Lovable afterwards exactly like before. The schema and rows come across cleanly.

The fiddly part is everything around the rows. Storage files have to be moved separately. Secrets arrive as names with no values, so every Stripe key and API token gets pasted in again. Google and GitHub OAuth providers get set up from scratch, including the redirect URLs, which is where most DIY migrations stall for an evening. And user passwords. Depending on how the export is done, your users may need to reset them, so write that email before you start.

We did one last month for a booking app with 23 tables and about 4,000 users. The data moved in under an hour. The OAuth redirect for Google took longer than the data, because the client’s custom domain was set up on a www subdomain in one place and the apex in another. That kind of thing.

If you want to see what the move involves for your app, the Cloud to Supabase migration page lists exactly what we move and what breaks, and how we work explains the access we need. Or skip the reading and book a call.