Internal ID vs Human-readable Names in Typesense

I would like some help clarifying how and when to use internal ID values instead of human-readable names with Typesense.

For example, I have a collection with a "customer name" field.
I can store customer names as int identifiers and then remap human-readable customer names on the client.

Pros:
• I can use different labels for different user locales (translation support) without storing different values for different locales in the collection (so less memory consumption)
Cons:
• It is impossible to search within facet values if this field is a facet. Since the number of facet values can be quite high, and they are paged, it is not possible to do a client-side search.
Is there any guidance or best practices on that?

Also, if I, for example, store the same string value in 1kk documents, does the string length affect the RAM consumption, or is it compressed internally?

In general I would recommend storing the full strings in Typesense instead of just the ID, especially if you want to use them in some search operations (eg: sorting, faceting, grouping, etc).

Repeated strings are only stored once in the in-memory index, so it "compresses" effectively.

Are there any particular benefits to this approach?

It has its own downsides:
• To translate the values, instead of doing simple value→label remapping on the client based on the current locale, we have to store values in all languages in separate fields;
• When such a value is renamed by the user, a complex synchronization logic must be implemented. E.g., a bunch of collections has a "customer" field, and if a user renames a customer, this change should be correctly propagated to all collections that use this field. If the value is stored instead of the label, no changes are required in this case (value→label remapping is done on the client dynamically).

Performance would be the main advantage. You can send requests to Typesense directly and render the full search results page with just data from Typesense instead of having an intermediate post-processing step through your backend.