Daisy Chain Filtering and Search Constraints Best Practices

I’ve used to take on faith that as soon as you apply :filter operator - everything is filtered client-side. And this was the reason:

An underlying principle is that if a filter (or sort) can be done “on the database”, it will be faster than a filter (or sort) that Bubble has to do after retrieving an initial set of data from the database. Which filters are done on the database vs. not? Filters which show up in the Search palette (the additional sidebar which slides out when you click “Do a search for”) are done on the database and are thus are generally fast. Filters which are applied with :filter are generally “advanced” filters that are generally slower.
[bubble manual]

But while playing with WU consumption in one of my apps I’ve noticed zero difference between using basic [=fields of the data type] constraints in Do a search expression and in :filtered operator. I’ve dived into Chrome DevTools and discovered that :filtered operator returns filtered items from the DB (again, if I was using basic constraints).

Not wanna copy the whole thread here, so you can check some info I got from Bubble support about client/server filtering here:

May be one day I’ll have enough time and enthusiasm to sit down and write a detailed summary topic (based on the results of communication with Bubble support and my experience) about :filtered being executed server/client side with examples…

p.s.

That’s true. At least they should understand what they are doing and how it works under the hood instead of following some advices blindly.