Dear community,
a quick question: I need space for my indices. Is local storage the only best option for hot data or is SAN a valid option too?
I am running a 8.17.x, single node, productive, dockerized all-in-one solution (redis, logstash, fleet, elasticsearch, kibana) for syslog data coming from switches, routers and so on AND it is running on an ESX VM. Due to lack of money the data storage so far are spinning disks.
Thanks for any insights and kind regards!
S.M.
There are some advices at Tune for indexing speed | Elastic Docs
Directly-attached (local) storage generally performs better than remote storage because it is simpler to configure well and avoids communications overheads.
I understand the budget constraint but please be aware that running all those services on the same hardware as Elasticsearch might not give you the best experience...
Not the best experience, not least because some component, maybe elasticsearch, needs so many IOps that other components get a bit starved. We once had experience like this when mongo and elasticsearch were fighting for IOps, not even on same servers, and it all sort of looks ok in testing until real load arrives. So at very least try to do realistic load testing.
Pragmatically you might be forced to try, if so make sure the stakeholders know you are going against best practise.
And last, decent fast storage is so cheap in 2025, so much cheaper than decent staff, that I would personally find that budget choice a bit alarming.
...it was not my choice actually. I worked for an internation retail company and managed big elk cluster - all was running on ssds. In my new job I inherited this situation. 
They guy who built this left the company.
1 Like
We’ve all been there!
Good luck!