Bubble is a platform for apps of all sizes. Whether you’re launching a new idea or scaling a business, it’s our responsibility to support our users by growing in a sustainable way. In order to do so, we have a usage-based pricing model so users will only pay for the resources their app uses.

Our mission is to make software development more accessible — Instead of requiring users to monitor all of the various metrics in a traditional tech stack built with code, we introduced a single pricing metric to track resources needed for each app: workload.

In this video we will break down the concept of Workload and explain how it helps simplify the complex infrastructure behind your app. You'll learn how Bubble tracks server-side activities using Workload Units (WU), which aggregate various metrics like database searches and other server tasks, so you only need to focus on a single metric to manage your app's resources.

We'll explore examples of server-side versus client-side operations, highlighting what contributes to Workload and what doesn’t, giving you the tools to optimize your app's performance without unnecessary overhead. Whether you're new to Bubble or looking to fine-tune your app's efficiency, this video will equip you with the knowledge to build smarter.

Check out the full manual for a detailed list of activity types and their Workload costs.

What is Workload? Workload represents the server resources needed to host, run and scale apps built on Bubble! Your Bubble app is constantly doing things behind the scenes for you, and Workload is our way to bring it all together.

Traditionally, teams of software developers typically need to manage a complex infrastructure with various systems, like servers, networking, storage, and more. Each system also comes with its own set of technical metrics to monitor, like CPU usage, load balancing, bandwidth consumption, and network latency - and that's just to name a few!

Instead, Workload aggregates how much server resources are needed for different processes, making it simple for you to track just one metric. That metric is Workload Units, and it calculates the amount of Workload your app consumes. Bubble will use Workload Units by tracking various activity types that each contribute to the total amount of Workload you consume. It calculates the total work that your app does during each month, and resets at the beginning of each new month.

Since every app is unique, this approach ensures a use-case agnostic way that lets you scale your app based on actual app consumption. Here is a brief, non-exhaustive list of activity types that contribute towards your Workload usage:

Each activity type comes with a starting cost of Workload Units that build the foundation for the total calculation. For example, the starting cost of performing a database search is 0.3 Workload Units and the cost of deleting a thing from the database is 0.1 Workload Units. You can find the full list of activities and their respective costs in the manual.

The most important thing to note here is that workload is all about server work. In other words, things happening client-side don't cost workload at all unless it involves some work from the server. Let's take a look at an example together.

If you wanted to create a custom state with basic data such as text, numbers, or date values, well data like this is saved on the user's device or browser. As such, they do not involve the server, so the action to set a custom state does not incur any Workload!

Conversely, if we need to use a custom state with a custom data type, we would need to fetch that from the database. The set state of a custom element action would still be free, but searching for the data would incur a Workload activity cost. Let's break it down.

Using "Do a search for" incurs a starting cost. The complexity of the search you do and the volume of data returned adds to the base to create the total amount of workload used. As we can see in this example, since the client-side action, which is setting the custom state, requires an additional server-side action - searching for and returning data - your app is doing work that uses Workload.

Let me repeat this: the activity types start the cost of an operation, but the complexity of the operation that you add determines the final value. It may feel overwhelming to be expected to calculate the little details, but here is where I want to inform you that it is not our intention. For most operations on Bubble, they are very low cost to execute and there's no need to analyze, understand, and predict every single operation down to the last decimal place. Rather, it's about understanding the totality of how Workload is calculated so you know the best way to build for your use-case.

It's important to know the difference between server-side and client-side. The client-side is the user on their device, using the application. The server is doing the heavy lifting: fetching the information and returning it. You will not incur Workload cost from a client-side operation. Let's take a look at an example.

Here is a repeating group of company-based users. I've set up some checklist functionality within the repeating group so that a manager can select a list of team members to later save to the database. Now, displaying this list of users requires fetching the data from the server, and therefore incurring Workload cost. The checklist functionality itself is enabled by using a custom state list to save the selection. Since we're not querying the database when making the selection, this is referred to as a client-side operation, and no Workload is incurred.

Now workload is an important topic to understand, and now that we've covered the basics of it, we're going to take a look at tracking and optimizing it. For more information on understanding workload and the inner workings of each activity type, please check out our manual to read all about it.