Thanks @cmarchan! I had not seen that video before.
However, I believe I have already implemented @josh’s recommendation of having reference fields in each post. Regarding the example in this thread: Performance Q&A guide, how is bubble’s performance (and capacity) when there are tens of thousands of invoices and the query has to include them all?
In my app, the posts have different properties (ie user who posted it, category, etc.) and I have to search across all posts and include/exclude based on different criteria. In other words, the search isn’t straightforward. I’m not using advanced filtering, but I am looking for the newest posts that meet a certain criteria. With only a handful of users and a few hundred posts, my app is already maxing capacity on the personal plan. I can’t tell for sure, but I believe the majority of the capacity is consumed by the search operation.
I believe I can restructure the data model such that posts are placed in lists based on combinations of the criteria (again, post creators & category) and keep the lists relatively short by keeping only the most recent posts. However, this will require each post to be written to many lists, which will affect capacity, but I’m hoping that because it can occur in an API workflow that it won’t slow down the user experience.
I believe I will try the new approach, even though it goes against @josh’s recommendation and see how the performance compares. I wish there was an easier way to determine bubble performance prior to implementation.
Thanks!
Ned