Custom State Performance

I feel like this question has probably been answered before but iI have been searching through posts and I have not found it. I am looking to understand the nature of custom states vs. things with regard to the underlying stack. From what I can tell from the Open jobs position on the Bubble site, the relevant technologies are Redis and PostgresSQL. I am trying to understand the performance implications of where I store data.

So my question basically is, is a custom state stored in the in-memory database (Redis) or written back to the Postgres database? What about the current user? Is the information held by the current user thing proactively cached to Redis?

Let me give a concrete example.

Example #1 - I have a number of places where someone can select a school year from a drop-down. I can:,

  1. Just make the school year drop-down static and put the text in the choices field. This would seem to have the best performance, but is the least maintainable. If I have 8 school year drop-downs throughout my app, I need to go make changes 8 times every time I want to add a new school year.

2A. Create a thing called schoolYear, add a name field to it, put 10 records in for each of the years I want to have and each place I want to show a list of school years, I can do a “Search for schoolYear”. I have solved my maintenance problem by introducing 8 places where the application will read from the database for the same content that will rarely change.

2B. I could create a thing called textLists with a field called name and a field called list and then create a record with the name “schoolYears” and a list of texts “2012,2013,2014,2015, etc.” and then each place I want to show a list of school years, I can do a “Search for textLists WHERE name=schoolYears” and then reference the list of texts.

Between 2A and 2B I don’t know which has the performance edge to be honest. With lists this small, it may ot matter but with larger lists, I think 2B is better.

  1. I could stick a custom state in my header object and load it with static school years so on every page it is available. It avoids a database trip, and it make maintenance easier (changes in one place). However, where is custom state stored? If it is really secretly just written back to the Postgres database, then I could have just gone with 2B. Also, this custom state will get created for every single user, so if I have 500 users I have the potential for 500 copies of the same data sitting in…cache? An application level custom state would probably be the best option, but I am not aware of that ability in Bubble.

So given the stack and the architecture of Bubble, which solution is best?

@josh @emmanuel

Anyone from Bubble who can shed some light on this? Or any Bubblers who can point me to a definitive post on this issue?



Hi @mguerrasio, I know you asked this question a year ago, but I just searched the forum for the same question and all I found is yours. I managed to discover the answer by myself and thought I could share in case you or someone else would still need an answer:

The custom states are saved in the client’s browser session; just like the rest of the elements in the page. I created a “FLOWER” state of type text with default value “FLOWER CONTENT” and was able to find it through the Web Inspector (Safari) even if there are no element/workflow referring to that state in my Bubble app.

To me that is good because I have a single-page app with lot of dynamic content (like 2000 entries) with several groups referring to that content. I don’t want to do a database search every time a group is shown so at the sacrifice of having a longer page load, all the entries are downloaded in a custom state so users can then have a more fluid UX. So far, didn’t have performance issues because of the size of the content.

Hope that helps.

1 Like

@petter is the guru of Bubble performance, might be able to answer this similar question as I do have too? Redis = Custom State?