Multiselect from 250k options

Hi, I’m trying to use multiselect with 250k options and this completely breaks streamlit, I’m not able to pick anything, is there any way to make this more optimal?


Wow that is a lot of options to put in a multiselect!! Will look into why this is breaking, but would like to figure out a way to do what you want without you having to put so many options into the multiselect. Can you tell me a bit more about what you’re trying to do and why? Hopefully we can find a better option for you!

Hey @kmiklos, @Amanda_Kelly

Agreed that it’s a lot of options for a Multiselect and we should look at alternatives for the moment.

As an FYI, we could potentially implement support for large options list, via

However it doesn’t seem to handle lists larger than 100k efficiently.

Hi @Amanda_Kelly, @Jonathan_Rhone, thanks for getting back to me so fast! Basically I was trying to use it as a tool to select all the possible medical conditions (from my database) that the user can have. I wanted to support autocomplete and restrict what can be typed in there. I could use a text area instead but then I don’t have the fancy features.

Are you retrieving all possible options from your database? I agree that the multiselect search functionality is really nice, but for these many options it may not be feasible. You have already pointed out at using the text area for the input and it could be tied to some search logic and an output box… Every time a user enters a value automatically it triggers a search. In this way, you could also offload the search to SQL saving you some compute.

input = st.text_input(...)
if input is not None:
   output = search(input)

It would be really cool triggering a re-run while you type in the text area, but it may be too costly and we don’t support it for now (maybe an idea for a feature request).


As a short-term solution you could also have a filter ahead of time to filter down by category or something so that they are not selecting from 250k options. It’s an annoying extra step, but should work if you have obvious categories.

Thanks @monchier and @Amanda_Kelly, yes probably I will go with the text_input for now, I’m doing some filtering but unfortunately there are no obvious categories, and it would probably slow down the workflow for the user.