How are people implementing site-wide Search?

How are people currently addressing side-wide search on their sites so that it is:

  • Highly Performant
  • Capable of Searching Multiple Tables / Displaying multiples types of things
  • Allows for user-friendly search characteristics such as fuzzy-search and case insensitivity
  • Allows for rich auto-suggest user interfaces including the display or small images and multiple fields of text from each thing

These videos by @romanmg should answer most of your questions.

For fuzzy-search, check out this Plugin:

Hope it helps.

Thanks for the reply. I’m familiar with each of these and use a variation of each within our app but none of these approaches provide me with a solution that really meets all of my requirements for a good site-wide search capability.

Using repeating groups for auto-suggest has performance/lag challenges, especially when searching a large database and when searching across multiple tables. It does seem like the most viable solution right now, though, because you can set different RGs for each table, customize the UI of the auto-suggest. But, I’m hoping there’s an even better solution, especially on the performance side.

The Search & Autocorrect plugin is also great (and we use it elsewhere), but it doesn’t work well in this instance because it requires you to load each thing to the client before you search them. This works very well for small datasets but isn’t viable for large datasets, including site-wide search.

Are there other solutions people are using?


Mmm, I wasn’t aware that these have performance issues with large data sets. In that case i’m stuck with the same problem as you. Hopefully someone else has a solution to this. I don’t know if this solution by Levon will increase the performance of site wide search. It states its for page load speed but maybe it can speed up performance/lag. Just thought i’d mention it. Hopefully someone can provide a solution to this.

Yeah, thanks for the suggestions. I’m not sure whether the slowness is primarily from having more rows in the table or more fields on the table (since Bubble currently seems to load all of the fields to the client whenever it loads a thing in a repeating group).

We implemented Cloudflare. Didn’t see a material change in performance on our site, but still seems to be a good tool to have implemented.


Cloudflare is just a CDN, it won’t help with improving the querying of data on the server.

This article is fairly detailed on options for full text search although I’m not really sure if there are any quick fixes.

1 Like

@Kfawcett, what are the best solutions you’ve seen / heard other Bubblers using? I can’t help but think I’m missing something since this is such a core capability for most sites and I don’t think we have a great solution yet and I don’t hear a ton about it.

I’m guessing RG’s are workable, but I’m sure most users will notice that they’re slow. Additionally, it’s particularly problematic for first time visitors to our site since they don’t know it’s slow so they may think it’s broken and give up before getting a result. Clearly, that’ll only happen a small fraction of the time, but it’s not the impression I want to leave people with.

Of course, we could build something custom as a solution. And, we’re considering it. But, that’s very costly and not our primary expertise. So, hoping there are some Bubblers that are smarter than I am who’ve come up with a clever solution.

1 Like

I’m in the same boat. Love the Search & AutoCorrect plugin but it definitely has noticeable time lags. I’m experimenting with two approaches and still not sure which is best because I don’t have vast quantities of data.

  1. I simply created additional fields in each table that concatenates a few fields into one e.g. vehicle Year + Make + Model. This search is fast because it’s bubble’s own search but it means I also have to add concatenated fields from other tables into this table so it’s really messy. It’s not really a site search more an expanded Type search.

  2. My preferred option, and it’s messy too, is to create a new table called Search Concatenation. Then I have fields for each Data Type so I can link to the records on another table (e.g. Customer, Vehicle, Worksheet…). And I have fields for each concatenation from the other Data Type tables (e.g. Concat.Base.Vehicle =" Year + Make + Model" and Concat.Cust.Vehicle = “Reg Plate + VIN”). This approach is fast and you can use conditions to display data in a single RG cell depending on the Data Type or you can have multiple RGs, one for each data type. When I do the latter, I limit the results to the first 3 matches in each RG, which is fast, and I provide an icon to expand (like full-screen only this is full list). When a user taps the expand icon then a full-page RG from the original Data Type is loaded. It’s not great but it seems to work ok.

I don’t know the answer myself but I pinged @NigelG recently and I’m hoping he’ll pitch in here because he seems to be knowledgeable on data performance issues.

And fingers crossed bubble decide to upgrade their search soon. I wish they had a Trello board like other companies so we could clearly see their roadmap and could upvote cards. Any news on search @emmanuel


I also tried your approach #1 but it’s very complicated to maintain.

Haven’t tried it but I think using a service like Algolia would be the best option. Getting search results is very quick and showing them as text in a repeating group is relatively light-weight for the browser.

A nice introduction can be found here:

Interesting link @soeren but I have enough trouble convincing users that their data will be secure on bubble without sending out to another service. And, it would be a shame to go to the bother of doing that (looks like a lot of work), when bubble’s roadmap (below) indicates that they are working on the Search box (albeit the last on the list). Unfortunately, there are no indicative dates.

1 Like

@sridharan.s You may have answered this in another post, for my curiosity, what plan are you on?, we’re on a dedicated plan.

@NigelG has chimed in on similar topics in the past. As much as anything, I’m curious how people are getting this done today. Is it mostly using RGs + replicating data in a new table or as a list of things so that it’s more performant?

Do people have any performant solutions for searching fields in different tables (e.g., Searching articles based on the title [articles table] and name of the author [user’s table]?

In time, Bubblers will be able to use more robust approaches as Bubble and the plugin community add new capabilities. Search is a hard technology problem. I’m looking forward to someone taking this on. Happy to chip in $ if that ever helps.

Surely, there are a lot of custom code solutions each of us could implement to supplement our apps but as Bubble has taught us, it’s just so much easier when there’s one high optimized implementation that all of us can use without coding it ourselves. #TruelyThankful


i have a problem when using search and autocorrect plug in where it cant do a search for fields that is in number format. how do i overcome this?

what i’m trying to say is field to search option doesn’t include field that are in number format.

With your current implementation, is there any way to load the numbers as text values and then search them that way? Just a thought.

i cant. because im using calculation workflow. is there any way to go around this?

Two ideas off the top of my head…

If you simply need to reference the text value on the page, then you can likely load the value to a custom state. If you set the custom state on the page to be type = text, then I believe it’ll turn the number into a text value.

Whereas, if you need to reference the text value from the database, then one solution would be to add another value to your table and make it equal the same number but store this field as a text field. if calculations are used, then reference the numeric value for the calculation.

that worked!!! created a new field in text format, copy result form previous workflow and add to the new field. thanks!!!

1 Like