Hello,

I am building a chat bot for clinicians and have had some interest from institutions, initally was planning on no PHI therefore no complaince needed but these customers are requesting it. Wondering if supabase versus postgres hosted on gcp/ vercel is the way to go?

Posted here a while back asking what RLS checklist people run before shipping. Kept digging since, and the pattern that shows up more than "RLS is just off" is worse: RLS is on, with a policy like using (true) with check (true).

That passes literally every naive check — Supabase's own advisor, a quick eyeball review, and (this is the part that surprised me) even a prompted AI review asking "did you set up RLS properly?" All of those confirm RLS is enabled. None of them confirm the policy does anything.

The other repeat offender: RLS enabled correctly in an early migration, then silently disabled by a later cleanup migration months down the line, with nobody re-checking because nothing prompts a re-check.

Genuinely curious from people running production Supabase apps — do you have anything that re-verifies policies after the fact, or is it a one-time check at build time and then trust?

I've been running a product on Supabase for a while now — Postgres, plus a decent amount of Storage — and I had a bit of a scare recently that made me finally look properly into backups.

I realized there were a few things I kind of knew in theory, but hadn’t really internalized:

• Pro daily backups only keep 7 days.
• Those backups don’t include the actual Storage files. The database backup includes storage.objects, so you get the metadata rows, but not the files sitting in the buckets. Which means a restore could technically give you a bunch of file references pointing to nothing.
• PITR is an extra $100/month per project.
• If the project itself gets deleted, the managed backups are gone too.

To be clear, none of this is hidden. It’s in the docs. I just hadn’t really thought through what it would mean in a real “oh no, we need to restore everything” situation.

And that made me realize my backup strategy was basically: “Supabase probably has this covered.”

Which… maybe not a strategy.

So I’m curious what people are actually doing in production:

1. Are you just relying on Supabase Pro backups? Paying for PITR? Running your own pg_dump cron? Using SimpleBackups or something similar? Or, honestly, doing nothing?
2. If you handle backups yourself, how are you backing up Storage files alongside the database?
3. More importantly: have you ever actually restored a Supabase project into a fresh project and verified that everything came back clean?
4. For people managing multiple client projects — agencies, freelancers, consultants — how do you keep backup policies straight across all of them? And are clients expecting you to be responsible if data gets lost?

I’m not trying to sell anything here. I’m just trying to build a backup setup I’d actually trust.

Would really appreciate hearing what’s worked, what didn’t, and especially any horror stories from people who’ve had to restore for real.

Fresh out of the oven, so heads up if you don't see it in your account yet. Thank you Lovable team for shipping this one.

Some context on why I'm excited: over the last months I've been creating guides, skills and workflows to help builders migrate from Lovable Cloud to their own Supabase, because until today there was no official way out. Your data was basically locked in, and every migration was a hand-crafted workaround. Now there's an official path, and it's simple.

Step 1: Export your database

Go to Stack > Lovable Cloud > Advanced settings > Export data, then select "Export" in the Database card (screenshots below). You'll get a temporary download link by email. Limits: 5 GB max, one export every 24 hours.

What's actually in the file

It's a full Postgres backup (.backup file, pg_dump custom format, ready for pg_restore). And it's surprisingly complete:

• Full schema: tables, indexes, sequences, extensions
• All your data
• All RLS policies
• Database functions and triggers
• Your users: the full auth schema, including password hashes, so your users won't need to reset passwords

One warning: because it includes password hashes and user PII, treat this file as sensitive.

Step 2: Remove Lovable Cloud

Before connecting your own Supabase, disconnect the old backend: Stack > Lovable Cloud > Advanced settings > Remove Lovable Cloud.

Just make sure you have everything downloaded FIRST: your database export and your storage files (user uploads and images live in the Storage section and are not part of the database export). Once Cloud is removed, that's your only copy.

Cloud used to be permanent once enabled, so having this button at all is a big shift. And if you're not ready to fully leave, you can now pause your Cloud instance instead (screenshots below).

https://preview.redd.it/trdhbhmwi1bh1.png?width=1198&format=png&auto=webp&s=cd9f2491379b22597b517297075e908eed7d9d9d

Step 3: Connect your own Supabase project

Create your Supabase project, then connect it through Connectors: pick the Supabase connector, authorize it, go back to your Lovable project and add it. This is the native integration, so your app talks to your own Supabase from here on.

If you want to double-check everything is wired correctly, leave Lovable a prompt like:

>"Review my Supabase connection: confirm the app is pointing to my new Supabase project, check that auth, database queries, storage and edge functions all work against it, and list anything still referencing the old backend. Don't change anything yet, just report what you find."

Step 4: Move the rest over

Restore the backup into your new Supabase with pg_restore, then cover the three things that don't come in the file (by design, they don't live in the database):

• Edge functions: they're in your repo under supabase/functions
• Storage files: re-upload the ones you downloaded in step 2
• Secrets and API keys: re-set them in your new project

