Thanks for sharing. Going to external DB is one of the things I have been thinking about, but the sheer complexity of it (no good no-code guide available as far as I know) has been keeping me from it.
Hi mate, what is the native solution your figured out? This is causing me no end of pain and I need to stay parallel ā¦ weāre processing emails, their links and attachments and it would take way too long to go sequential. Your help is much appreciated in advance. Iāve got some ideas as well, an exchange might be fruitful. Right now am thinking instead of updating existing records I create a new one every time so no conflict and once all done remove duplicates. Chris
Hi all. In case itās helpful, I built this plugin to get a lock on operations.
So dissapointing that Bubble hasnāt implemented database transactions (locks) yet.
Vote for this feature here
Iāve spent two years building my app on Bubble, but Iām now seriously considering rebuilding it elsewhere. Bubbleās lack of atomicity/data locks for sensitive financial transactions makes me uncomfortable, and I donāt think critical money flows should depend on hacky workarounds. Am I wrong to leave? Convince me otherwise
That is one of Bubbleās biggest weakness without a doubt. Doesnāt help that this is always ignored by some Bubblers when they say, āyou can do everything in Bubbleā.
Though you wonāt need to rebuild outside of Bubble if all you need is atomicity and isolation. Just branch the pipeline to an external DB.
For example, my booking Bubble app handles booking validation and concurrency through Cloudflare Durable Objects. It calls a Bubble endpoint after a booking is confirmed.
Bubble is not ideal to handle concurrency sensitive DB transactions.
Without knowing the exact issues you are facing, below the solution to one of the issues I was facing with reliable stock levels and related financial insight. Instead of adjusting previous records, use new records/transactions: product bought +5, product sold -3, product sold -1, product returned +1. Of course with a lot of users that will result in a lot of records. But because you are not adjusting records you can a use daily, weekly jobs to the calculate totals or, in this case, the stock level (f.i. transaction type āproduct countā) at a certain point in time. To display the current stock level you only do a search for the latest stock level transaction and the other type of transactions with a date (timestamp) greater than that stock count transaction.
Iāve done something similar where I only update Stock numbers with Searches :count. Itās a lot more compute than I would like but seems to be the most accurate way to handle this.
Queuing is another annoying problem I face here and could never really solve though - specifically in a scenario where 200 people are trying to buy 30 tickets to an event at the same time.
Yeah, agree but we are living in the age of big data. On the other hand, Bubble punishes us for using computing power by charging WUs. 
By daily adding a totals row you can limit that a bit. Even SAP does (or used to do) it this way for their ERP software.
Oof, that is a different problem. Our movie theatres here in NL temporarily block tickets. If a customer does not purchase them, then after xx mins the block is removed and they are available for purchase again. But if 300 people are waiting untill f.i. 12 oāclock to be the first to purchase tickets, this might not be a solution. But to be honest, that is a good problem to have, your app is well used.