15+ Million Workload Units to Near Zero. Bubble Backend Migration
It was kinda interesting when Bubble released their new pricing back in April, 2023. There was a massive backlash on the introduction of Workload Units (WUs) and what this would mean for applications built on Bubble. After this backlash, members of the community were quick to run some tests and see just how expensive this would be for most applications.
After a short while, Bubble made some adjustments to their formula which effectively made everything 10X cheaper. Still, on their own forums, there were application creators with multi-million workload units who would see their pricing go from a few hundred dollars a month to many thousand. This isn't a series to dunk on Bubble, I love their product, it is awesome but I don't agree with the introduction of a fairytale unit which penalizes successful apps.
One of the main positives about the pricing change is that they gave everyone a wide deadline, a deadline of 1st October 2024 before you are forcibly moved from the old pricing system to the new pricing system. For much of 2023, this was seen as kick the can down the road and start to explore and get the mindset together needed to attack this migration and rebuild apps in an efficient manner.
My Applications
Before the cut off of the old pricing no longer being available, I grabbed a few empty applications just incase I had some ideas or wanted to do some experimenting. This proved to be a wise move as we have already put one of these to work and I am building out a second internal project on another of the shells so currently in total, I'm running 6 applications on Bubble.
Of these 6 applications, the WUs totals about 15 million which means if we keep to the new pricing, we don't fit into any plans. There is no consistency in pricing in terms of overages and it doesn't account for future growth. I like to know what my bill will be every month and the new pricing doesn't give me that confidence or peace of mind.
The Plan
The best way to make your application more efficient is to separate your frontend and your backend. Using Bubble purely as a front-end tool and using an external backend database. By doing this, you can connect to your backend via an SDK which means that actions take place directly in the browser and do not touch the Bubble server. Don't touch the Bubble server, don't use WUs.
This will have the benefit of making the app run faster, be more efficient and cost less. We are using less resources from Bubble so they are happy we are not straining their systems and we are using a backend which is completely independent and means that we can migrate this backend if we need to in the future offering greater independence.
Choosing a Backend
When looking at external backends which are supporting the no-code type apps, the options seem to be Xano or Supabase. Both of these are well funded, have a strong community and seem to be growing from strength to strength. When looking through and doing research, the barrier to entry of understanding these products looked pretty tough but from someone who has gone from Zapier Expert to Integromat (Make) to loving N8n, I just see the process as being similar.
Ultimately, I decided to go with Xano and hope this is a decision that will see me successful in the long run. I like the way that Xano has the different database structure and the builder for API requests, it reminds me of a mix of the other automation tools I mentioned above so that is set.
Digging into Xano
Xano has an SDK which means that you can push data from Xano to Bubble via the browser. There is a plugin called the Xano Connector. It is pretty functional albeit the documentation is lacking somewhat. The best resource for getting going with the Xano Connector plugin is to watch this video by Eli Beachy, be warned, you'll probably end up watching it 5-10 times.
Here, you will learn the basics, how to sign a user up, how to log a user in, how to display data in a repeating group and then some advanced things like pagination. I managed to copy most of the things shown here and then created a simple test where I put a button on a page to call an API, and then create something in the Xano database, to then show that refreshed in a repeating group. Works pretty flawlessly.
Challenges Ahead
My main concerns going forward are to make everything work relationship wise. For example an album data type showing images that are in it and some more complex scenarios. I played around with this already by showing items specifically belonging to a user only in a repeating group and am getting more confident so I'm excited to dig a little deeper into this.
The migration ahead is going to be a long journey full of potholes I am sure but it is one I am quite excited about as I see some positive speed improvements in how our apps will operate and ultimately if we can provide our users with a better experience by going down this rabbit hole, it is worth exploring.
Follow Along
So there we have! The first post in this series. I plan to post fairly regularly with my learnings and how this migration progresses. This is the first in the series so feel free to follow this blog or follow me on X - https://x.com/StuJLans.
I can't promise it will be plain sailing but I'm pretty sure I will have the skills / learn to do this pretty effectively over the next months and as Bubble have eluded to in recent updates, they are starting to gate-keep certain features from legacy plans, it makes sense to get this done ahead of the 1st October deadline to ensure we can benefit from anything they seem to have in the oven.
I'm not so much a fan of them keeping features that are pretty critical to a migration out of the hands of legacy plan holders but I have overcome bigger challenges and will overcome this one.