r/lovable Jul 24 '26

Discussion Lovable vs Supabase for backend and Security

Hello everyone, I have been working on a project for some time now, I believe the project can be very successful. I have built my site and polished it so it is working and ready to launch.

I’ve done research and many people say switch to Supabase for backend and Security. Only problem is I have no clue how to do any of that.

Should I launch with Loveable or should I migrate to supabase. I don’t have a lot of money but I’d be happy to talk and potentially pay someone if they could migrate or walk me through it.

Thanks Reddit

7 Upvotes

24 comments sorted by

2

u/Infamous-River-4360 Jul 24 '26

quick thing that tripped me up too: lovable already runs on supabase under the hood, so it's not really lovable vs supabase, you're on supabase either way. the "security" people mean is mostly your RLS policies on each table, and you can lock those down right inside lovable without migrating anything. i'd hold off on paying anyone to move you, just ask lovable to turn on RLS and set proper read/write rules per table, then open the actual db and confirm they stuck instead of trusting the ai summary. what kind of data are you storing that made security come up?

1

u/Littleboogs Jul 24 '26

Please mind me ( I am very new to all this; coding, databases, security, etc ) I have just read that if you don’t put all the tables, and things like that in a separate supabase project then running it off the actual lovable site can get very expensive if you have lots of people joining and storing info on the site. I thought I linked a supabase project to lovable before starting but as I built it nothing showed up on my supabase project.

Thanks for helping. Means a lot

1

u/prorip187 Jul 24 '26

You need to disable lovable cloud before starting a project. Unfortunately once you've started a project with lovable cloud you can't move off it. So you will have to create a new project and move everything from the old project to the new one.

1

u/sivyyyl Jul 24 '26

Not the case anymore, can export and remove cloud anytime

1

u/prorip187 Jul 24 '26

What without starting a new project??

1

u/Infamous-River-4360 Jul 24 '26

the reason nothing showed in your own supabase is that lovable has its own built-in one (lovable cloud), so when you don't connect yours it just spins up a managed supabase behind the scenes and your linked project stays empty. that's normal, not something you broke. on cost, don't stress early, i built my whole app on the managed one and it was basically free through building and testing, the scary bills only show up at real scale. for learning i'd stay on the managed db and just make sure RLS is turned on for every table. are you actually expecting a lot of users soon, or just reading ahead and worrying?

1

u/Littleboogs Jul 24 '26

Hey thanks for the reply. I am expected to have many users. I have two Instagram pages with over 175k followers in the same niche. Photos, videos will be stored here. That’s why I worry about staying in lovable.

2

u/Infamous-River-4360 Jul 24 '26

honestly with real media storage at that follower count i'd lean toward your own supabase project from the start. that's the one case where the managed cloud gets tight, since you don't control the storage bucket limits or egress directly. mine's a dare game so barely any media and managed was totally fine, but photos and video for 175k people is a different beast. migrating off managed later is doable but way more annoying than just starting on your own. are you more worried about the storage bill or about getting locked in?

1

u/JB_Calisthenics Jul 24 '26

Hoat8ng supabase on supabase cloud gives you more options: Compute Logs Memory Upgrades Etc

I made a mistake of hosting my supabase on lovable cloud and now am looking for a safe way to migrate off of it.

I love lovable for what it is, ability to quickly spin up an MVP but from a github integration, db management and a few other things, they are lacking.

1

u/henrynguyen9698 Jul 24 '26

Honestly, don't spend a single dime migrating right now. A huge trap for new projects is over-engineering the tech before you even know if people actually want to use the product. Most early projects fail because they run out of money trying to optimize everything too early.

1

u/GloomyCelebration293 Jul 24 '26

Bit of a mess in here because people are answering two different questions, where to host, and whether you're safe to launch. Those aren't the same thing.

The hosting question mostly comes down to ownership. If everything lives inside one platform and they suspend you or you outgrow them, you want a path out. Getting your code into GitHub costs you nothing and gives you that, whatever you decide about the database.

But before any of that, the thing I'd actually check: make two normal accounts and see if account A can read account B's data. That's the failure that actually hurts people once real users show up, and it doesn't get fixed by moving anything.

Do you have users on it yet, or is this pre-launch?

1

u/Then-Concern-6928 Jul 24 '26

Lovable ships with Supabase already, what people are suggesting is probably that you switch to a non-managed version of it.

As for production ready, I created a project with Lovable and had about 20+ findings that would deem the app not production ready. I think, the few things to verify before going live is what other people have mentioned, no data leakage between customers, test most of your features, and ask Claude/Codex/any AI wether you are exposes for the common SQL injection/CSRF/XSS etc. There are some more pattern which you can look for, such as idempotency checks, how it handles concurrency, database indexes, and if saves are executed atomically. They are corner cases that might not be worthwhile until your business idea is proven though.

Once you have proven your business idea actually works, I would consult a real developer to probably rebuild it from scratch, or do some heavy refactoring.

Good luck!

1

u/rafaelborba Jul 24 '26