You can finish all of this with the MCP (I'll write about that soon), but honestly, today this whole flow is easier and more intuitive than it's ever been.

Why this actually matters

This changes how I think about Lovable Cloud, and probably how you should too.

Lovable Cloud is genuinely good, and not just for small projects. Auth, database, storage, edge functions, all working out of the box with zero keys to manage. The thing that made people hesitate was never the product, it was the lock-in: once you enabled Cloud, there was no official way out. That meant choosing it felt like a permanent decision, so a lot of us defaulted to our own Supabase "just in case."

That trade-off is gone. If your project outgrows Cloud, or you need full dashboard access, or your team wants total control, you export, remove, connect, restore, done.

Honestly, I might use Lovable Cloud MORE now, not less. Knowing I can migrate later in an easy, efficient way removes the main reason I was cautious about it. Start fast on Cloud, move when (and if) you actually need to.

What's next

I tested this flow end to end, and I'm working on a skill and plugins to make the whole move even smoother, everything the export doesn't cover, automated. That plus the updated migration guide will be on my site soon, I'll share them here when they're live.

Docs: https://docs.lovable.dev/integrations/cloud#export-lovable-cloud-data

I need to implement user logins across web, ios and android play store apps, is Supabase the best for compliance, security and cost?

Hello everyone!

I'm developing a small app with Supabase and I'm currently using the free plan.

I recently found out that Supabase's built-in email service is limited to 2 emails per hour. I only need email for OTP logins and password resets.

Does anyone know if there any free SMTP providers that work well with Supabase?

Probably going to get downvoted for this, but what is going on?! Yes, I can see 99.97% uptime across most services but most of these outages/incidents last most of the day.

Want to get some perspective on using a Python (FastAPI, Flask, etc) backend with Supabase.

I'm comparing two options:

Option 1: Python backend only:

Frontend -> FastAPI -> Supabase

Pros:

• Python ecosystem
• No Supabase runtime constraints (400s, 256mb memory, etc.)
• Single backend deployment

Cons:

• Verify Supabase JWT in Python
• Frontend talks to separate API instead of Supabase Edge Functions

Option 2: Edge Function as a gateway to Python:

Frontend -> Supabase Edge Function -> Python -> Supabase

Pros:

• Supabase Edge Functions are the public API layer
• Built-in JWT verification
• Python ecosystem

Cons:

• Multiple deployments
• Additional network hop
• Edge Function still has runtime limits for the gateway request
• Distributed debugging / observability. Errors, logs, and tracing now span two runtimes.

I'm leaning towards not calling Python from an Edge Function. It seems cleaner to use Edge Functions until they become insufficient, then add separate Python services to handle relevant workflows.

Curious about others experience using a Python backend with Supabase. Has anyone adopted Edge Functions as the gateway layer, and if so, what benefits did it provide?

I have a Supabase app where some internal data still lives in spreadsheets because it’s easier for non-devs to update them there.

Now I’m thinking about bringing part of that data into Supabase, so the app can use it instead of having someone copy it manually.

Has anyone done this in a clean way? Did you keep the imported data in separate tables, or merge it into your normal app schema?

I’ve been reviewing a bunch of public Next.js/Supabase repos recently, and the most common production-risk pattern was not broken code.

It was code that worked locally, but had weak data boundaries.

The patterns I kept seeing:

- tables created in migrations without RLS enabled

- RLS enabled but no meaningful policy added

- UPDATE/SELECT policies that were too broad

- auth checks happening in UI/client logic but not near the actual mutation

- routes trusting client-provided userId/orgId/accountId

- service role usage drifting into application code where it did not belong

The scary part is that most of these apps would pass a normal “does it work?” test.

The UI loads.

The query returns data.

The mutation succeeds.

The deploy passes.

But the app is still not necessarily safe to ship.

For people building production Supabase apps, what is your actual pre-launch checklist?

Do you manually review every table/policy/mutation path, or do you rely mostly on Supabase advisors and testing the happy path?

Hey everyone, I'm currently diving into Supabase and backend development.
Learning how tables, relationships, and real-time updates work together to power apps.

I’m still early in the journey, but it’s starting to click. Any tips from people who’ve built with it before would help a lot.

Set up automated pg_dump backups to S3 months ago and just... never checked again. Cron runs, script does its thing, assume it's fine.

Then I realized I'd have zero idea if it silently broke. Bucket permission change, script error, cron just dying I wouldn't find out until the day I actually needed a backup and it wasn't there.

Anyone actually monitor this or just trust it? Has this bitten anyone before?

Which database service should I use to store data for my project? Both are good, but I am looking for a service that is cost-effective and suitable for projects ranging from small to large scale.

I know supabase is having issues / outages at the moment.

But my project runs on the eu-west1 region.

Why am I being affected by this issue when we arent part of the problem areas?

I've spent the last few months building a transactional email API for people who'd rather their email (and their users' data) stay in the EU. Think Resend/Postmark, but EU-native: our own sending infra on EU servers. No SES.

What I actually want now is a handful of real senders to use it and tell me where it breaks. I run my own sending IPs, so I'm being deliberately picky about who I onboard.

Deliverability is shared, so I'm watching it closely. To be clear, that means it's for email people actually asked for - receipts, notifications, product updates, opt-in lists - NOT cold outreach or bought lists. So it's invite-only and free during the beta.

If you send emails using the Supabase custom SMTP feature and care about the EU angle, comment or DM me with what you'd be sending and roughly what volume and I'll get you an invite.

Thanks!

i was setting up a side project and realized my whole "backup strategy" is basically a pg_dump cron i made once and never actually tested. no idea if it'd even restore. and the free tier keeps zero backups which kinda freaked me out. so how do you all handle this?

whats your actual backup setup right now have you ever tried a full restore? did it work anyone ever lost data or had a real scare? trying to figure out if im the only one being sloppy about this lol. happy to share back whatever i learn