Hi everyone!
I’m considering using Supabase as the backend for a client project that involves handling a large dataset and requires vector search capabilities. Initially, I thought of using Bubble + Pinecone, but for this specific case, it seems too WU-intensive.
I’ve experimented with two plugins, Nocodegarden and Supabase.js, and found them really impressive! I managed to set up authentication, real-time features with WebSocket, database queries, and file uploads without too much trouble.
However, I’ve hit a roadblock: how to manage development and production environments between Bubble and Supabase. After some research on YouTube, I noticed that Supabase’s branching system seems to require CLI/Git skills, which feels a bit overwhelming for my current skill set.
Here are the two options I’m considering:
-
Using two database schemas: Use the default public schema for production and create a staging schema for development, passing it as a variable in Bubble (Supabase.js supports schema customization).
-
Creating two separate projects: One for production and one for staging. However, this seems inefficient and difficult to manage in the long run.
Has anyone found a good workaround for this? I’d love to hear your thoughts or experiences!
Thanks in advance! 
Create 2 separate projects will be more secure and will really separate your data.
That’s what’s recommended.
On the other hand, you have to make sure that both DB schéma are the same. So, I would only create the live project db when you’ll be (pretty) sure about the db to avoid changing live too often
Hi there. How did you approach this?
Hi @shu.teopengco
Finally I did create a dev branch locally (super easy to setup + with the access to studio so same dashbaord as online) and distributed it from my machine to bubble using ngrok. Then added this dev version credentials in the plugin (I ended up building my own but supabase.js is also really great).
So you need to use a bit local development and code but it’s way better to manage than having 2 different schemas or 2 separated projects.
The only annoying thing is that you need to launch ngrok every time you need to test.
1 Like
So you used the Supabase CLI? Pushed from local to dev then dev (db diff) to prod?
How is it in maintainability and performance aspect? Is it worth it the extra dev time instead of using bubble db?
Yes that exactly the flow I’m using. @shu.teopengco
it’s obviously more painful than just building with bubble but for me it’s manageable. Here is more context:
In the past, I always said it didn’t make much sense to use Bubble with an external database—after all, one of Bubble’s biggest strengths is being a full-stack platform. And to be honest, for 90% of my clients, Bubble alone is more than enough.
But things changed with the release of the Native Mobile Editor, and I had to build a project that was extremely data-intensive (millions of rows), with complex analytics views that involved joins—something Bubble doesn’t handle well. I needed a stronger backend while having both web and mobile version, so I went with Supabase.
That said, I expected it to be painful to connect Supabase with Bubble. But it turned out to be smoother than I thought. The JavaScript client is very smart, and it’s fairly easy to build or reuse a plugin for it. The results:
- Zero WU usage
- Faster response times than Bubble’s native DB (typically 100–250ms per query)
- The ability to build both web and native mobile versions on top of the same backend.
Of course, this is a pretty specific use case.
If you’re building a web-only app that’s not particularly data-heavy, Bubble’s built-in database will work just fine.
But if your project needs more backend control, or deals with large-scale data and performance-critical views and don’t need mobile version, then Bubble might not be the best choice for your frontend (may be Weweb?).
Curious to hear—what’s your use case?