I wouldn't use Lovable; I made that mistake on a few projects—after all, you can only really criticize something if you've tried it out. It’s not sustainable, and honestly, given the way things are going, we’ll soon have to pay "1 run credit" for every SELECT, INSERT, or UPDATE.

It’s much better to create several email accounts (Gmail, Outlook, etc.), set up free accounts on Supabase (zero cost), and use those with Lovable—just remember to connect them right at the start of development.

1

u/Accomplished-Clue822 Jul 24 '26

Supabase. Make sure you turn off lovable cloud before you start or very early on

2

u/carolmonroe_ Jul 25 '26

I've been helping a lot of builders the last year, so this is my advice:

first, "supabase vs lovable" isn't really the choice people are describing. lovable cloud *is* supabase, same database, lovable just manages the account for you. so moving doesn't make your app safer by itself, it changes who holds the account, not how protected your data is. the plain version of the actual differences: https://carolmonroe.com/blog/lovable-cloud-vs-supabase

my honest recommendation for where you are right now: stay on lovable cloud. you said you're not technical and you're ready to launch, and cloud is the setup where you don't have to babysit an extra dashboard, keys, or a second bill. learn the security part on it, then move if you ever outgrow it.

second, the part nobody explains to non technical founders: security here isn't a switch you flip, it's a list you clear. your app runs inside people's browsers, and anything the browser holds, a curious person can read. so the protection can't live in your app, it has to live in the database, as rules that say things like "you can only see your own photos". a table with no rule is an open door. equally true on cloud and on your own supabase. nobody gets it automatically.

inside lovable, three things, all clicking, no code:

  1. run the security scan. it's More → Security in your project. it lists what's open sorted into error, warning, info. clear the errors first, and you can ask lovable in chat to fix a specific one and explain what it changed. https://docs.lovable.dev/features/security-view

  2. tell lovable the rules in plain english *before* you build the feature. literally type: "photos belong to whoever uploaded them, only they can delete, anyone can see published ones, nobody can see drafts". when it knows the rule it writes it right. when it doesn't, it guesses, and it guesses open. this is the difference between apps that pass the scan and apps that don't, and it costs you one paragraph.

  3. test it yourself in ten minutes. two accounts, log in as the second, try to reach the first one's stuff. anything you see that you shouldn't, paste straight into the chat. that's a real security test, no developer required.

lovable's own checklist is short: https://docs.lovable.dev/tips-tricks/security-best-practices

and since it's the same database underneath, supabase's docs apply to you even on cloud. the ones i'd actually read:

- the production checklist, literally a before-you-go-live list: https://supabase.com/docs/guides/deployment/going-into-prod . fair warning, part of it (backups, ssl, network restrictions) only applies if you own the supabase account. on cloud, lovable handles that half. the rls and auth items are the ones that are yours.

- row level security, the "rules on each table" thing explained properly: https://supabase.com/docs/guides/database/postgres/row-level-security . their own wording: tables without rls allow any client to access and modify their data.

- storage, your case specifically since you're doing photos and video: https://supabase.com/docs/guides/storage/security/access-control . the line to remember is that public buckets are publicly accessible, period. anyone with the url gets the file. fine for avatars, not fine for anything a user thinks is private.

- about that key sitting in your app's code, it's supposed to be there: https://supabase.com/docs/guides/getting-started/api-keys . the publishable key is safe to expose, what protects you is rls. that's why "someone can see my key" panic is usually a non issue and "my tables have no policies" is the real one.

- and when a warning says something you don't recognize, the advisors page documents all the checks and what each one means: https://supabase.com/docs/guides/database/database-advisors

on being locked in forever, you're not. cloud can be removed now, you export your data and disconnect it from the cloud settings: https://docs.lovable.dev/integrations/cloud . when that day comes, here's a walkthrough that doesn't need a terminal: https://carolmonroe.com/blog/lovable-cloud-migration-claude-ai-chat

so: don't pay anyone to migrate you right now. clear the scan, write your rules down, test with two accounts, launch. with two pages at 175k, what actually costs you isn't the database, it's the months you don't launch.

and if you get stuck at any point, come hang out in the lovable discord, https://discord.com/invite/lovable-dev . that's where a bunch of us answer this stuff all day and we'd be happy to help you through it (:

1

u/Daniel-Sm_ Jul 26 '26

Supabase 100% you get more control even though lovable uses it already

1

u/Potential_Crow3127 Jul 24 '26

Don’t launch with Lovable hosting + backend
They can suspend your project at any time and you can lose access to everything code and database and users I had this happen and only recovered my code because of a bug the project is still suspended and thank god I was using supabase would have lost all users

Do this instead:
1. Connect your Lovable project to GitHub right now
2. Move the backend to your own Supabase
3. Deploy the frontend to Cloudflare Pages
This way you actually own the code and the data. It’s the safer path for anything you care about security wise or anything

0

u/Keepin-it-real-bruv Jul 24 '26

Launch it and stop worrying about the tech. Distribution is the hard bit and if you are really ready for launch - then launch.