Summary:
-
We’ve spent the last few days reading and listening to the community’s feedback. This post summarizes the adjustments we’re making in response to what we’ve learned.
-
We’re making the key activities crucial to scaling your app on Bubble cost fewer WUs than originally planned by 50–99% beginning this Thursday (leading to a ~30–90% decrease in cost).
-
We are releasing new tools to help make WU consumption easier to analyze and understand; our first releases include a new subscription planner and the ability to see how much WU is consumed by each workflow and action in the Logs tab.
-
We are increasing the WUs in the free plan to 50K WUs and giving all paid apps 100K free development WUs per month.
Hi all,
I want to start by acknowledging the frustration and concern expressed by our users regarding our new pricing structure. I have personally read the feedback in this forum, on Twitter, and the emails that have been sent to me, and so has Emmanuel. Both of us, and the entire Bubble team, do not take this feedback lightly or for granted. We appreciate that the activity here is the result of a passionate developer community that cares about this platform, is concerned, and is invested in the future of Bubble.
We recognize that we could have communicated this change more effectively and been more clear about user impact.
The bulk of this post will be dedicated to the changes we’re making to workload in response to the most common themes from the feedback below, but first, I want to help clarify a couple of points of confusion and share a few updates:
- You do not have to switch to annual pricing to remain on the legacy pricing structure. This is not a change from our last announcement. If you’re currently on a paid plan that uses capacity, regardless of your billing frequency, you can stay on your legacy plan until October 2024. Switching to annual pricing before May 1 will lock you into a discounted price for the next year.
- There are custom plans for high WU apps. If you have over 40M WUs and are looking for consistent, discounted pricing, please contact our sales team for a custom plan.
- A new subscription planning tool has been released today. It enables you to input your current WU consumption and get a recommendation for the most cost-effective way to add a WU tier (if applicable!). Since we are making an important change to WU calculations, we recommend taking this Friday’s usage and multiplying by 30 to estimate your new level of consumption as input for the planning tool.
- We are increasing the Free plan to include 50K WUs. Developers of new apps can build and learn much more before they need to upgrade.
- All paid plans will now include 100K of free development WU per month. We want to support users in their development phase and encourage building, testing and debugging apps.
You can read summaries of our changes to workload and tooling below. I’ve also provided a technical deep-dive into what workload is, where it came from, how it relates to capacity, and exactly how certain weights are calculated.
Summary of changes to workload
After taking all of your feedback in, we are confident that we have the right structure — workload is the right path forward. However, two important themes have emerged from the feedback:
- There are actions in Bubble that cost too many workload units (WU) making Bubble unaffordable for many builders. In its current state, certain activities, like calling out to external APIs, consume too much workload to make key use cases viable
- The tooling Bubble has provided to understand and assess workload is not yet sufficient
WUs are calculated by assigning weights to various activities Bubble performs in order to run your application. Over this past week, we’ve re-evaluated each weight in our pricing model, and we’re adjusting them in order to ensure Bubble is more affordable. We’ve also worked hard to build out more extensive tooling and there will be much more coming soon.
We’re making the key activities crucial to scaling your app on Bubble cost fewer WUs than originally planned by 50–99%. The impact of this change on your app will depend on the features your app uses the most, but we expect apps to see a 30–90% drop in total WU consumption relative to the numbers you’ve seen in your App Metric Tab thus far.
We haven’t made these changes lightly. It’s important for us to have a sustainable pricing structure that will enable Bubble to invest in necessary features and operational excellence in the short term. But given the community’s feedback, we’ve decided that it is just as important to ensure that builders continue to be able to create — affordably —on Bubble.
Some of the biggest changes to weights will be made in areas identified by our community as fundamental to launching and scaling a company on Bubble. For example:
- Inbound and outbound API calls
- Searching and displaying data
- Running workflow actions
- Deleting data
The full set of new weights are shown in the section “How many WU do different activities consume?” below.
We’re planning to deploy this change at 9 AM ET on Thursday, April 13. While you won’t see a retroactive change in your historical WU consumption in the App Metrics dashboard, going forward, you’ll see an decrease in your app’s WU consumption starting on Thursday.
Updates on tooling
A clear theme from the feedback on the forum is the need for stronger tools to understand WU consumption. We’ll be releasing our first updates Thursday morning (ET) in response to community feedback: users will be able to see WU per action and workflow run in the Server Log tab.
Here’s our current roadmap to improve workload transparency and predictability. (This is subject to change over the coming weeks based on customer feedback.)
A closer look: What is workload and where did it come from?
Workload is a measure of the amount of work Bubble does to run an app. It tracks the activities that Bubble’s backend servers and infrastructure take when users visit your app’s pages and interact with your app’s API, like when you run and schedule workflows or load data to display to the end user.
Workload replaces our old metric, capacity, which was how Bubble measured infrastructure usage. Although it’s evolved, looking back at capacity can help me explain how workload functions under the hood.
It all started with capacity
Bubble started measuring capacity back in 2017. Before that, on Bubble’s shared hosting, we’d give every application as many resources as it asked for in order to let all apps run as fast as possible. But as more and more apps began successfully scaling up on our platform, they competed for resources leading to outages and downtime. Capacity created a necessary upper bound on how much of our resources any one app could consume at once. We measured it in terms of the number of milliseconds of Bubble server CPU time spent running web requests related to that app (people visiting a page, people running workflows, and people uploading files or interacting with the API).
However, web server CPU wasn’t the only resource we needed to measure. Database usage was another critical factor. It is very difficult to measure how many ms we spend per app in real-time on a database because execution is controlled by the database engine, not by our code. So, we developed heuristics to estimate the impact an app’s queries had on database CPU and memory. We also developed similar heuristics for resources like AWS Lambda executions.
Capacity became the pooled sum of all these measures and heuristics, providing a single, graphable measure of how much work an app was doing at any moment in time. We started bundling it into our pricing plans because we wanted growing apps to have a way to purchase more headroom, and to enable us to invest in the extra infrastructure resources it would require.
But capacity never became a key pillar of our business; up until now, the majority of our plan revenue has come from upgraded features. But this structure doesn’t match how Bubble’s business works. Today, most customers subscribe to free or inexpensive plans so they can test and iterate ideas: of those, a very small handful turn into fast-growing, successful businesses. For a company like ours — or Stripe or AWS or Segment — usage-based pricing is a much better fit than feature-based pricing, because it enables us to better scale up with our most successful customers.
Last year’s pricing rollout was our first attempt to introduce a true usage-based pricing structure but ultimately, “DB Things” was the wrong metric. We know there is no perfect usage metric for a company like ours. The closest comparison to Bubble is an infrastructure platform like AWS or Heroku, and so the fairest metric we could pick would be one that measured overall infrastructure consumption.
How capacity evolved to workload
Capacity measures app usage, but it has a key flaw: It is too tied to the exact execution time of Bubble’s code and database calls, which is fairly dynamic in response to changes we make to our code and our infrastructure. As a shield that ensures no app uses all of our CPU at once, it’s good that capacity is directly linked to execution time — but we don’t want customer bills spiking because our database is having a bad day.
So we set out to stabilize capacity, which led us to workload. Our engineers brainstormed everything our code does that could help predict how much capacity an operation would consume. For example, when querying the database, the number of results returned is one predictor of how long the query takes to run. Or when making a call to an external API, the number of bytes returned predicts how much work Bubble has to do to process the results. We then honed in on activities that were user-legible and user-initiated so that they’d be significantly more stable — and more under the user’s control than Bubble’s — than execution time.
List of activities in hand, we ran a statistical regression comparing them to the capacity consumed by the operations that generated them. That enabled us to assign weights to each one of those activities and multiply it by the amount of activity performed. We named this new metric “workload.”
In short, workload was created to provide a more stable measure of our infrastructure usage. It tracks similar underlying things as capacity — the amount of work that Bubble does to host and run applications — but with less variance in response to Bubble code changes and infrastructure issues.
How did we decide on today’s updated workload weights?
One of the disadvantages of the way we initially created workload was that it embedded all the performance inefficiencies in Bubble’s current code into the definition of a WU. So if some activity consumes a lot of CPU time today because of things we would like to improve, the cost in WU reflects that inefficiency.
We absolutely have plans to improve the performance of our code over time, and we’d expected to pass those savings back to our customers as those newly-more-efficient activities consumed less WU. However, we have heard loud and clear from our community that “trust us, we will make it better over the next 18 months” is not good enough. It is important for use cases to be affordable for our smaller customers who are still iterating today.
So, we went back and re-evaluated the activity weights with this in mind. Today’s adjustments are an order of magnitude less than the numbers that came out of our initial regression because our priority is ensuring anyone that wants to build on Bubble is able to afford it.
How many WU do different activities consume?
We also heard your request for more transparency around how workload is calculated, so the table below lists exactly how many WU various activities “cost” — these are the inputs required to calculate total workload that will be released on Thursday morning.
One note before I dive in: The cost of each weight represents the cost of the raw ingredients for an action. The ultimate cost of something like “run a workflow that creates a new item in the database” is going to be the sum of the ingredients, which might be significantly higher than any one weight in isolation. Often, Bubble performs backend activities that might not be obvious. So if the WU consumption you’re seeing in practice doesn’t correspond to exactly what you might expect when you add together the weights below, that’s likely why. It’s easier to figure out how much something will cost by actually building it and testing it. To that end, we are working to improve our workload debugging features as fast as we can in order to make the testing process as easy as possible.
That caveat aside, here are the new weights that will soon be used to calculate workload:
When you view WU consumption in the App Metrics dashboard, you won’t see these weights directly. Instead, you’ll see the activities described here. You can think of the relationship between weights and activities like the relationship between ingredients and dishes when cooking — activities are the end results you see, whereas weights are what goes into them and determine how much they cost. For example, the total WU consumed by each instance of the “Search” activity is a factor of several weights: the base weight of a database search, the weight of each result returned from the database, and the weight of the characters of data fetched by the search.
—
It’s our hope that these changes will help make the transition smoother and better serve our customers whatever they are building on us. Thank you, again, for your feedback and support. Every member of this community makes it — and us — better.
– Josh and Emmanuel
