Are apps built with Bubble scalable?
7th November 2024
How many users can your Bubble app really support?
The answer to this question is not a fixed number.
If you’re looking to build a scalable app that can handle many users, then you need to be asking a different question.
What is the right question to ask?
Okay – so, let’s start with the basics. When new users sign up to your app, they create a record in your apps database. Each user is represented by a single row of data. See an example of users stored in a database below.
On Bubble’s paid plans, there is no limit to the number of users that you can store in your Bubble database. However, just because you can store unlimited users, this does not mean that your Bubble app will perform well at scale.
In fact, rather than asking “how many users can your Bubble app support”? A better question is, can you use Bubble to build an app that can support lots of users in an efficient, performant & secure way?
Building an efficient & performant app is really important. This is because, if your app is inefficiently designed it will be slow & will cost you more to run. App slowness will cause you to lose users to your competition & high running costs will eat into the profitability of your app as you scale.
As you scale, the security of your app is also massively important. Data leaks might not seem important when you’re at ideation stage, but data leaks suddenly become real as you start onboarding actual users to your app. According to the IBM Ponemon Survey the cost of a data breach is in excess of $4 million per incident & the number of instances are increasing.
So – does Bubble let you build an app that can support lots of users in an efficient, performant & secure way?
The main five limits in Bubble apps are:
Let’s go through each of these limitations now & look at what the solutions are to these limits.
Database design
Database design is fundamental to your app development. A well designed database will be fast, easy to extend & will guarantee data security & integrity. A poorly designed database will be slow, impossible to extend & will cause data errors & data leaks.
In Bubble there are certain limits that can cause your database to perform sub optimally at scale. This is because Bubble does not let you perform all the database operations that professional database administrators (DBAs) do on a daily basis.
One example of where Bubble’s database is limited is Bubble’s database designer. The designer does not let you create junction tables. Junction tables are used to implement many to many relationships in your apps database design. Without the option to create many to many relationships, this will cause errors to materialize in your data & increase the risk of a data leak.
In contrast, traditional coders use a language called Structured Query Language (SQL) to design & implement an app’s database. SQL allows for total flexibility when designing your database – however using SQL requires knowledge of code. Below is an example of a tiny bit of SQL code that allows you to create a table to store users in your database.
CREATE TABLE app_5177.users (
id serial NOT NULL,
first_name varchar,
last_name varchar,
email varchar,
password varchar,
PRIMARY KEY (id)
);
But what if you don’t already know SQL? What can you do? Can you still use no-code?
Modern hybrid no-code platforms let you generate real SQL code, but in an entirely visual way. Below is an example of Dittofi’s hybrid no-code builder. As you can Image: Dittofi’s hybrid no code platform. Build apps visually & generate professional, enterprise grade code.see, the top half of the screen shows the database tables & in the bottom half of the screen, you can see their corresponding SQL code that can be accessed & edited.
The best hybrid no-code tools come with generative AI plugins. Tools like ChatGPT can allow users of all technical backgrounds to generate custom SQL & blocks of code in other languages at super high speed saving you time & money in your app development. You can then import this code directly into the hybrid no-code platforms. Below is an example of how to do this using Dittofi’s hybrid no-code tool.
Scaling Specialists:
Learn how to create a scalable database design using Dittofi’s hybrid no-code platform.
Vendor lock-in
The next limitation when scaling your Bubble app, is that Bubble does not let you access, customize or own your apps source code & intellectual property. The image below is taken from a blog article written by Thomas Groc & covers certain Bubble limitations.
Bubble developers will tell you that it is not necessary to own your app’s code. However, as you scale, it is essential to be able to access, edit & own your app’s code. This is for several technical & business reasons.
On the business side, there are two main reasons why you should own your apps source code & intellectual property.
(1) Without ownership of your code, your technology roadmap is not strategically future proof. This is because building on Bubble means that your tech roadmap is 100% dependent on whatever Bubbles roadmap is. If Bubble deprecates support for a particular browser – as they did in 2020 when they stopped supporting Internet Explorer – you will also need to deprecate support for that browser.
(2) Without ownership of your code, you’re not able to build up intellectual property value in your business. As a result, many VCs will not invest into tech companies built on Bubble.
On the technical side, you will find that your Bubble app hits technical limits at around the 1000 user mark. These technical issues largely result from the complexities in delivering a great user experience with (1) many users & (2) a wide variety of user devices that are accessing your app.
In the first case, efficiently supporting more than 1000 simultaneous users requires carefully architected code. These types of architectures are not possible with Bubble. In the second case, as you scale your user base, the variety of devices that you app will support will increase. As this happens, you will see more & more of your apps components fail to load on certain devices.
To solve the problem of unsupported devices, you need more granular control over your apps source code than Bubble provides. This will allow you to design fall back mechanisms for when one component fails to load.
At Dittofi we recently helped build an app for the PGA Qualifier in Wichita, Kansas. The app had to run in real-time & needed to support 3,500 concurrent users. A short video of this app is below.
The app used websockets to provide users with a superior real-time app experience. However, websockets are a relatively new technology. This means that they are not supported on many devices including certain versions of Edge, Safari, Chrome & Firefox. Therefore, to offer real-time on all devices, we had to design a fallback mechanism to automatically poll for records where websockets failed. This method relied on a protocol called HTTP. This would not have been possible on Bubble & without access to the source code, the app would not have worked.
Our suggestion here is that, if your app is central to your business you should look to use Bubble apps as short term solutions or for rapid prototyping & not as the base for sustainable app development strategy.
If you’d still like to use no-code for all your apps, there are alternatives to Bubble. We suggest looking at no-code tools that let you build visually, but also give you access to & ownership of your code when you need it, such as Dittofi for full stack code ownership, or for frontend mobile development FlutterFlow or AppGyver & for frontend web development, WebWeb.
No-code vs hybrid no-code
Learn about the differences between Dittofi & Bubble.
App hosting
The most important aspect of scaling your Bubble no code app is app hosting. Bad Bubble app development can be hidden by running your app on powerful servers. This leads to higher running costs that eat into the profitability of your app. The post below is an example of where Bubble users are struggling to handle the cost of hosting their apps as they scale.
Nowadays, there are lots of technologies to keep your app hosting costs low & can even turn your app hosting model into a competitive advantage. For example, all major hosting providers (Amazon, Google, Microsoft & others) now offer fully serverless & elastic products. These allow you to run massively scalable, low cost & secure infrastructure with minimal in house management. This can be a competitive advantage for your business as better hosting your users will get a better end app experience &, lower cost hosting means that you will have more funds to deploy for marketing & sales.
Bubble & all traditional no-code platforms do not allow you this level of customization in your apps hosting. This means Bubble apps are more expensive to run, experience more down time & are less secure than can be achieved with traditional development. All that being said, building a cloud native app requires a lot of initial investment & very difficult to find resources.
At Dittofi we have developed a solution for this. Our hybrid no-code platform allows you to auto generate a cloud native app, that you can own, in a single click. This is called Dittofi Automated DevOps Solution or Dittofi ADS.
Security & compliance
Data security laws vary by region. For startups, this means that data security is often an afterthought when you have no users. By contrast, scale ups often look at security & compliance as a blocking function that slows down innovation i.e. Information Security teams will tell you why a new feature cannot be added, because it is not secure.
Hosting providers such as Amazon, Google, Microsoft & others have attempted to challenge the paradigm of “build apps fast OR securely”. These providers now give the option to “build apps fast AND securely”.
For example, if your app needs to be GDPR compliant, you can use Amazon’s Route53 service to automatically direct users with a European IP address to a server based in the EU. You can also run your app on Amazon’s Elastic Container Service (ECS). Using this service, Amazon assumes total liability for how your operating systems are patched & fixed. There are in fact over 600 cloud services designed to allow you to move fast AND securely in your app development.
As we have already seen, Bubble does not allow you to utilise these modern cloud services. However, Bubble does give you a basic setup that you can use when you’re running beta test users. After this point, Bubble allows you to purchase a private server off them, where you can run your app. Bubble does still host the app however & their security measures & app hosting setup is a closely guarded secret. Teams that work with Bubble apps have told us that this can make it hard to respond to security audits from data compliance officers.
Another major challenge with hosting your app with Bubble is to comply with HIPAA or equivalent medical data protection laws. For instance HIPAA requires that your clients data is not accessible outside of your organisation. This is something you cannot confidently comply with when you host on infrastructure that is not owned by you. In effect, Bubble is storing all of your data & telling you to “trust us, we are not looking at your data”. This is the opposite of how secure, zero trust systems are built.
As mentioned above, the upfront cost of building your own scalable hosting model is very expensive & requires difficult to find resources. This makes it inaccessible for many startups, scaleups & SMEs. For example, the average cost of building a fully cloud native app that can scale up efficiently on demand is approximately $1 – $2 million in up front investment & will take 12 – 18 months to deploy. For this reason, many startups tend to look past Bubble’s lack of data security & just focus on their MVP, but for SMEs Bubble is not an option.
At Dittofi we have solved this problem by giving you the chance to bypass the development & management of your own secure infrastructure. We do this by giving you the option to deploy your app immediately into your own Amazon hosting environment. We then let you continually push changes to your app into this environment directly from inside Dittofi’s hybrid no-code platform. This allows you to build & scale apps securely on your own infrastructure.
Scaling Specialists
Learn about Dittofi’s model of shared responsibility.
Workflow performance
Another factor that determines the efficiency of your Bubble app are Bubble workflows. Workflows are configurable blocks of pre-built functionality that you can chain together to develop functionality for your app. For example, you can create workflows that your users can trigger to run searches, calculate flight prices, check user authentication & so on. An example of a Bubble workflow is shown below.
Bubble workflows have a massive impact on how your Bubble app performs & how much it costs to run your Bubble app. This is because Bubbles pricing is done in terms of Workflow Units (WUs). If you have an inefficient workflow, then the cost of hosting your Bubble app will increase.
Bubble experts often talk about Bubble best practices to optimize WUs. This is especially the case since Bubble has updated the way WUs are computed several times. When this happens, you will need to update your existing Bubble workflows & this can end up costing more. Below is an example of a tweet from a Bubble expert showing how to lower your Workflow Units.
All that being said, even if you architect workflows in your Bubble app according to Bubble’s recommended best practices, Bubble workflows are totally non standard way of building apps & workflows are massively inefficient when compared to traditional code & here are some reasons why.
- No distinction between the frontend & backend workflows.
Every app in the world can be thought of in two parts: a frontend & a backend. The frontend is the bit of your app that your users see & the backend is the bit of your app that your users don’t see. Along with displaying your user interface, the frontend of your app will also perform certain tasks. These are generally small tasks that don’t require much power & do not need to be run securely on the backend of your app. For example, checking the number of characters in a tweet, changing the style of your app from dark theme to light theme & so on.
The backend of your app is required to run more complex & sensitive tasks. For example, calculating flight prices, checking user password credentials & so on.
In Bubble, every task is handled using workflows. Bubble does not let you choose if these workflows run on the frontend or the backend of your app. This makes it impossible to optimize your app as you scale. This is because tasks that should take place on the frontend of your app get sent to the backend of your app & vice versa. Below is a screenshot of a twitter user expressing his concern about why he is not able to run workflows on the frontend of his app.
- Arbitrary data processing limits.
Bubble imposes arbitrary data processing limits on their clients. For example, let’s say you want to loop through a list of users in your apps database & send each of these users an email. Bubble restricts you to looping through one record per second. This restriction introduces unnecessary slowness into your Bubble app that is currently impossible to work around.
- Automatic workflow refresh.
In traditional programming, your app will choose when to run a certain workflow. Bubble does not allow you to do this. Instead, Bubble automatically runs workflows for you. This is a super inefficient way to develop an app.To see why this is the case, let’s say that you are building a property management app. Your app will need to have a list of short term rental units stored in a database table marked “short term rentals”.
Now – lets say that whenever a user clicks on a button to view your short term rentals, you need to pull the data out of the database & display this to your users.
Ideally you want to run the workflow to get the short term rentals only when your app’s user clicks on an in app button. This will prevent any unnecessary processing time for users who don’t want to see the rentals data. Bubble does not allow for this level of control. Instead, Bubble will automatically refresh your screen at periodic intervals to check for new data.
These workflow limits make it impossible to build an efficient app on Bubble without massively increasing the computing power required to run your app & therefore the cost of running your app.
Bubble recognizes the limitations in their app development & is working hard to overcome these challenges. However, it’s clear that resolving all of the challenges with the workflows is not going to be easy & will require a fundamental overhaul to the way apps are developed on Bubble. Bubble will need to redesign themselves with a code first approach, which will make them more like the more modern full stack, hybrid no-code tools such as Dittofi.
What scalability boils down to
When you’re thinking about how scalable is your Bubble App & how many users can your bubble app support, you need to ask – does Bubble allow me to build an app that can support lots of users in an efficient, performant & secure way?
There are many limitations to Bubble Apps that mean you cannot build apps that are efficient, performant or secure when compared to traditional code. The trade off is that Bubble allows you to build quick, low cost MVPs. You can then rebuild these apps once you’ve got the revenue required to scale.
At Dittofi we recommend that you try modern hybrid no-code tools that offer a better, more custom, app development experience & allow you to own your apps source code, deploy your app anywhere & ultimately support you better when you’re ready to scale.
We’ve mentioned our tool, Dittofi, which is a full stack hybrid no-code tool. There are also other frontend only hybrid no-code app builders such as FlutterFlow & WeWeb. These platforms only give you ownership over the frontend of your system.
Sign up to Dittofi & try us out on your next app build or schedule a demo of our hybrid no-code app builder.