The “Day 1 vs. Day 100” Trap
Bubble.io can be deceptive. On Day 1, it feels like magic. You drag, drop, and launch a functioning database. You create a “User” type, add a list of “Orders,” and your MVP works flawlessly.
Then comes Day 100. Your user base has grown to 5,000. Suddenly, your dashboard lags. Your monthly Workload Unit (WU) bill spikes by 400%. The magic has turned into a maintenance nightmare.
The problem isn’t Bubble. The problem is how you treated Bubble’s database. While the platform abstracts away the code, it runs on a strict logical infrastructure. Treating it like a spreadsheet is the fastest way to kill your application’s performance.
This guide moves beyond generic tips. It is for the founder or architect building a scalable, production-grade application. We will focus on architectural scalability and WU optimization to separate a prototype from a platform.
The Core Philosophy: “Load Only What You Need”
The single biggest performance killer in Bubble is over-fetching. When you tell Bubble to “Search for Users,” it doesn’t just fetch the name. It fetches every single field attached to that User data type unless you block them.
Imagine your User data type includes a long biography, a profile picture, and a list of sent messages. Bubble downloads all of that data to the user’s browser every time you reference the Current User. This inefficiency leads us to our first architectural rule.
Best Practice 1: The “Satellite” Data Architecture
In traditional SQL, we normalize data to reduce redundancy. In Bubble, we architect data to reduce payload size. You must avoid building “Monolith” data types.
A Monolith is a single data type that holds every piece of information about an entity. If a User type has 40 fields, Bubble secretly downloads heavy text fields in the background, even if you only display a name.
The Solution: Satellite Data Types
Split your data into “Core” and “Satellite” types. This keeps your application lightweight and responsive.
- User (Core): Keep this light. Include Name, Email, Profile Photo thumbnail, Role, and Slug.
- User_Profile (Satellite): Store the Biography, Social Links, and Preferences here.
- User_Onboarding (Satellite): Use this for onboarding status, internal notes, and raw contract text.
- User_Stats (Satellite): Keep counts of orders, total spend, and last login dates here.
Link these by creating a “Profile” field on the User type. When you load a list of Users, Bubble only loads the lightweight Core data. It does not load the linked satellite data until you explicitly request it, such as opening a popup.
Best Practice 2: The “100-Item Rule” (Lists vs. Inverse Linking)
A common debate involves choosing between a List field and a “Do a Search” operation. The old method involves adding a “List of Tasks” field to a Project. Every time you create a Task, you add it to that list.
However, Bubble’s List fields are optimized for small, static lists. Once a list exceeds roughly 100 items, performance degrades. This creates a heavy parent issue. If a Project has 5,000 tasks, loading that Project requires processing 5,000 unique IDs, slowing down your page.
The Architectural Standard: Inverse Linking
Instead of the Parent knowing about its Children, the Children should know about their Parent. This is called inverse linking.
Do not create a “List of Tasks” field on the Project. Instead, create a “Project” field on the Task. To display the tasks, use a Repeating Group that searches for Tasks where the Project equals the Current Page’s Project.
When to Use List Fields
Use List fields only when the list is capped and unlikely to grow indefinitely.
- Good: List of Categories (User selects up to 5 tags).
- Good: List of Collaborators (Usually under 10 people).
- Bad: List of Followers.
- Bad: List of Transactions.
Best Practice 3: Option Sets vs. Data Types
Option Sets are faster than Data Types because they are part of the application’s code. They load instantly without a database query. However, there is a catch regarding code bloat.
Since Option Sets are part of the source code, they are downloaded to the browser on every page load. If you create an Option Set with 5,000 entries, you add megabytes to your app’s bundle size. Users will face a slow initial load time.
The 2026 Rule of Thumb
- Under 200 Items: Use Option Sets. Examples include Statuses, User Roles, and Days of the Week.
- Over 200 Items: Use Data Types. Examples include Cities, Zip Codes, and Schools.
Also, remember that Option Sets are public. Never store sensitive internal codes in them, as tech-savvy users can view them in the browser’s source code.
Best Practice 4: Search vs. Advanced Filters
Understanding the difference between Constraints and Filters is critical for saving Workload Units.
The Client-Side Trap
Avoid using the “Advanced: filtered” operator on large lists. If you search for Users and then filter by “Active” and “Date,” Bubble downloads all users to the browser first. Then, the browser filters them down.
This results in massive WU usage for data retrieval and slow performance.
The Server-Side Solution
Always use strict server-side constraints inside the “Do a search for” box. For example, search for Users where “Status = Active” and “Created Date > Current Date – 7 days.”
The server filters the data before sending it. Bubble only downloads the matches, resulting in minimal WU usage and instant load times.
Best Practice 5: Privacy Rules as Performance Gates
Privacy Rules are not just for security; they are powerful performance tools. They filter data at the database level, deeper than your search constraints.
The “Hidden Field” Technique
If you haven’t split a monolith type, you can use Privacy Rules to stop heavy fields from loading. Create a rule that unchecks heavy fields like “Biography” or “Notes” for general users.
Even if your Repeating Group searches for Users, Bubble will not send the restricted text to the browser. This drastically reduces the payload size. Configuring Privacy Rules properly often doubles app speed instantly.
Best Practice 6: Workload Unit (WU) Optimization
Bubble’s pricing relies on Workload Units. Inefficient database operations drain your budget. You must optimize how you handle bulk operations.
Bulk Operations: SAWOL vs. Recursive
When updating thousands of records, choose the right tool. The official best practice is to “Schedule API Workflow on a List” (SAWOL). It uses parallel processing and is extremely efficient, costing approximately 0.12 WU per item.
Recursive workflows use sequential looping. They cost more WUs and should only be used if tasks must happen in order or if you need to throttle API calls to external services.
Finally, avoid using “Make changes to a list of things” for large sets. It runs in a single timeout window and is prone to failing silently.
Enterprise-Grade Architecture with Thinkpeak.ai
Building a database is easy, but building one that handles 100,000 users requires engineering. At Thinkpeak.ai, we help businesses move from a No-Code MVP to a scale-ready platform.
We approach this via two distinct channels:
1. Bespoke Internal Tools & Custom App Development
If your app is sluggish, it is likely an architecture issue. Our engineering team can refactor monoliths into satellite architectures and replace client-side filters with SQL-like constraints. We also deploy Custom AI Agents to handle complex logic, ensuring your app stays lightweight.
2. The Automation Marketplace
Sometimes, the best practice is to process data outside of Bubble. We provide pre-architected templates for n8n and Make.com to handle massive data transformations. We also offer tools like a Google Sheets Bulk Uploader to clean data before it hits your database.
Your database is the foundation of your business. Don’t let it be your bottleneck.
Conclusion
Bubble.io is a legitimate development stack, but it requires responsible architecture. By respecting the “100-item rule,” utilizing satellite data types, and aggressively optimizing for Workload Units, you can build apps that perform like custom code. The goal is to build it to last.
Frequently Asked Questions (FAQ)
How many records can a Bubble database hold?
There is no hard limit on the number of records. Bubble apps can host millions of rows. The limit lies in how you access them. You cannot load 1 million records to a browser at once, but you can search and display them using pagination without performance loss.
Should I use an external database like Xano or Supabase?
For most apps, Bubble’s native database is sufficient if architected correctly. Consider external databases like Xano or Supabase only if you have extreme compliance requirements (HIPAA/GDPR), need strictly analytical processing, or need to share data with a native mobile app.
Does using Option Sets save Workload Units?
Yes. Reading an Option Set costs 0 WUs because it does not query the database. However, avoid making Option Sets too large, or you will trade WU savings for slow page load speeds.
What is the fastest way to delete a list of things in Bubble?
Do not use “Delete a list of things” on the client side for large lists. The best practice is to use “Schedule API Workflow on a list” (SAWOL). This runs a backend workflow to process the deletion in parallel, keeping the user’s browser responsive.
