We’re currently hitting some scaling difficulties with very long lists. To keep this from impacting the performance of Bubble, we’re rolling out a limit on the maximum length of a list: we will no longer let apps add more than 1000 items (attempting to do so will result in an error message).
We have some planned architecture changes that will allow us to eventually relax this limit or drop it all together, so this is an interim action to keep things running smoothly until we’re able to make those changes.
This should not impact the majority of our users at the moment. We’ve reached out to people individually who we know have data where this is an issue.
If you are worried you may eventually hit this limit, you can generally modify your app by doing the following:
Let’s say you have a custom type “A”, which has a field “long list X” that’s a list of "B"s. Instead of using the field “long list X”, you can create a field on B called “my A for X”, and store the A. Then, if you need to get all the Bs in that used to be in “long list X”, you can do a search for Bs filtered where “my A for X” is the right A.
If you are not sure how to apply this approach to your own app, feel free to post a question and we’ll be happy to help you figure it out! Apologies for the inconvenience.
I’m confused. I have a a list of liked Items on each User which is just a list of Items . I also have a list of users on the item that have viewed it so i can make sure the item doesn’t show up in the suggestion page after they have liked or disliked it.
How would i go about changing these? because the users that have viewed it list will quickly go over 1k and for some people the liked items list will surely go over 1k.
For the list of users who have viewed an item, I would change that to a list of items that a user has viewed. If you get individual users who have viewed / liked near a 1000 items, talk to us… we can probably raise the limit on a case-by-case basis.
Hey mario, it’s still true, but we’re in the process of migrating to a relational database, which will let us relax / eliminate this limit. We expect to make the transition within the next 2 weeks. I expect we’ll be able to immediately relax the limit. Eliminating it completely will take more time.
If 900 is the max, a list is probably going to be faster, but if you expect to go into thousands of items I’d recommend a reference to the parent on another table. That said, we try to optimize slow queries automatically behind the scenes, so the way you define it in your app isn’t necessarily the way it will be implemented under the hood… in other words, pick the option that makes the most logical sense for you as the app designer.
Has the move to a relational db been completed? Is here still a limit? And if not can you return top x amount for those situations where you may have a lot of data?
Yes, we now use Postgres as our backend. We’ve increased the limit to 10,000 items per list. In the future, we may allow unlimited length lists (via reimplementing them as relational tables – they’re currently arrays), but that will require additional work and will probably be down the road a bit.
Once you set up the data as relational tables do you see the ability to do data modeling? Ex set up tables columns relationships first then create the UI. I’m a ms sql dba so in my mind I see the data first
Personally, whenever I start building a Bubble app, I usually go to the “data” tab and set up my custom types + fields first thing… I also find it easier to think from the data layout first
Here’s the bubble -> relational glossary:
Custom type = table
Custom field = column
Custom field whose type is a custom type = one-to-many relationship
Custom field whose type is a list of custom types = many-to-many relationship (stored as an array on the first type, but as I mentioned we’ll likely add relationship tables down the line)
