So what you are telling me that the cold node has no better compression over data so if i have an index of lets say 500GB on the hot node, it will remain the same 500GB on the cold node?
Correct. Compression ratio doesn't change between lifecycle steps, but the memory-to-disk ratio does, meaning you need less memory (fewer nodes) to serve the same amount of data. Also, cold nodes generally use slower, less expensive disk meaning the cost (not the size) for data on a cold node is less than it would be on hot or warm.
I probably was giving you a deeper answer than you wanted with my first response. I was saying that Elasticsearch does not ship with different types of data nodes. What you do (and what we do in Elastic Cloud) is use different types of hardware in a single cluster, labeling the faster hardware "hot", the slower hardware "slow", and then use ILM to do make the indices move between them and do other optimizations at the same time (like a forced merge)
And if i have old indices that has not been in to an ILM then how will i be able to move them to cold node.
If you all you want to do is have older data with a higher compression ratio than newer data, you'd need to reindex data from your "hot" indices to your "cold" ones, where the cold indices have been configured with
If you've setup shard allocation filtering, then you can move indices from "hot" to "cold" by changing the index routing settings on the hot index when ready for them to move. Curator does these API calls for you, but it isn't required.