Hi everyone, Is there a limit on how many indexes a collection in typesense can have? We are working on adding multiple locale support to our app, and I was wondering what the better approach is - having a collection per locale, or having multiple fields per locale in the same collection. With the second approach, I am concerned that we might have too many indexes in the collection. I am trying to understand at what point is it worth it to have a separate collection. Thanks!

Separate collection will lead to duplication of data times your language support. Not only that, changes to documents will have to be synced throughout the collections, so many writes as well. You could search on language specific fields conditionally, based on the user's choice e.g if they're on English search

q:desc_en

Also, as a follow up does typesense have coalesce kind of support? For example if I don't have a translation for a particular field, use the base field for filtering instead?

There's no limit on collection fields, but, if you have multiple fields changing based on language locale, and only a small subset of metadata not meant to be searched by, you could create a separate collection for each locale. Have a metadata collection that references one of each locale specific collections

Thanks, I was thinking more along terms of missing localisations as well. Maybe only few of the products are localised. For the rest of the products we should use the default data. In every approach that I can see, we have to duplicate the data of all the other products into this new collection as well, even if there's just a few products that have been translated. That's the applicable level logic right? I am trying to see if there's a less wasteful way of doing it

Keeping it all consolidated into one collection would be the easiest choice. You could add a field specifying whether your product has been localized or not, and do a multisearch on that. For example, filter by localized, and query the localized field, and have a separate search that finds the un-localized ones and query by the default field

That's a cool idea, it works with filtering but it doesn't work for aggregate queries like faceting. For faceting we would need the field to be localised in all documents or consider a non localised field.

Yeah, that would most probably be needed