How Aerospike Delivers Millisecond Latency on TB‑Scale Data

Why Aerospike?

Aerospike is a distributed NoSQL database designed for TB‑scale data with millisecond‑level query latency. It targets workloads where low latency is critical, such as real‑time fraud detection, bidding, and user profiling.

Comparison with other NoSQL databases

Redis provides sub‑millisecond latency but does not scale beyond a few terabytes. Cassandra can store petabytes but incurs higher latency due to its write‑heavy architecture. Aerospike combines sub‑millisecond latency, high throughput, and linear total cost of ownership as data grows.

Hybrid storage architecture

Aerospike automatically tiers data across three storage layers:

DRAM (full‑memory)

Persistent Memory (PMEM, e.g., Intel Optane DC)

Flash (NVMe/SSD/HDD)

Data moves between tiers based on access patterns, keeping hot data in faster media while storing cold data cost‑effectively. The hierarchy follows DRAM → PMEM → SSD → HDD, with latency increasing at each step.

Supported storage types

DRAM

PMEM

NVMe or SSD

Traditional HDD

Model implementations

DRAM (full‑memory) model

Data resides entirely in RAM. Aerospike uses jemalloc to allocate memory pools with low fragmentation. Multiple DRAM replicas provide high reliability; if a node fails, its partitions are re‑sharded to other nodes and replicas are rebuilt automatically. Randomized distributed hashing ensures a low probability of data loss (e.g., with 10 nodes and a replication factor of 2, simultaneous loss of two nodes affects only ~2% of data).

PMEM (full‑persistent‑memory) model

Since Aerospike Enterprise Edition 4.8, both primary indexes and record data can be stored on Intel Optane DC Persistent Memory. Each PMEM module can hold up to 512 GB, allowing a single server to reach TB‑scale memory capacity at roughly half the price of DRAM while offering 1‑2 orders of magnitude lower latency than SSDs.

Flash (full‑flash) model

In the flash model, Aerospike writes data in large blocks to reduce wear, bypasses the OS file system to access SSDs as raw block devices, and employs an optimized distributed hash algorithm for balanced placement. A background fragmentation‑reclamation process recycles low‑usage blocks.

Write path in the flash model

Client acquires a lock to avoid write conflicts.

Data is written to an in‑memory buffer.

If the buffer fills, the data is queued to disk.

All replicas are updated; the result is returned to the client.

During network partitions, conflicting writes are resolved on the next read and synchronized across the cluster.

Flash‑specific optimizations

Writes are performed in large blocks to minimize wear.

SSD is accessed as a raw block device, bypassing the file system to eliminate extra I/O overhead.

An optimized distributed hash algorithm ensures even data distribution across nodes and flash devices.

A fragmentation‑reclamation daemon tracks block usage and reclaims under‑utilized blocks.

Ecosystem integration

Aerospike can ingest data from Kafka, MySQL, PostgreSQL, and other sources. Queries can be executed via Spark Connect or Presto Connect, and data can be exported to data warehouses for further analysis.

Typical use cases

Financial services – real‑time fraud detection requiring sub‑second decision making.

Advertising – real‑time bidding with millisecond response times and TB‑scale data.

Telecommunications – user profiling and balance queries at massive scale.

IoT, e‑commerce, smart manufacturing, online gaming – any scenario needing TB‑level data with millisecond latency.

All these scenarios share the requirement of handling multi‑terabyte datasets while keeping operation latency within a few milliseconds.