FAQ - What is the max size of a records primary key in Aeropsike


FAQ - What is the max size of a records primary key in Aeropsike.


Aerospike can handle strings or numeric values as its primary key. The original key will be hashed (RipeMD160) to generate a unique record identifier known as the digest.(See http://www.aerospike.com/docs/architecture/data-distribution.html)


The original key is not stored in the database by default. Aeropsike will only store the 20 bytes digest hash of the original key as well as the set name (if specified). This would imply that the original key could be of any size that the Client can handle. There are however some limit. Let’s first look at the Java client as an example.

The java client limits the key to slightly under 8 KB. Here is the reason:

  • The computeDigest() method is used to create a 20 byte hash digest from a set name, user key type, and variable sized user key. This 20 byte digest will be sent to the server. The user key will not be sent to the server by default thus implying there is no limit.

  • The computeDigest() method uses a temporary thread local buffer initially sized at 8 KB to assemble bytes for use with the RipeMD160 hashing method.

  • This temporary buffer size is the defacto limit in the java client.

For C based client: (python, php, C)

No limit defined. Actual limit is the size of the stack at around 10MB.

The stack size can be determined by running:

ulimit -s


ulimit -a

[vagrant@localhost ~]$ ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 7424
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 10240
cpu time               (seconds, -t) unlimited
max user processes              (-u) 1024
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited
[vagrant@localhost ~]$ ulimit -s


  • It would have of course been possible to add code to estimate the size and dynamically create a buffer in the Java client thus allowing keys of any size, but this would impact performance. In general, 8KB should be a very reasonable limit for the vast majority of use cases.


Max userKey size client limit