Search Speed - Is this normal?

thethinklab.au · 2025-03-09T05:14:11.861Z

Manually in DB…

nocodeventure · 2025-03-09T10:29:23.870Z

Filtering occurs after records are fetched, which could cause browser crashes when processing around 15,000 records. Could you adjust your query to avoid client-side filtering?

Just add a search column to the table to combine whatever you want to search for in one single field

Search column example “AT 2607 Mawson $2500”

thethinklab.au · 2025-03-09T10:41:50.855Z

@nocodeventure

I have no filters, I am already searching on a field that combines postcode and suburb:

“Combined_suburb_postcode” e.g. value “9000 Sydney”

How do I move the search to the backend?

nocodeventure · 2025-03-09T10:50:01.771Z

You mentioned 1. Normal “Do A Search” filtered by Input’s Value = ~30 Secs

Can you do this without using filtered by?

thethinklab.au · 2025-03-09T11:02:19.708Z

Sorry this was with it directly in the do a search (combined_postcode_suburb = input’s value)

I wasn’t actually doing :filtered by

BrianHenderson · 2025-03-09T12:48:54.884Z

nocodeventure:

Just add a search column to the table to combine whatever you want to search for in one single field

This is exactly what I do. I use the normal Bubble searchbox element (not a plugin, I think that’s what OP’s problem is, I’ve never gotten plugin searchboxes to play nice with large datasets) and I have a field called “Search Combo” that’s a text value of all the different fields one might want to search for. For example, for a customer list, the Search Combo would be “Name, Phone, Company Name”.

ahmed.elkaffas · 2025-03-09T12:48:55.290Z

“Search & Autocorrect” won’t be suitable for 15,000 records. it should perform well if your records are up to 300~400 records, but more than that it won’t be performant.
Second, about the WU usage spike, that’s normal compared to your traditional usage over time, so if you are never using the application and once you made 331 WU then you will receive a notification of the spike just as a heads up.

In your case, you can use Bubble’s native search which might show filtered results in 1~2 seconds. If you’re seeking a better performance, then you can go for Algolia.

boston85719 · 2025-03-09T15:27:40.737Z

thethinklab.au:

(combined_postcode_suburb = input’s value)

change it to a setup where you are eliminating potentials for capitalization to be a problem…you would have to do this by creating a group, make it type text and datasource is the input elements value:lowercase (this is because your also need to make your database entries lowercase as well dynamically and we are not able to through dynamic expressions when comparing two sources values against each other to use the lowercase operator on the second value in the comparison expression). It also has to be done because Bubble contains comparative is case sensitive

… contains

This operation tests if the first entry contains the argument. The substring of text should match the sequence of characters of the first entry exactly, including case. This search respects the order of the words in the entry.

For example, searching for ‘cat’, ‘hat’, ‘cat in’, ‘cat in the’, ‘in the hat’, ‘at in’, or ‘cat in the hat’ would all return the phrase ‘the cat in the hat’.

However, searching for ‘cat the hat’, ‘cat hat’, or ‘Cat’ would not return ‘the cat in the hat’. This search is useful for returning exact matches for partial words, like searching ‘pepp’ and returning ‘peppers’.

manual.bubble.io

Operators and comparisons | Bubble Docs

Aggregating, manipulating and comparing data.

Make your search with built in constraint be combined_postcode_suburb:lowercase contains group inputs value lowercase.

Make your Repeating Group set to display at max maybe 10 items and likely for design reasons, it should be limited to 5 if you don’t want the ugly scrollbar and a clean ‘dropdown’ like selector made from groupfocus and repeating group.

One thing that might also need to be done based on the ordering of items in the value to compare as in the example from manual of cat in the hat…you may need to split your data field (since it is zip plus other values as single string)…or maybe structure the single string properly so it is 9000|suburb_name|other_details…which causes it to be treated as single word and then should remove the issue of contains operator being order driven.

Lastly, if you are still stuck on this in two weeks, reach out to me directly as I’d be interested to test my own tools against the issue.

DjackLowCode · 2025-03-09T18:47:00.317Z

Bubble can definitely handle queries on this number of records quickly in normal ‘Do a search’ on native elements, if not I’d raise a bug report.

Also, ‘Do a search:filtered’ and ‘Do a search:merged with Do a search’ should both happen server side unless using ‘advanced’ filters.

nocodeventure · 2025-03-09T23:16:02.905Z

The results are fetched from the database and then a filter is applied on the front end. Correct us if we’re mistaken.

adamhholmes · 2025-03-09T23:33:31.177Z

Do a search: filtered is (in most cases) no different from applying the constraints on the search - i.e. it’s done directly on the database query.

It seems to be a common misconception around here that using the :filtered operator applies filtering client-side - that’s not the case (at least, not usually).

It is the case if the filter operator uses an advanced filter.

DjackLowCode · 2025-03-09T23:35:06.327Z

@adamhholmes is correct. Check out the manual entry: Client-side and server-side processing | Bubble Docs

This can be useful when you want to allow for ‘ignore empty constraints’ on a search when you really want a few to not be ignored (e.g. =current user)

DjackLowCode · 2025-03-10T01:00:53.986Z

Hey @thethinklab.au , to give you a bit more confidence, here’s a similar dataset searching over 51,000 records with native search:

Screenshot 2025-03-10 135829726×379 16.1 KB

Search

mitchbaylis · 2025-03-10T01:55:50.698Z

try algolia

bubbles internal search is fine but very limited (not fuzzy etc) and slow (compared to algolia)

thethinklab.au · 2025-03-10T03:28:31.313Z

@DjackLowCode
Really odd… I’ve got no idea what I’m doing wrong but I can’t get speeds like yours using any solution (Native vs Algolia vs QuickFind).

Here is a Loom where I demo Search + Results on both an Algolia and a Native solution. They’re both similar speeds (~2 second lag), but Aloglia has better matching: Isaacapp - 10 March 2025 | Loom

Native settings:

image1416×670 71.5 KB

@mitchbaylis
RE: Algolia:

Does anyone know any more things I can try to speed up Algolia results?
Does anyone know why I’d be getting ‘2267_WANGI_WANGI_NSW’ as the first result on a search for ‘2607’???

image724×832 32.7 KB

Settings:

image690×1444 75.2 KB

nocodeventure · 2025-03-10T04:03:51.270Z

I believe it used to be different looking at the network tab but we’ll look into this more on our end. Thanks for the feedback!

boston85719 · 2025-03-10T04:36:58.952Z

Inputs or postcodes likely the issue…key issue being an OR operator, unless that is just your source name

DjackLowCode · 2025-03-10T04:53:54.357Z

@thethinklab.au If you want some silly speeds you can use a ‘instant text’ plugin - this is basically running the search call for every character entered in the input.

Natively, Bubble won’t register the input until you finish typing (applies to both constraints on Algolia too).

Will consume more of whatever service your using (Bubble or external). I would recommend just having a loading state.

Search

Screenshot 2025-03-10 1346361521×235 18.3 KB

thethinklab.au · 2025-03-10T05:02:13.710Z

It’s just the source name:

Screenshot 2025-03-10 at 3.53.07 pm694×514 36.5 KB

thethinklab.au · 2025-03-10T05:34:40.804Z

Oh wow…

LiveText + Algolia is giving me near-instant results! Thanks @DjackLowCode

For Algolia, does anyone know how I can get the following example so ‘2071_EAST_KILLARA_NSW’ and below are excluded?

image870×1018 39.4 KB

image934×812 65 KB