I’m trying to find ways to save on WU usage. I found in the documentation this Bubble plugin called “SQL Database Connector”, that let developers get data from external databases, like Microsoft SQL or a MySQL database.
What I want to know is does this plugin consumes WU?
If it doesn’t, then I’m willing to build a separate database for my app in order to save on WU and migrate all Bubble data to it. Even if I need pay more to keep the database active, at least it’s a fixed and predictable cost.
Each call to the database (which goes through the plugin) will consume WU, would be interesting to know if it consumes more or less than using the bubble database (id guess more).
I’d say using my own database should consume less because then the Bubble back-end doesn’t need to perform any database operations, only a request to an external service. On the other hand, using the regular Bubble database should consume more because the back-end is performing database operations in addition to the request to the back-end.
I will conduct some tests on a test app to see if I notice any changes in WU usage after several days of using Bubble’s database versus my own SQL database. It will take some time, but I think it would be interesting to find out.
That would be amazing to know! please do share your findings 
I’d love to know an answer to this as well ^ +1
Apologies for the lack of updates on this matter. Over the past few months, I haven’t had the time to test the difference in WU consumption. However, the Bubble team has now added the ability to measure WU usage by the minute and improved drill-down options. This allows us to gain a clearer insight into how WU are utilized in the app. With this new feature, I can conduct quick tests on free test apps, avoiding the need for a whole week of testing to obtain meaningful results.
I started by creating an empty app from scratch and setting up two front-end workflows. Both workflows are set to “Do every 5 seconds,” but I adjusted their running frequency to every 60 seconds.
The first workflow, named “Bubble workflow,” contains actions related to testing the Bubble database. Meanwhile, the second workflow, named “SQL workflow,” includes actions for testing a SQL Server database.
Both databases share the same type/table, called “Tabela Teste” (Portuguese for Test Table), and the same field/column named “Teste” (Portuguese for Test).
The SQL workflow consists of the following actions:
Here’s what each step does:
“inserir_teste”: This action inserts a new line into the “Tabela Teste” SQL table using the “INSERT” SQL statement.
“Add a pause before the next action”: A one-second pause is added between actions.
“obter_teste”: This action performs a “SELECT” statement on the “Tabela Teste” table to retrieve a list of lines that contain the same value used in “Step 1”.
“Set states Teste… of index”: The first item returned by “Step 3” is obtained, and the value of the “Teste” column is saved in a custom state within the “index” element.
Another one-second pause, similar to “Step 2.”
“excluir_teste”: This action executes a “DELETE” statement on the “Tabela Teste” table to remove the lines containing the same value used in “Step 1”.
Here are the actions set up for the Bubble workflow:
Explanation of each step:
“Create a new Tabela Teste…”: This action inserts a new line into the “Tabela Teste” Bubble type, using the same value that was used in “Step 1” of the SQL workflow.
“Add a pause before the next action”: A one-second pause is added between actions.
“Set states Teste… of index”: This action retrieves the list of lines from the “Tabela Teste” Bubble type that contains the same value used in “Step 1” of the SQL workflow using the “Do a search for” expression. Then, it selects the first item from the search results and saves the value of the field “Teste” in a custom state within the “index” element.
Another one-second pause, similar to “Step 2.”
“Delete a list of Tabela Testes…”: This action deletes a list of lines from the “Tabela Teste” Bubble type that contains the same value used in “Step 1” of the SQL workflow.
The obtained results were in line with my expectations. The SQL Connector consumes fewer WU compared to performing Bubble database operations. Below are some of the graphs available in the logs tab. However, before we delve into the details, it’s worth noting that although all the testing was conducted on 08/03/2023, Bubble displayed the results as if the testing occurred on the day before, 08/02/2023. This discrepancy is something that the Bubble team might want to investigate.
The graph below depicts the overall WU usage for the test app I created:
The next graph presents a Pie chart showcasing the app’s overall usage:
In the latter chart, you can observe that most of the usage belongs to the two workflows I designed, with “Fetching Data” constituting 6.09% of the total:
Upon examining that portion of the chart, it becomes apparent that the majority of the usage for the “Fetching Data” section is attributed to data searches on the Bubble database, with the remaining part related to processing data requests. When comparing the WU used for SQL Connector versus Bubble database, it’s important to consider this additional load on the Bubble database:
Now, revisiting the overall usage, it’s evident that the “Workflow” type accounts for approximately 93.85% of the app’s consumed WU:
Upon clicking on that section of the chart, the two workflows I created become visible. It’s noticeable that the Bubble database workflow has utilized more WU compared to the SQL workflow, disregarding the impact of “Fetching Data” usage:
Upon analyzing the usage for the SQL workflow, we observe that the WU consumption is evenly distributed among the three actions: “obter_teste,” “inserir_teste,” and “excluir_teste.” This equal usage suggests that all these actions involve only processing requests and converting the returned values into the Bubble data structure. For Bubble, they essentially represent the same operations.
Now, shifting focus to the Bubble workflow, we notice varying WU usage across its actions. The first two actions that consume more WU involve write operations in the database. The third action, a set state action, only performs a “do a search for…” operation.
After considering all the information presented, the decision between hosting a SQL database server or using Bubble’s own database depends on whether you prioritize control over WU usage or not. Below is a list of pros and cons that I have compiled based on the insights gained from this test, comparing the use of Bubble’s database versus an SQL database with SQL Connector as an app database.
Pros:
Cons:
Pros:
Cons:
For individuals already familiar with configuring an SQL database or those who already have one containing user data, the SQL Connector can significantly reduce WU usage and provide more control over the data used by the Bubble app. However, for those unfamiliar with SQL databases, spending time and effort on learning how to manage one may not be worth it. In such cases, it might be better to accept higher WU usage in the app and focus on optimizing other aspects.
I would love to hear your opinions on this matter. If you have any suggestions for additional information to include in this topic, please let me know, and I will respond as soon as possible.
If you are decoupling the front from the back end, get tf off bubble and use weweb. Bubbles biggest selling point is how nicely it ties in to the backend and it’s nocode query builder. Without the need for that, it’s an overweight front end builder.
Hey @GrupoPortfolio thanks for the investigation and insights! I really can see several use cases for this!
Amazing work!
Hey there, take it easy and relax. What’s got you so worked up?
My intention wasn’t to invalidate the advantage of Bubble. It was merely an investigation out of curiosity because, where I work, we highly value predictable costs without having to pay more for them (such as upgrading to a higher tier of WU, even if we won’t use all of it).
Furthermore, you’d still be able to utilize most of Bubble’s “back-end management” with this Bubble-made plugin. The only difference is that the database would need separate management, which isn’t a problem for some of us, myself included. Bubble would still provide most of the handy expressions in the expression builder, so, in the grand scheme of things, it wouldn’t change much about how you build apps with Bubble. You’d still have the ability to use workflows to edit data and perform various tasks.
The only downside that I see would be the substantial number of actions that you would have to make available in the data tab of the workflow editor for larger databases, but it’s manageable.
What I said is not merely a reason to use ‘weweb.’ Even if we regard Bubble as merely an ‘overweight front-end builder,’ it would still be far superior to manual front-end development, greatly enhancing development agility. Among the Web App editors I’ve tried, none offer the same level of ease of use as Bubble. Additionally, some of the other good solutions available sometimes compel you to use their own services. Bubble stands out as the only one that allows such seamless integration with other APIs and databases.
And please remember, people are different from you. Some may find the ‘nicely ties into the backend’ aspect great, while others may not value it as much because they are already familiar with building back-ends, and that’s perfectly okay. Bubble will continue to have users and will continue to grow regardless. If the research I did upsets you in some way, then it means it wasn’t intended for you.
You asked for opinions… you got an educated and emphatic opinion. From someone with experience doing it both ways. Who has seen the glory and the pain points behind both approaches.
Debatable and utimately decided upon by your need, skill set, and comfort zone.
This is silly and incredibly presumptuous. There’s not much you can do from grind your keyboard that would upset me. Again, you asked for opinions and not a truly objective analysis of the pros and cons.
Open up the floodgates and water will surely flow in.
Also, I love rousing the dust and ruffling some feathers every now and again.
I appreciate your feedback, but the way you responded made it seem like you were disregarding the research I conducted and discarding it solely because it didn’t align with Bubble’s intended purpose.
I agree with you and that’s precisely why I undertook this research in the first place – to test that use case and engage in a respectful debate on the topic.
I apologize for my earlier response. I was fatigued and didn’t think clearly, which made me feel attacked by your feedback. When I asked for opinions in a forum of a professional tool, I had hoped for constructive responses and discussions. I didn’t feel I received that from your response. I’m sorry.
