The network for creativity
Join 1.25M professional creatives like you
Connect with clients, get discovered, and run your business 100% commission-free
Creatives on Contra have earned over $150M and we are just getting started
Back to feedPost
Taste Test
Hey everyone 👋
I’m currently building a crypto Saas and I’m at a decision point regarding the backend setup.
Right now, my stack includes Lovable + Vercel, and I’ve been exploring two options for handling the database:
Using Lovable Cloud as the database (fully integrated, simpler workflow)
Using Supabase (more control, dedicated backend, scalable)
I’d love to get your feedback based on real experience 🙏
👉 For those who’ve used both:
Which one do you recommend for a SaaS project?
Any limitations or issues with Lovable Cloud?
Is Supabase worth the extra setup/complexity in the long run?
9 voted
64%
5 voted
36%
14 votes
Closed
If you're building a serious SaaS, I would lean towards Supabase. More control and scalability matter a lot once users start growing. Lovable Cloud is good for speed, but can feel limiting later.
The network for creativity
Join 1.25M professional creatives like you
Connect with clients, get discovered, and run your business 100% commission-free
Creatives on Contra have earned over $150M and we are just getting started
Related posts
A private aviation website should do more than look expensive. It needs to turn visitors into qualified leads.
For Fly Velair, I designed and developed a complete digital experience built around their private jet charter and aircraft sales business.
The project included a full Framer website, a custom 3-step booking flow integrated with their CRM, CMS-driven aircraft listings, a dedicated Jets for Sale platform, SEO optimization, 10 search-focused articles, and premium print collateral.
Every part of the experience was designed to feel as premium as the service while making it easier for customers to inquire, book, and explore available aircraft.
Full case study below. Would love to hear what you think.
The 10 search-focused articles are the part most people skip, and for charter that long-tail traffic is probably where a lot of the real leads come from. Curious how you split the build, Framer for the main site and Lovable + Supabase for the jets for sale platform?
Love the live bento idea.
Is it safe to expose the Supabase anon key? Yes, it's built to be public. The key you must never ship is the other one.
Supabase's docs say the publishable key (the newer anon key) is "safe to expose online" and add: "Anyone can read it, so it only reaches what Row Level Security allows." So an anon key in your Lovable or Bolt front end is normal. RLS protects your data, not hiding that key.
The one that must stay on the server is the service_role key, now called a secret key. It bypasses RLS: whoever has it can read and change every row. Supabase: "Never put one in a browser, a shipped application, or source control."
How to tell which key you shipped
• An old-style key is a JWT. Decode its middle part: "role":"anon" is the public one, "role":"service_role" is the secret one.
• New keys say it in the name: sb_publishable_ is public, sb_secret_ is not.
• Check every VITE_, NEXT_PUBLIC_ or REACT_APP_ variable. Vite's docs: VITE_ variables "will be exposed in client-side source code after Vite bundling."
• Need admin access? Use an Edge Function: SUPABASE_SERVICE_ROLE_KEY is already there by default.
Found a secret key in your front end? Supabase says to rotate it as soon as you fix the cause of the leak. Deleting it from the code isn't enough: your git history still has it.
The audit tool I built for Lovable, Bolt, Base44 and Replit apps flags both as critical: a service_role or sb_secret_ key in the code, and a secret in a browser-exposed variable. It leaves the anon and publishable keys alone on purpose: flagging them would be a false alarm.
Is the anon key the only Supabase key in your front end, or have you never checked?
