Hi,
Just wanted to know what the performance/latency hit of changing a tenancy status is - if any benchmarks are available or if anyone has any anecdotal experience.
For example, say a user logs in and this triggers making their tenant hot; how much time does this operation take and what factors impact it (I assume the number of items in the tenant and size of vectors is a factor, is that correct and are there other factors to consider?)
Thanks 
Hi @Kieran-who,
I hope you had a great weekend! Happy Tuesday 
Absolutely excellent point! so Deactivating from hot to cold state takes mere seconds (even could feel instant). Activating from cold (persisted on disk) to hot (loaded into memory) can be relatively quick, approximately less than half a minute to load 20 GB from disk to memory. I based this calculation on an object size of 20 KB, with a tenant consisting of 5 million objects totaling around 95.37 GB. Considering multi-setup nodes with replication (can play part here too), the factors influencing the switch speed include disk I/O speed, network latency, and memory allocation efficiency. The primary concern is ensuring that memory and processing demands of active (hot) tenants do not exceed resource you have.
Even with above being âfair assumptionâ! I have come across an experiment in a real live production where switching tenant between hot and cold with a tenant holding about 3 million objects. The switch from cold to hot gave impression of instant 
I hope this help!
Have a lovely day!
Awesome just what I was after, thanks for the quick response.
I wonder if youâve come across any production scenarios where a large number of relatively small tenants are being made âhotâ at the same time and whether this has resulted in any problems.
The scenario would be something like a user would search across items X and each item X has 100-5000 related items Y. Each item Xâs items Y are in a dedicated item X tenant that is kept cold unless item X is returned in the search.
The issue is that all items X need to be searchable at any time but items Y do not and they would take up a lot of resources if always kept in memory.
Hope that makes some sort of sense 
Iâve not come across any complain from that process. Definitely, this scenario shouldnât result in any issues, as Weaviateâs multi-tenancy feature is designed to handle high loads efficiently. Activating multiple tenants simultaneously should be managed seamlessly.
Your description makes perfect sense and aligns well with the intended use of multi-tenancy. Keeping tenants cold while getting them into hot state as needed is a smart approach, especially we both know that memory is very expensive 
.
In practice, similar factors will influence performance, such as latency, resource efficiency, and query optimization. Itâs crucial to ensure queries are well-optimized.
Overall, I wouldnât worry too much. The architecture should support your use case effectively.
