One more dumb question: Imagine 768GB and 96 vCPUs won't be enough one day, am I screwed and have to leave? or are there still ways to scale?

We are planning to expand the amount of RAM capacity available in the medium term. Until then, you can still do application-side sharding. You'd spin up multiple Typesense Cloud clusters and for eg: store UserIDs 1-10M in the first cluster, 10M-20M in the 2nd cluster and so on (to fill up each cluster). On your application-side depending on the user-id, you'd connect to the appropriate cluster to fetch the data.

Ahhh thanks!! Differently said: E.g I have a cooking app with Recipes. I would store all recipes that start with an "A" on one Cluster, all that start with a "B" in one Cluster, and so on until Z , right? (of course I would need TONS of recipes to do that)

You'd typically shard by numeric values like IDs, but yeah you could do this as well in the example you described, especially if there are no fields like UserID or CompanyID to shard the data by.

If I shard it with IDs, how does the client actually know which Cluster He should query? Or is he querying all 3 at once since all 3 could contain results he could need?

You'd maintain a mapping of which ID ranges are stored on which cluster (hostname) and when initializing the client, you'd determine which user/company/entity's data you want to query and swap out the hostname of the cluster to use, based on the EntityID to Cluster mapping you have