[New Thread] More context on our changes to pricing - FAQs answered

In case team at Bubble is still listening, I would chime in with my few cents.

  • I feel Bubble must have two components of the fee. One should be platform fee which is for the features they are building etc. Other one should be for the usage.

  • And with so many limitations in Bubble with respect to performance, Bubble should not be adding a lot of margin on “usage and performance” because we are forced to work around Bubble’s limitations. So Bubble ought to fix a good majority of those issues before premium on “performance and usage charges” are brought in

  • When performance and usage based charges are introduced, have a very clear way for us to estimate and track usages of various actions

  • And for the usage, it should be a fair premium on the charges borne by Bubble. Say 20% margin?

In case they need to know, here is a list of my thoughts on performance limitations in Bubble.

  • No good and easy way to work on lists and iterate through lists
  • No way to have temporary variables in workflows
  • No way to have return value of workflows
  • No way to have duplicate elements in lists (so can’t store shopping cart maps in local custom variable, but have to create a data entry for this)
  • Recursive workflows require long lists to be passed to workflows. Will long lists cause higher workload? No way to prevent this.
  • No way to take bulk actions on items without running recursive workflows.
  • Not even possible to bulk import or delete records easily and without consuming workload units
  • Repeating group data refresh has issues and we have to come up with workarounds of multiple calls to counter it to some extent.
  • Workflows require lot of searches to be done again and again due to small variations as there is no good way to store and reuse the results or point to a mother search and reuse it partly etc.
  • No good way to search with OR or such composite conditions
  • No way to search with a constraint where a list field has an intersection with a given list
  • No good way to search on second/third level fields (“This data’s field1’s field > 10” kind of thing)
  • No way to search where a field of data type can be compared to another field of data type or its some computed value
  • No way to store data-mappings in DB as a field. It is required so often. Because of this new tables need to be created/managed
  • We need to keep our tables flat instead of normalised as the searches become very extensive/expensive and often impossible. But this means that individual tables become fat. Now since they become fat, even small operations over there simply cause a lot of workload.
  • There is no way to get only certain fields from search and thereby reduce the workload.
  • Since there is no way to do a simple forking of if-else logics, we need to keep repeating same condition in multiple actions resulting in more workload being used. And all of those steps consume workloads even if they would actually not get executed at all if it was normal if-else fork.
  • Since there is no assurance of workflow steps to run in sequence, we have to do a lot of extra processing of “if result of this step was not empty or if it was empty then if that was true…” to make things run in sequence. All this increasing workload.
  • No easy way to get just the count of a certain search or a particular data type
  • There is no option to do a “create new or update existing”
  • There is no way to “Update only changed fields” in case there is an edit form and I want to update the thing changed by user where user has changed only few fields. I still need to write full “make changes to thing…” with all the values in the form
  • There is no way of doing a “function call”. So if we want to keep our app modular, we need to do a various “call this api which will call another api” etc and that increases the load. We can use custom event if it is all within backend, but from front-end there is no way to call a custom event within backend. So I need to create an API call excessively for sure.
  • No clean way of assuring atomicity of operations.

By the way, I am on professional plan and consumed 66M workflows last month :cry:

44 Likes