# Can Aerospike be used to store large values? **URL:** \ **Category:** Tuning\ **Tags:** ldt\ **Created:** [October 7, 2015, 7:50pm UTC](https://discuss.aerospike.com/t/can-aerospike-be-used-to-store-large-values/1974 "2015-10-07T19:50:54Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![Vineet\_Sharma](https://avatars.discourse-cdn.com/v4/letter/v/a183cd/32.png) [@Vineet\_Sharma](https://discuss.aerospike.com/u/Vineet_Sharma)\ **Post date:** [October 7, 2015, 7:50pm UTC](https://discuss.aerospike.com/t/can-aerospike-be-used-to-store-large-values/1974/1 "2015-10-07T19:50:54Z")
we have a requirement where we would need to store large values of type String (up to 3MB) in a key value store. While we have memcached setup right now, we would want to experiment with aerospike given its performance benchmarks (although with values within a few KBs). I read in the aerospike config about the write-block-size that cannot go beyond 1MB. Does that mean I cannot store value pairs more than 1MB? Or if I can go beyond 1MB, then what should be the acceptable performance benchmarks considering 50/50 read-write). ---
**Author:** ![kporter](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.aerospike.com/kporter/32/515_2.png) [@kporter](https://discuss.aerospike.com/u/kporter)\ **Post date:** [October 8, 2015, 6:28pm UTC](https://discuss.aerospike.com/t/can-aerospike-be-used-to-store-large-values/1974/2 "2015-10-08T18:28:23Z")
That is correct, presently records are limited to the **write-block-size**. For larger objects Aerospike has [Large Lists](http://www.aerospike.com/docs/guide/llist.html), but again each list element will be limited to the **write-block-size**. > [@Vineet\_Sharma](#): > > if I can go beyond 1MB, then what should be the acceptable performance benchmarks considering 50/50 read-write). I do not know the precise answer to this question but the LDT operations are currently significantly slower than normal operations. ---
**Author:** ![Vineet\_Sharma](https://avatars.discourse-cdn.com/v4/letter/v/a183cd/32.png) [@Vineet\_Sharma](https://discuss.aerospike.com/u/Vineet_Sharma)\ **Post date:** [October 8, 2015, 6:56pm UTC](https://discuss.aerospike.com/t/can-aerospike-be-used-to-store-large-values/1974/3 "2015-10-08T18:56:29Z")
@kporter Thanks for your reply. I think if we just use the storage engine as **memory** , than **write-block-size** doesn’t come into the picture and we can store large values as well. Please correct if I am wrong here. But what should be the acceptable performance benchmarks in this case if we use large values in memory. How much TPS we should expect with 2 cores r3.xlarge instance? Will it be better than memcached on the same hardware? Please advice. ---
**Author:** ![Mnemaudsyne](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.aerospike.com/mnemaudsyne/32/200_2.png) [@Mnemaudsyne](https://discuss.aerospike.com/u/Mnemaudsyne)\ **Post date:** [October 8, 2015, 10:06pm UTC](https://discuss.aerospike.com/t/can-aerospike-be-used-to-store-large-values/1974/4 "2015-10-08T22:06:35Z")
@Vineet_Sharma, We’re seeing double … the same issue was posted on Stackoverflow, [here](http://stackoverflow.com/questions/33001151/can-aerospike-be-used-to-store-large-values). We are always happy to help, but please refrain from double-posting on the forum and on Stackoverflow … especially on the same day. 😕 ---
**Author:** ![kporter](https://sea1.discourse-cdn.com/flex019/user_avatar/discuss.aerospike.com/kporter/32/515_2.png) [@kporter](https://discuss.aerospike.com/u/kporter)\ **Post date:** [October 8, 2015, 11:11pm UTC](https://discuss.aerospike.com/t/can-aerospike-be-used-to-store-large-values/1974/5 "2015-10-08T23:11:50Z")
Correct, memory only doesn’t share the write-block-size limitation. ---
**Author:** ![Vineet\_Sharma](https://avatars.discourse-cdn.com/v4/letter/v/a183cd/32.png) [@Vineet\_Sharma](https://discuss.aerospike.com/u/Vineet_Sharma)\ **Post date:** [October 9, 2015, 5:50am UTC](https://discuss.aerospike.com/t/can-aerospike-be-used-to-store-large-values/1974/6 "2015-10-09T05:50:36Z")
Will keep in mind next time. Sorry for the inconvenience.