# Comparing SSD performance based on "config recipe"

**URL:** <https://discuss.aerospike.com/t/comparing-ssd-performance-based-on-config-recipe/1758>\
**Category:** Aerospike Server Benchmarks\
**Created:** [September 5, 2015, 1:56am UTC](https://discuss.aerospike.com/t/comparing-ssd-performance-based-on-config-recipe/1758 "2015-09-05T01:56:33Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![dc12078](https://avatars.discourse-cdn.com/v4/letter/d/9de053/32.png) [@dc12078](https://discuss.aerospike.com/u/dc12078)\
**Post date:** [September 5, 2015, 1:56am UTC](https://discuss.aerospike.com/t/comparing-ssd-performance-based-on-config-recipe/1758/1 "2015-09-05T01:56:33Z")

</div>

The configuration recipe’s in the [Storage Engine Configuration Recipes](http://www.aerospike.com/docs/operations/configure/namespace/storage/) documentation has been quite enlightening, but I’m still left with some confusion.

Has anyone done a comparison of “Recipe for an SSD Storage Engine” vs. HDD Storage engine WITHOUT data in memory?  
Given the same exact disks, I would like to get the flexibility of specifying files instead of raw devices. I take it aerospike needs to take a completely different approach to writing and defragging files.

---

<div class="post-metadata">

**Author:** ![sunil](https://avatars.discourse-cdn.com/v4/letter/s/5fc32e/32.png) [@sunil](https://discuss.aerospike.com/u/sunil)\
**Post date:** [September 11, 2015, 5:52pm UTC](https://discuss.aerospike.com/t/comparing-ssd-performance-based-on-config-recipe/1758/2 "2015-09-11T17:52:48Z")

</div>

Aerospike’s storage engine is not meant for “HDD without data in memory”. We liberally do random reads. HDDs will not perform well for such a work load. The latencies will be high. There will not be any correctness issues.

You already have the flexibility of specifying files on raw devices. Aerospike can work with filesystem without any issues. We just treat it as a binary file and use the same storage layer logic (because the expectation is that the files will be on SSDs). We have customers in production who create ext3/ext4 filesystem on top of SSDs. The primary reason is to logically manage the device by moving/deleting the files.