Skip to main content
Aerospike Vector is now live with LangChain integrationTell me more
Loading

Server Hardware Requirements

All databases have strong reliance on the underlying hardware, however it is not always obvious what your priorities should be in selecting appropriate hardware. The following sections review hardware requirements and recommendations.

Processor​

The CPU load depends on the type of operations your application performs. Simple CRUD operations rarely stress the processor, while heavy use of atomic data type operations (such as the Map API) combined with compression and encryption at rest will demand a higher CPU load. Aerospike provides asbench to help you properly benchmark of your hardware.

Minimum Requirements​

  • One quad core processor for production deployments
  • For 64-bit x86 (Intel/AMD) processors: x64-64-v2 microarchitecture level compatibility
  • For ARM64 processors for Database 6.2 and later: ARMv8.2-A instruction set (Neoverse N1 microarchitecture) compatibility, such as AWS Graviton 2 processors

Recommendations​

  • The amount of memory you can have on your server may be determined by its processor. For bare-metal deployments, check with the manufacturer on the CPU's memory limits
  • Hyperthreading is reliable from Intel Xeon v2 (ivy bridge) chips onward. In older Xeon v1 chips (sandy bridge and older) you should rely on the physical cores and turn off hyperthreading
  • You may benefit from auto-pinning NIC queues to the CPU cores

Memory​

Indexes are stored in RAM by default, and the amount of available memory limits the number of records that can be stored on each cluster node. Aerospike Database is very memory efficient, with each record (AKA object or row) requiring only a (CPU cache line efficient) 64 bytes of memory for its metadata in the primary index. This means that each GiB of memory can index 16 million records.

  • Memory use is also affected by:
    • secondary indexes and set indexes, if they are declared
    • the post-write-cache ](/server/reference/configuration#post-write-cache), max-write-cache, XDR transaction queues and other internal buffers
  • If storing data in RAM, you must also account for the size of the data in addition to the indexes
  • If storing data on SSDs or Intel Optane persistent memory, no additional RAM is required
  • The memory needed for indexes, and optionally storage, is multiplied by the replication factor of the namespaces
  • Aerospike Database Enterprise Edition (EE) stores primary and secondary indexes in shared memory, allowing for fast restarts
  • Aerospike EE also supports storing the primary index in persistent memory or on flash (SSD), which results in a tiny memory requirement, unless secondary or set indexes are used

Minimum Requirements​

  • 4 GiB of RAM is required for production deployments
  • For development deployments, you can tune down the index-stage-size to 128MiB. This allows you to run in 1GiB of RAM or less, but limits the maximum number of records on the node

Recommendations​

  • In our testing, the specific type of memory and even speed did not significantly affect performance
  • Persistent memory performs nearly as well as RAM, at a lower cost and higher density of memory per DIMM slot, as well as being persisted on clean shutdowns

Solid-State Drives (SSDs)​

The most common hardware configuration for an Aerospike namespace is to store indexes in RAM and the data on SSDs. This Hybrid Memory architecture is one of the reasons that Aerospike Database has the best cost-performance ratio, and the ability to store very large data sets (multi terabyte and petabyte) on a significantly smaller database cluster than the competition.

  • When declaring a namespace storage to be on SSD, it is typically on a raw device, and not a file system
  • When declaring a namespace storage to be RAM, an SSD can be used to persist the data to a file or the raw device
    • Aerospike stores the data in memory and writes a copy to disk. During normal operation this data is only read to defragment the persistence file
    • If a node is taken down, the data that was stored in memory is lost. At startup, the data is read from the persistence file to reconstruct the index, and reload the data into memory. Note: this can be disabled through configuration, if you wish to repopulate the data from the other nodes instead of the persistence file.

Minimum Requirements​

  • The data storage requirement is multiplied by the replication factor of the namespace
  • Consult the capacity planning guide to determine the required amount of SSD storage space

Recommendations​

  • Partitioning flash drives (SSDs) tends to increase write performance
  • For an in-memory namespace with persistence to the file system, the recommended size of the persistence file is 4 times the amount of data stored in RAM. The large size of the file allows for efficient defragmentation of data
    • Rotational hard disks (HDDs) are not recommended for anything other than possibly the persistence file for an in-memory namespace
    • While not required, it is a good idea to put the persistence file on a different disk than the OS

Cloud and virtualized environments​

  • See the Cloud section for specifics about the different cloud and virtualized environments.