# SAN a valid option for an ELK stack? **URL:** \ **Category:** Elasticsearch\ **Created:** [June 5, 2025, 5:01am UTC](https://discuss.elastic.co/t/san-a-valid-option-for-an-elk-stack/378888 "2025-06-05T05:01:39Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![smm](https://avatars.discourse-cdn.com/v4/letter/s/bb73d2/32.png) [@smm](https://discuss.elastic.co/u/smm)\ **Post date:** [June 5, 2025, 5:01am UTC](https://discuss.elastic.co/t/san-a-valid-option-for-an-elk-stack/378888/1 "2025-06-05T05:01:39Z")
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. ---
**Author:** ![dadoonet](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/dadoonet/32/137187_2.png) [@dadoonet](https://discuss.elastic.co/u/dadoonet)\ **Post date:** [June 5, 2025, 7:28am UTC](https://discuss.elastic.co/t/san-a-valid-option-for-an-elk-stack/378888/2 "2025-06-05T07:28:16Z")
There are some advices at [Tune for indexing speed | Elastic Docs](https://www.elastic.co/docs/deploy-manage/production-guidance/optimize-performance/indexing-speed#_local_vs_remote_storage) > Directly-attached (local) storage generally performs better than remote storage because it is simpler to configure well and avoids communications overheads. > [@smm](#): > > I am running a 8.17.x, single node, productive, dockerized all-in-one solution (redis, logstash, fleet, elasticsearch, kibana) 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... ---
**Author:** ![RainTown](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/raintown/32/140206_2.png) [@RainTown](https://discuss.elastic.co/u/RainTown)\ **Post date:** [June 5, 2025, 8:39am UTC](https://discuss.elastic.co/t/san-a-valid-option-for-an-elk-stack/378888/3 "2025-06-05T08:39:50Z")
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. ---
**Author:** ![smm](https://avatars.discourse-cdn.com/v4/letter/s/bb73d2/32.png) [@smm](https://discuss.elastic.co/u/smm)\ **Post date:** [June 5, 2025, 8:42am UTC](https://discuss.elastic.co/t/san-a-valid-option-for-an-elk-stack/378888/4 "2025-06-05T08:42:06Z")
...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. ---
**Author:** ![RainTown](https://sea2.discourse-cdn.com/elastic/user_avatar/discuss.elastic.co/raintown/32/140206_2.png) [@RainTown](https://discuss.elastic.co/u/RainTown)\ **Post date:** [June 5, 2025, 8:44am UTC](https://discuss.elastic.co/t/san-a-valid-option-for-an-elk-stack/378888/5 "2025-06-05T08:44:27Z")
We’ve all been there! Good luck!