# Hashstore Migration Guide

**URL:** <https://forum.storj.io/t/hashstore-migration-guide/30658>\
**Category:** getting started\
**Tags:** hashstore\
**Created:** [September 1, 2025, 11:10am UTC](https://forum.storj.io/t/hashstore-migration-guide/30658 "2025-09-01T11:10:57Z")\
**Posts on this page:** 1\
**Showing post:** 61

<div class="post-metadata">

**Author:** ![Alexey](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/alexey/32/41_2.png) [@Alexey](https://forum.storj.io/u/Alexey)\
**Post date:** [September 28, 2025, 10:24am UTC](https://forum.storj.io/t/hashstore-migration-guide/30658/61 "2025-09-28T10:24:02Z")

</div>

> [@AiS1972](#):
>
> Если перенос таблиц хешей даст моей системе хотя бы немного меньше двигать головками блинов, я бы хотел перенести работу с таблицами на ssd.

Не даст, не тратьте время. Для глобальной сети эти мс пока что не имеют никакого значения, но увеличивают количество точек отказа. Если есть RAM, рисковать потерей узла разделением метаданных и данных не имеет никакого смысла, особенно с учётом, что у вас даже не raspi 2, даже не чихнёт. Хотя, если Windows, у вас будут проблемы до следующей версии, но только если у вас больше 3 узлов на сервер. Это не связано с типом (memtable/non memtable), а с тем, что Windows не лучшая ОС для сервера.  
См. [Windows GUI node consume big amount of virtual memory](https://forum.storj.io/t/windows-gui-node-consume-big-amount-of-virtual-memory/30742)

Вы можете сделать узел немного быстрее (если у вас действительно упирается в диск), если будете использовать tiered storage. Т.е. SSD как “отстойник” для горячих данных, прежде, чем они отправятся на HDD.

FYI: Текущий максимум для SATA III 6 Gbps.

---

_[View the full topic](https://forum.storj.io/t/hashstore-migration-guide/30658)._