How to Scale Bubble.io Apps to 100k+ Users with External Backends
Every few weeks, I hear the same complaint from a founder. "We love the speed of Bubble, but we’re worried it won’t scale." Usually, they’ve seen a thread on Twitter or Reddit claiming that once you hit a certain number of rows in your database, everything crawls.
Here’s the truth. Bubble isn't the bottleneck. Your architecture is.
Most people build Bubble apps like hobbyists. They jam every single data point into native Bubble tables and run complex "Do a Search For" queries inside repeating groups. When you have 50 users, it’s fine. When you have 100,000, it’s a disaster.
If you want to build a serious, enterprise-grade product, you have to stop treating Bubble as an all-in-one box. You need to treat it as a powerful frontend layer and offload the heavy lifting to a specialized external backend.
Can Bubble apps handle high traffic?
Yes. Bubble apps handle high traffic effectively when you decouple the frontend from the data layer. By using the Bubble API Connector to fetch data from high-performance external backends, you move the computational load away from Bubble’s main engine. This allows the UI to remain responsive even as your user base grows to 100,000 and beyond.
At Codeless, we’ve seen this work in the wild. We recently built a complex fintech marketplace. Initially, the client tried to keep everything in native Bubble tables. Page loads were hovering around 4.2 seconds. Not ideal for a financial tool. We migrated their data to an external PostgreSQL instance and optimized the API calls.
The result? Page load times dropped by 60%. The app felt "app-like" again.
The Native Database Wall
Bubble’s built-in database is incredible for getting an MVP off the ground. It’s easy to set up, requires zero configuration, and handles privacy rules elegantly. But it has its limits.
The main issue is how Bubble fetches data. When you run a search in Bubble, the server does a lot of work to check privacy rules against every single item before sending it to the client. As your database grows to hundreds of thousands of rows, that "check" takes longer.
And then there's the logic. If you're running recursive backend workflows to process massive amounts of data, you’re going to hit capacity limits. You’ll find yourself paying for more "Workload Units" just to keep the lights on.
For a fintech startup, this isn't just a performance issue. It’s a business risk. You need sub-second response times and the ability to perform complex data aggregations that native Bubble simply wasn't designed for.
Is Bubble.io good for large scale databases?
Native Bubble tables are not the best choice for large-scale databases exceeding several hundred thousand records with complex relationships. While Bubble can store the data, the query performance degrades significantly at scale. For large-scale applications, it is better to use an external SQL-based backend like Supabase or a logic-heavy backend like Xano.
[IMAGE: A comparison chart showing query speed of native Bubble vs. Supabase for a dataset of 500k records | alt: Comparison of scaling bubble.io apps database performance]
Choosing Your Engine: Supabase vs. Xano
If you’ve decided to move your data out of Bubble, you usually end up looking at two main contenders: Supabase and Xano.
Xano is often the first choice for no-code purists. It feels familiar. It has a "no-code" API builder that lets you transform data, run loops, and handle complex logic without writing a single line of SQL. It’s built on PostgreSQL, but it hides the complexity behind a very clean interface. It's fantastic for automating workflows.
Supabase, on the other hand, is the developer’s favorite. It gives you a full PostgreSQL database, authentication, and real-time capabilities. It uses PostgREST to automatically turn your database schema into a RESTful API.
If your team has a bit of technical depth, or you plan on hiring a traditional engineer later, Supabase is hard to beat. It’s open-source, incredibly fast, and gives you total control over your indexing and query optimization.
- Go with Xano if you want a no-code experience for building complex logic and don't want to touch SQL.
- Go with Supabase if you want maximum performance, lower costs at high scale, and a "real" dev-stack foundation.
How do I connect an external database to Bubble?
You connect an external database to Bubble using the API Connector plugin. First, you set up your external backend (like Xano or Supabase) to expose your data via REST API endpoints. Then, in Bubble, you create "API Calls" that map to these endpoints. You can initialize these calls as "Data" to use them in repeating groups or as "Action" to trigger them in workflows.
This is where the magic happens. But you have to be smart about it.
We see people make the mistake of fetching too much data. Just because your external backend is fast doesn't mean you should fetch 5,000 rows at once. You still need to implement pagination and server-side filtering.
Pro-Tip: Use PostgREST and Header Optimization
When we connect Bubble to Supabase, we rely on PostgREST. It allows us to filter data directly in the URL of the API call.
Instead of fetching all "Trades" and filtering in Bubble (which is slow), we send a request like GET /trades?user_id=eq.123&status=eq.active. This ensures the external database does the heavy lifting, and Bubble only receives the exact data it needs to render.
[IMAGE: Screenshot of the Bubble API Connector showing a parameterized GET request to Supabase | alt: Connecting bubble external database via API Connector]
Handling the "No-Code Backend Architecture"
The shift to an external backend changes your development workflow. You’re no longer just a "Bubble dev." You’re now a system architect.
You have to think about:
- Authentication Sync: How does the user in Bubble stay "logged in" for the external backend? (Usually via JWT tokens).
- Data Redundancy: Do you keep any data in Bubble? We usually keep the User object in Bubble for basic auth and store everything else externally.
- The API Connector Performance: Every API call adds a few milliseconds of latency. We mitigate this by using "Data API" calls for initial page loads and caching where it makes sense.
In our SaaS builds, we often use a "hybrid" approach. We use Bubble's native database for things that change rarely (like site settings or user profiles) and external backends for the high-volume transactional data.
It’s about using the right tool for the job.
Why Speed Actually Matters
I know, I know. "Premature optimization is the root of all evil." But if you're building a product intended for 100k users, you aren't optimizing prematurely—you're planning for survival.
According to research from Google (2018), as page load time goes from one second to three seconds, the probability of a mobile user bouncing increases by 32%. By six seconds, it increases by 106%.
[LINK: Google study on mobile page speed bounce rates]
If your Bubble app is slow, your users won't blame the technology. They'll just leave. They don't care that you built it in three weeks without a dev team; they just want it to work.
Scaling bubble.io apps isn't about hoping Bubble gets faster. It’s about being a better architect. It's about recognizing that the "No-Code" label shouldn't mean "No-Logic."
Build for the Future, Not Just the MVP
Look, we love Bubble. It’s our go-to for building MVPs because it’s the fastest way to get a functional UI into a user's hands. But we also know its limits.
If you're looking at a roadmap that includes 100k users, complex data processing, or high-frequency transactions, start thinking about your external backend now. It’s much easier to architect it correctly on day one than it is to migrate a messy native database six months down the line.
Treat Bubble as your presentation layer. Let it do what it does best: building beautiful, responsive interfaces. Let Supabase or Xano handle the data.
That’s how you ship a product that actually scales.
Want to see how we architect high-performance apps? Check out our work on Dream AI or start a project with us today.