I’ve completed a SaaS product built with Bubble, and good news: a school has approved it for a pilot. The initial pilot will involve around 100 students. If the pilot goes well, the plan is to expand the implementation, with a potential wider rollout across the country next year that could eventually reach 10,000+ students.
The system will collect daily student activity, so the database and reporting workload will grow continuously.
For those who have built/managed Bubble apps at this scale:
What should I worry about first — Workload, database size, backend workflows, or something else?
What are realistic monthly costs at 100 → 1,000 → 5,000 → 10,000 students?
Would you stay fully on Bubble at 10k students?
What mistakes should I avoid during the 100-student pilot?
I’m looking for real numbers, real setbacks, and lessons from people who have actually scaled Bubble apps.
I’m keeping the product name/concept private for now, but the scaling target is real.
No way of knowing except through tests and observation of what your app does and how users use it. You can start simply by acting as a user then look at logs and extrapolate from there. But every app does different things, some can cost nothing some can cost a lot.
When I was building my app and was the only user during development stage I looked at the WU usage and nearly cried when I realised that if I multipled my own usage by 1000 users id be paying a fortune and the whole thing was unfeasible.
Then something strange happened - we actually started getting users and WU didn’t increase the way I anticipated at all… I was also soon able to spot inefficient areas and improve them.
Now we have nearly 13000 users and am STILL on the lowest bubble tier. Although I constantly hit overages now so will be upgrading soon (Although there’s still numerous optimisations I could make yet).
But as @boston85719 says - it’s really impossible to say as every case is completely different. All I can say is that for me personally, it’s been a delightful experience.
I wouldn’t say there’s one specific area you should worry about more than the others. There’s usually room for improvement everywhere.
Poorly designed workflows can take a lot of time to run and can also make your app’s costs scale very quickly. Database size itself isn’t necessarily a problem either, but I’d be careful about creating data types that are too “heavy.”
For example, in the User data type, I wouldn’t store every single piece of information related to that user. Otherwise, you can end up with a huge record that Bubble has to load over and over again.
A better approach is to split things into supplementary data types, such as User-Address, User-Classes, User-Preferences, User-Billing, User-Enrollments, User-Activity, etc.
This way, instead of having one massive data type, you have several smaller ones that are only used in the specific parts of the app where they’re actually needed. That helps a lot as the app scales and also keeps the database much more organized.
But overall, it really depends on where your project ends up going. These are the kinds of things you keep adjusting and improving over time as real usage starts showing you where the bottlenecks are.
As for costs, it’s basically impossible to predict in advance. It will depend a lot on how many students actually use the app every day, and how frequently they interact with it.
Your 100-student pilot will definitely be your first real benchmark. It should give you a much better idea of your actual workload consumption and how costs might scale from there.
I’d definitely feel comfortable staying fully on Bubble at that scale.
For the first pilot, I’d mainly focus on getting the basics right.
A solid signup/login flow, password recovery, well-structured privacy rules, a clean UI, intuitive screens, and so on. Basically, make sure the fundamentals are really well done before worrying too much about more advanced optimizations.
One tip: I’d already start thinking about external file storage instead of relying entirely on Bubble for that. I use Wasabi and it’s excellent. It has a lot of security features and the cost is very reasonable.
I imagine your app may eventually handle a significant volume of uploads, so it’s worth thinking about that architecture early rather than dealing with it only after the volume starts growing.
Lol same. Once users come in, there’s this realization that they aren’t gonna do what we normally do.
Haven’t encountered this kind of problem but I read somewhere that this is also one way to optimize WU so I’m doing this whenever possible. I’m seeing this could be annoying once we decide to go this route in the future so doing this early on is better.
Be careful with that. It’s often mistaken that WU consumption for data fetch is high because of how much data is returned based on extra fields.
WU costs for fetching data are high for the fetch itself, the do a search for a thing part alone is 0.3 WUs per time you do it. The other portion is number of things returned, which is 0.015 per thing (I think, haven’t looked for a bit) so if 10 records returned it’s per thing 0.015 X 10 records returned…THEN it’s the cost per character of data which is tiny like 0.000003 per character or something.
So the proposed approach saves you on each character of data returned by putting for example address as a separate data type instead of directly on the user, BUT it costs you the address fetch of 0.3 plus the record returned of 0.015 (you could save address unique ID to make it an individual data request but still costs more WU then just having address fields on User data type).
So everytime you want to use or show the other records like address you get charged more WU for fetching data and data return. The result is HIGHER WU costs.
ADDITIONALLY, there are the highest WU consumers, of create data and modify data…want to put a user address onto a separate data type, costs 1.12 for creating it and 1.12 to update it. Of course you won’t create and update as often as fetch but they do contribute to the overall higher WU costs involved in the approach of separate data types.
My assumption on why you’ve read it somewhere else and here again is developers are not testing and checking real numbers when they implement this strategy, since if tested, it does cost more WUs in most every case, especially if you’ve got a lot of separate data types for storing user information than you need.
If expressed this information on this Forum in past, the truth of it has not changed. People should run numbers for WU strategies to verify if a hypothesis is true or not.
I think we’re actually agreeing on the WU math, but I don’t agree with the conclusion that separating data types will result in higher WU in almost every case.
Bubble’s own documentation says that the Current User data is downloaded on page load, including the fields the user is allowed to see according to privacy rules. That’s exactly the scenario I was referring to.
If I have 40 or 50 fields directly on User, including information that is only needed on one specific page, I’m potentially sending that data repeatedly even though most of the app doesn’t need it.
If I move rarely used data into a related data type, then yes, I’ll pay something when I actually need to fetch that record. But I’m no longer sending that information on every page where Current User is loaded.
If you need the address on basically every page, then yes, putting it on a separate data type could absolutely be less WU-efficient. But if you have information that is rarely accessed, while the User itself is loaded constantly, separating it can make perfect sense.
The additional create/modify cost is also real, but again it becomes a question of reads vs writes. In most apps, profile-related information might be written a handful of times but read hundreds or thousands of times.
So I definitely agree with your last point: measure it. I wouldn’t recommend splitting data types blindly just because “smaller tables are better.”
My point was more about avoiding an unnecessarily bloated User data type and structuring the database according to how the data will actually be consumed.
Yes, basing when to decide to split is extremely important. The other user posted they are trying to do it everywhere possible.
I would say things like classes might be related to access of features, preferences needed for loading page states or communications, billing could be related to access of features, enrollments maybe also related to access of features, so depending on what the app does and what the separated data is for makes a world of difference.
Also keep in mind, the user is fetched as a individual data request once per session (I do not believe bubble fetched the current user on each page load if user navigates around, but I could be wrong), and I think we do get charged for fetch of user if running backend workflow (again I could be wrong) but in a hypothetical situation of a user data type with 40 additional fields that could instead be separated into 5 different data types, where each field is 40 characters (bubble charges for name of field and field value and some extra details like text, number or date, so I assume 40 characters is generous enough per field), the math shows if we assume 3 user fetches a day for a month the cost per character is less than a half a workload unit.
40 fields × 40 characters = 1,600 characters per record fetch.
3 sessions/day × 30 days = 90 fetches/month.
So:
1,600 × 90 = 144,000 characters/month
At 0.000003 WU per character:
144,000 × 0.000003 = 0.432 WU/month
So the per-character workload cost only is about 0.432 WU per user per month.
If you need to fetch a separate data type two times in a month in that hypothetical the extra data types cost more.
My take is simple. If your current platform works, still within your spending budget and users don’t complain, then keep it. Wait until you have VALID reasons to switch dev platform, then switch.
I believe attracting more users to your application should be the first thing to worry about. it’s great you’re witnessing interest from real users and this needs to be growing all the time.
From a technical perspective, I believe you should focus more on Efficient Database Design + Properly Configured privacy rules. I won’t say that you can’t fix them later, but the earlier, the better.
No one can predict this. Only time will tell based on users behaviour.
Yes. You can even scale to more than that.
Perfectioning everything and not listening to users feedback and implementing everything they ask for. I know this might be counterintuitive but some feedback will be just noise, you should be able to figure it out.
Finally, most probably your schools have their own Identity Provider (IdP) for centralized user authentication, something like “Microsoft Entra ID, Okta, Authentik, etc..”. If any school asks you about SSO and you don’t know from where to start, please let me know as I can implement it for your schools in a matter of days.
