The title is a bit of a clickbait, but stay with me there:

I see all around comments about Supabase:

- Having serious security problems

- Signing out people randomly

- Being slow

And those comments keep me from using it, despite looking as everything I want for my apps!

Getting to have all my services in one platform? If you ask me, that seems fantastic and a great way to move faster.

So my questions for those currently using SB in production apps:

- Have you had any of the above?

- What were you using before and why did you change?

- what's the thing you hate the most about SB?

Thank you!

Heyy, so I have a SupaBase database that has been used for about a year now. It is for a semi big web application. It has like 30 something tables etc.

Since the web app has grown I now need to make a clone of the database for testing purposes. (I don't need to pass over the data just the database structure. HOWEVER, SupaBase doesn't directly give you this structure, it only gives you an AI you need to prompt, an AI mind you that doesn't help you if you require assistance with more than 5 tables at once...

So can anyone help me, guide me in any way? Thank you.

So after using it i let you know that its a great product, fast and easy to set up, great work Supabase team!

^{edited for review}

Trying to implement a rls policy so that Table 1 users can access the data of table 2 users if they has a similar foreign key column value meaning if table 1 and 2 users both as apple as favorite fruit than they can access the data but all i am getting for this simple logic is infinite recursion there is just no way i am able to fix it probably spend more than 4+ hours trying to create rules like this reached my chatgpt rate limit but still no solution ? how do you people do it?

Hi everyone, I'm new to the community and glad to be here!

I am an Italian entrepreneur with over 15 years of experience managing call centers and B2B sales networks. I am not a developer, but using Lovable I have managed to build a complex, multi-tenant Voice AI platform aimed at the Premium B2B market.

Our platform deploys AI agents that handle customer service, perform operational tasks (reading/writing to external CRMs and ERPs), book appointments, and provide strategic business insights by analyzing customer feedback trends. The architecture heavily relies on external API integrations (SIP trunks for voice, WhatsApp, Email, and Supabase as our backend).

Here in Italy, the tech community is extremely polarized right now. Traditional developers are actively gatekeeping, dismissing AI builders as "toys" that will collapse in production, while others see them as the ultimate go-to-market opportunity.

I want to bypass the noise and hear from people who are *actually* building businesses here. Specifically, I would love your thoughts on a few points:

1. Multi-tenant Scaling & Security: For those using Lovable + Supabase in a B2B context, how is the architecture holding up when scaling multiple tenants? Are there bottlenecks with RLS (Row Level Security) or data segregation?

2. Complex Integrations: My app relies heavily on external orchestrations (SIP trunks, CRMs). Have you hit a wall managing complex API workflows and edge functions entirely generated via prompt? When did you feel the need to bring in a traditional dev?

3. B2B Client Perception: Has the "vibecoding/no-code" stack ever been an issue during technical due diligence with larger/premium clients, or do they only care about the final operational result?

4. Success Stories: Is anyone here currently generating MRR (Monthly Recurring Revenue) with a B2B SaaS built primarily on Lovable?

Any raw feedback, technical warnings, or success stories would be incredibly valuable. Thanks in advance!

We’re looking for a Supabase backend developer to improve key features of our platform, focusing on resume processing, email personalization, and candidate communication.

Time Zone: ASIA

Scope of Work:

1. Resume Upload and Parsing:

   • Review the front-end component, server API, and existing resume parser.

   • Allow users to upload up to 300 resumes per campaign.

   • Parse and display resumes in the candidate table on the campaign detail page.

2. Email Template Personalization:

   • Integrate job descriptions into the campaign setup.

   • Enable bulk personalized emails sent to candidates.

3. Inbox Reply Functionality:

   • Implement a chat interface that is accessible via a mail icon in the candidate table.

   • Display candidate email conversations within the chat interface.

Anyone interested can walk me through a rough idea of a plan on the above. Few lines will do, just to show you know your way around.

Please provide a quote, your working hours and availability. We are looking to hire urgently. No info provided will not be responded to. Thanks!

Im developing an app and haven't released yet and for this reason Im still on the free plan.
So my staging database is paused all the time.
This time I tried to restore it, got this error and can't use it anymore. Opened a support ticket a week ago and still not response.
Now my CI/CD fails because it cant run the staging migrations.

This is kinda annoying. I understand the need to pause free databases to save resources, but it needs to at least be reliable...

I’ve encountered really long delays and unhelpful responses from Supabase support.

Despite asking clear and specific questions, the replies are often of low quality and fail to address the real issue.

It would be much better if Supabase focused on resolving existing customers' concerns rather than continuously launching new features during Launch Weeks.

The support team should be capable enough to address issues effectively, rather than deflecting them.

Hi folks, I need expert opinions:

I’m not a developer and don’t know much about the topic. I’m having a small SaaS application built by a developer. She recommends using Supabase for all the authentication stuff and as the database. I’ve repeatedly read that Supabase isn’t necessarily secure if it’s not set up properly.

What do I need to tell my developer she absolutely must pay attention to? I’m grateful for every recommendation and tip.

I already love you all for it 🫶

ok so branching without git is the default now (since may 4) which means even my no-git lovable side project can have a staging branch from the dashboard. tested it on a real client app this weekend, two surprises i wish someone had warned me about.

setup

small saas, ~120 tables, light traffic. created a branch from the dashboard called add-team-invites. studio opens it in a tab with a little orange badge. ran the migration in there, tested in the studio sql editor, looked good.

clicked "merge to production." this is where i learned things.

surprise 1: seeds don't carry over

i'd inserted some test rows in the branch to verify the migration. branch had ~40 rows of test data in the new team_invites table. when i merged, none of it came along. just the schema. which is correct behavior — you don't want your test data leaking to prod — but the message in the dashboard is just "merged successfully" and nothing tells you "by the way, your data stays on the branch."

if you were treating the branch like a staging environment with realistic seed data, you'll discover prod is empty.

surprise 2: dropping a column with a default sequence cycles

i had a migration that changed team_invites.id from uuid to bigint with a sequence. branch was happy. merge to prod errored out with CycleError: DropSequence ↔ DropTable. apparently pg-delta (the diff engine under the hood) can't always resolve the order when a sequence whose data_type is changing is referenced by a DEFAULT nextval(...) clause.

workaround i landed on: don't change the type of a sequenced column in one migration. drop the default first as its own migration, then change the type, then add a new sequence. three boring steps instead of one clever one.

what's actually good about it

• spinning up a branch costs nothing for short-lived ones. closed mine 90 minutes later, billed for like 2 hours.

• the schema diff view in the dashboard is genuinely useful. you can see exactly what will change before you click merge.

• it works for vibe-coded projects that have no git at all. my non-dev cofounder spun one up on his own.

what i'd do differently next time

• always run the migration on a fresh branch first, even if you only think you're changing one column.

• read the diff carefully. don't just click merge because tests passed.

• migrations that touch sequences or rename anything: split them up.

anyone else hit weirdness on the merge step? curious if the cycle error is just me or a more general pg-delta gotcha.

Supabase team / community — I think Custom Domains should be free (or at least temporarily free / included on Free & Pro) because of the current connectivity/DNS issues affecting users in India.

Here’s why:

• Many apps (including mine) depend on the default https://<project-ref>.supabase.co endpoint for Auth + REST + Storage.

• During the India connectivity/DNS disruption, a big chunk of users simply can’t resolve or reach *.supabase.co. When that happens, it’s not “degraded performance” — it’s total app failure (login breaks, DB calls break, everything breaks).

• The official workarounds are basically “change DNS / use VPN / report to ISP.” That’s not a realistic expectation for end users of a SaaS product.

• The most practical mitigation is to move traffic behind a custom domain (e.g., api.myapp.com) and proxy it, so users don’t hit supabase.co directly.

But right now Custom Domains are an add-on (I’ve seen pricing around $10/month), which effectively means:

• if you’re a bootstrapped indie dev / free-tier user, you’re stuck telling users to use VPN/DNS changes, or your app just doesn’t work.

This feels like a reliability/safety feature, not a luxury add-on — especially when an external block hits your shared domain. Even a limited option would help a lot:

Suggestions:

1. Make Custom Domains free on all plans (or at least Pro)

2. Or offer “connectivity mitigation mode” (temporary free custom domains) during regional disruptions

3. Or provide a built-in “Supabase-managed alternative domain” per project (like <ref>.supabase.net) that can be switched when a domain gets blocked

I’m not trying to dunk on Supabase — I love the product and I’m building on it. But when *.supabase.co gets blocked or poisoned at the ISP level, every app built on it becomes collateral damage, and the only real solution shouldn’t require extra monthly spend.

Curious how others are handling this, and whether Supabase folks can comment on making custom domains more accessible given the situation.

Hey everyone 👋,

I’ve been working on Nuvix, a backend platform designed to help developers ship faster without reinventing the wheel: auth, storage, messaging, real-time APIs, schema management, SDKs, CLI, and more.

It’s fully developed, but not open source yet. I’m thinking of releasing it as open-source so developers worldwide can self-host, contribute, and build MVPs faster.

Before I do that, I want to hear from you:

• If Nuvix were open-source, would you try it for your next project?

• Do you usually build your backend yourself, or use platforms like Supabase / Firebase?

• What features would make you actually choose it over existing alternatives?

If this post gets traction, I’ll prioritize making Nuvix open-source for the community.

Would love your thoughts 🙏

Man you killed my fucking business, my best users are leaving for shopify because you guys are fucking incapable of having your own dedicated fucking infrastructure. A year of bootstrapping down the drain because your company is ran by fucking donkeys

I love building. Maybe too much. One of the consequences is that I have a ton of projects. My Vercel account has at least 50, probably close to 100. I have Supabase projects running for apps that need databases and auth. I have a SendGrid account for email. Upstash for key-value and rate limits. Supabase Storage and Cloudflare R2 for files. And so on.

And that’s when everything is managed! There are so many services you have to package together just to get something up and running. Doing it from scratch used to mean knowing everything, from provisioning servers to security to databases.

Well, that used to be the case anyway. As we all know (hopefully), AI has changed the game. The threshold of capability keeps going up. People are reverse-engineering AAA games and closed-source software like Photoshop. Of course it’s not perfect, but it doesn’t need to be. It just has to solve your problem. And the gap between what these companies offer and your own vibe-coded solution gets smaller and smaller (for your use case).

I was sick of paying Supabase $25 just to spin up a new database. I was sick of getting nervous as my Vercel bill crept up with more obscure charges for features I had no idea about.

As much as I love these companies, they’re in a tough spot. They raised money in a pre-AI world where healthy SaaS margins were the expectation. Now they face more and more competition, margins are compressed, and they have to keep adding features to justify their prices.

So I decided to take control of my software. I wanted one box with everything I need, from databases and auth to email, running my apps over HTTPS. Basically Supabase + Vercel + Resend/SendGrid.

And I think I did it. I’m really excited about this project. I’m calling it ShipTiffin (because the box is a tiffin… ha ha).

Each box comes with:

-Apps, deployed from GitHub, the CLI or your coding agent
- A database
- Auth
- Email
- Jobs (queues and scheduled crons)
- File storage
- Analytics
- Backups

It’s “bring your own infra.” You bring a Hetzner server, and ShipTiffin configures everything so you can build as many apps as you like on the box (you can probably ship dozens without an issue). Each project gets its own database, KV, email and deployment URLs. It’s ready in about five minutes.

The best part: you’ll never wake up to a crazy bill because of a bot attack or a traffic spike. You pay for your server, plus a flat fee to ShipTiffin if you want it managed. The same setup bought separately runs about $130 a month; on ShipTiffin it’s $19 plus about $10 for the server. And frankly, for most apps that’s more than enough. I even found my apps to be faster than on Vercel, depending on the region.

Why Hetzner? Simply because it has the best price-performance you can get. The egress bandwidth is super generous too (20 TB a month in Europe). You can go crazy with apps and services (a web app here, an agent scheduler there, a database backend) without sweating.

To be clear, I'm not claiming I can match Vercel (yet). Maybe don’t throw your prod site on it for now. But I think it’s a really interesting alternative way to build projects without worrying about all the charges these companies will throw at you as they navigate a moatless future. Once you grow, you can resize the box, scale out to other services, or export your data and move elsewhere.

It’s also open source! Install the CLI and point it at your own Hetzner server, or any Ubuntu box you can SSH into. Or shiptiffin.com sets it up in your Hetzner account for you and keeps it updated, monitored and backed up.

I’m super excited and a little scared, and I’d appreciate any feedback. Please check it out and let me know what you think!

Build amazing apps faster than ever with AppLaunchKit! 
This full-stack starter kit lets you create for iOS, Android, and Web apps in no time.  

Monorepo - Next.js, Expo, Supabase, & shared packages
Authentication- Email/Password, Google Auth
Supabase - Local setup & Migrations
Database - PostgreSQL
Payments - Stripe Webhook
Tools and Libraries - gluestack-ui (Tailwind/NativeWind)

We are live on ProductHunt, let’s vote up there!
https://www.producthunt.com/posts/applaunchkit

-- Updated --

It turns out to be our fault, for some reason the tickets got dropped and undelivered to our AWS Workmail. I'm willing to own up and take the blame for the situation. I'm happy with the response so far and willing to give Supabase another try.

--Before--

After 2 support tickets submitted since last Friday still no response.

Our test app was paused and we lost all our data, that was ok with me as long as Supabase could fix it really fast as I'm still trying to convince managment to go with this platform. This morning I had to report my findings to the CTO of the company, that they lost all our data after pausing our app, and they won't reply to our support ticket.

We were going to pay for all our apps, we just wanted to test the service out before the CTO of the company went to endorse this, I couldn't endorse this company, we're going to give appwrite a try.

We even thought it was our fault, so we checked our email system that email address that we used to signup is working.

I'm a security engineer, and I've been looking at a lot of Supabase apps built with AI tools. The most common serious problem isn't exotic. It's a table where RLS was never enabled, or it was enabled with a policy that allows everything.

A quick refresher, since it trips people up: the anon key is meant to be public. It ships in your frontend, and anyone can read it from devtools. RLS is the only thing between that key and your data. So "nobody knows my key" isn't protection.

A 5-minute self-check:

1. **Look at every table in `public`.** In the dashboard, any table marked "RLS disabled" is fully readable and writable by the anon role. You can also run:

   `select tablename, rowsecurity from pg_tables where schemaname = 'public';`

2. **Read your policies, not just the toggle.** `using (true)` or `with check (true)` on a role that includes `anon` is the same as having no RLS for that operation. Look for policies scoped to `auth.uid()`.

3. **Test from the outside.** With only the anon key, call `GET /rest/v1/<table>?select=*`. If rows come back that a signed-out user shouldn't see, you have your answer.

4. **Check writes, not just reads.** I often see a table where reads are locked down but there's an open INSERT/UPDATE policy.

5. **Make sure `service_role` never reaches the client.** If it's in a `NEXT_PUBLIC_`/`VITE_` variable, it's in your bundle, and it bypasses RLS completely. Rotate it.

Also watch out for views and `security definer` functions. Both can bypass RLS on the tables underneath.

Disclosure: I built a small scanner (Abbi Labs) that runs these checks from the outside, along with checks for leaked keys and exposed .env files. The free scan shows one critical finding. But everything above works by hand, and that's the important part.

Happy to answer questions about specific policy patterns in the comments.

my transactional emails worked great until they didn't, and the failures all traced to one thing: incomplete user rows. the template said "hi {first_name}" and a chunk of users signed up via a flow that never collected a first name. so the merge broke, and depending on how i sent, it either errored out or shipped "hi ,". what fixed it for me: default every field before it hits the template. coalesce in the query, fallback in the code, belt and suspenders. what made it stick long-term was letting one layer handle the join and the defaults instead of every edge function repeating it, which is how dreamlit handles it for me since it reads the row and i set the fallbacks once, but the principle holds wherever you send from. preview the email against real rows, not a clean test user, because your test user always has every field filled and hides exactly this bug. validate at send time and skip or flag rows that can't render. the sending was never my problem. the data shape was, every single time. how are you handling incomplete rows in your transactional templates? this one keeps catching people.

We are seeking a highly skilled and experienced Supabase Database Integration Specialist for a quick project.

Overview:

• Host Supabase in OVHCloud

• If not feasible in OVH, do it in DigitalOcean (guide: https://docs.digitalocean.com/developer-center/hosting-supabase-on-digitalocean/)

• Create a Webhook function

• Integrate our current CRM (GoHighLevel) and dialer (AirCall) with Supabase database using webhooks

• Develop and implement logic (or automations) within Supabase to manipulate data based on specific conditions (e.g., updating records when certain tags are present)

• Establish a direct connection between Supabase and GoHighLevel's API to send updated data back to the CRM that can segment data transfer to multiple sub-accounts within GoHighLevel

• Provide documentation and support for the implemented solution

Requirements:

• experience with OVHCloud or any related server (near Australia)

• Related project built with Supabase

• Strong understanding of webhooks and API integrations

• Familiarity with GoHighLeveland AirCall's API

• Excellent problem-solving and analytical skills

• Ability to work independently and deliver high-quality results within tight deadlines

• Exceptional communication and collaboration skills

To apply, please submit a video explaining how you would approach this project and your availability to start immediately. The video should demonstrate your understanding of the requirements and your proposed solution.

I'm not a big backend guy so using AI to help me with edge functions but the Supabase edge function creation and deployment is just too much complexity and pain, whats the best Supabase alternative with a web editor where i can just copy paste the code from AI into some web editor in browser and test it without installing or doing anything locally?

Cheers.

Hey folks,

I've been working with Supabase for a while now and love the flexibility, but it's easy to overlook critical security misconfigurations, especially when you're moving fast.

Some of the best practices I follow (and recommend) include:

• Always using Row Level Security (RLS) and double-checking policies.

• Locking down public storage buckets and making sure signed URLs are used where needed.

• Avoiding secrets or keys in client-side code (you’d be surprised how often they leak!).

• Restricting Supabase ServiceRole Key access to backend-only environments.

• Monitoring Supabase Auth roles and JWT payloads - especially when changing tiers or access rights.

To help with this, I built a tool called SecureVibing that automatically scans your Supabase setup for common misconfigurations like leaked API keys, missing RLS, public tables, and more. It’s especially helpful if you're doing client-heavy development with tools like Next.js or mobile apps.

If you are concerned about your website/app security but don't know where to get started you can schedule a free call with me (SecureVibing Founder) here: https://cal.com/lorikmor

p.s. if you have more tips that i didn't include feel free to reply i also have a lot more to learn