Is using 80 WU for a single Create Record normal?

notorioustech · 2024-12-01T16:09:54.412Z

I don’t know how bubble can expect real world applications to be built if just updating 3k records causes over 100k in WU burn.

Using a recursive workflow with an update and a write to log table. Turns out just act of writing to a log uses 80 WU? I am just referencing items in the recursive list so there shouldn’t be much overhead.

How is this possible?

image574×777 104 KB

image844×459 23.8 KB

image852×275 7.34 KB

LittleBubbler · 2024-12-02T04:39:14.775Z

No, it shouldn’t be.

From what I can see, your records are referencing/searching for another value before creating the actual entry. I’m not sure if this is the culprit, but it could be.

You mentioned that it’s a recursive workflow with an update & write fuction for logging purposes. Perhaps you could share the entire logic for it?

notorioustech · 2024-12-02T06:41:41.532Z

i already deleted the offending logging call as i need to run it for more records.

but it was basically two workflows startfix and runfix

startfix
schedule a workflow “runfix” that takes a list of items then
a. does update on first item
b. writes to the log about that happening
c. schedules “runfix” on list of items minus first item
d. stops with list of items is zero.

the insert references items in the list including a current count and references a subitems property.

Given that lookup are listed as < 1 WU the MAX this single event should have cost is 3 WU.

Since i deleted it, i am not going to report it to support and go through the whole process.

I just want people to be aware of these crazy calculations they are doing.

Frankly. Unless you go on enterprise plan, bubble is useless for any serious application with real life data.

I am scared to clean up my database because it will use up my monthly quota!!!

notorioustech · 2024-12-02T06:48:20.319Z

As a note, i have been on bubble for 7 years and built two enterprise systems on it with many millions of records. My prior system was hybrid with most of the data in elastic search and bubble was just the config admin and UX and running on dedicated server.

This current system is mostly bubble for data storage and now i am regretting that decision since the forced upgrade to WU model a month ago.

Having to limit functionality due to WU fears is very anti-innovation. It’s like we are back in the 80’s.

johnny · 2024-12-02T07:00:13.980Z

Why did you run a recursive workflow instead of scheduling a workflow on a list?

notorioustech · 2024-12-02T08:16:01.054Z

There were three use cases i could have done.

Update a list
Schedule workflow on a list
Recursive updates

I use all three in difference scenarios.

There are four reasons for recursive model.

you can cancel it by passing in a data structure like job that has a cancel flag
you can keep track of count of items updated through that job object
you can know when it is done
you can add a sequential data type to the object

Recursive is the slowest actually, and just chose this in case i needed a cancel flag.

The fastest model of updating very large number of records is to use a combination of recursive and update a list of items btw.

Choosing recursive should have only added 1 WU for the scheduling and when i removed the create log entry, processing 3k items went from 120k WU to like 5k…

So something else is wrong.

notorioustech · 2024-12-02T08:25:56.876Z

Saying culprit is rather funny. That is like debugging a pointer in c++.

We shouldn’t have to identify a culprit for every simple process, it is not the no-code promise.

The bubble pitch is anyone can build anything, but how is someone without years of real world development experience going to hunt down culprits and then have to figure out different design patterns to solve the same problem twice.

I have 30 years btw, and can spend the time to hunt these down and modify the approach easily. But the problem is I already burned WUs that is a huge pain to try and prove and get back and it slows down development and shouldn’t