Hey all, assuming I need to store some temporary variable for whatever reason, will custom states generally work faster than storing the same in a Thing (say, the current user or the current page thing)?
I understand Things are talking to the database so that may slow things down, but is that intuitive understanding correct?
Thanks in advance!
(Why I’m considering using Things at all: I like the way they can be handled in workflows more, e.g. operations like add/remove list/item, etc.)
Hi there, @vovazk… my understanding is the same as yours, so if you are incorrect, well, then that makes two of us. 
I am under the impression that using a custom state for any kind of temporary storage is always more efficient/faster because a trip to and from the database is not involved. I’m not necessarily sure what you mean by handling things in workflows, but I’m sure you know you can perform the same operations on custom states in workflows, so using custom states is probably still the best way to go for temporary storage.
Anyway, just food for thought… hope it helps.
Best…
Mike
Thanks, Mike! What I mean by easier handling is that, say, if I need to add an item to a list of things, I could use “make change to thing → my list → add item.” For states I would instead do “set state → my list → its current value :plus item new item.” I know it’s probably just a matter of syntax, but it just somehow feels less efficient iykwim. I might be overthinking though.
Almost unrelated, but I sometimes wish Bubble could treat elements as a specific kind of Things (virtual ones or whatever we’ll call them), with some unified syntax for both.
Just wanted to chime in about states vs things performance.
Don’t forget about scalability. If your app saves (lets call them temporary) values in the database for a lot of stuff on the page as well as for user actions that can (and will) add up very very quickly for each additional user working on the site in terms of server capacity. Then you will encounter performance issues for all users.
Its probably a good idea to ask if a solution works well for N users 10, 1000, 1000, etc. I would say even for internal sites with a dozen or so users it could still be an issue having a lot of state-like data being routinely saved into the db depending on your plan and what the app is doing with the db.
