Aerospike handles 1 million writes per second with consistent sub-millisecond latency on a 3-node cluster — without the memory constraints of Redis or the JVM overhead of Cassandra. Version 7.0 ships strong consistency mode by default and significant improvements to XDR cross-datacenter replication. Here's what changed and when Aerospike beats every other option.
- Aerospike stores data directly on SSDs using its own flash-optimized storage engine — bypassing the OS page cache
- Aerospike 7.0 enables strong consistency mode by default (CP in CAP theorem terms)
- Primary indexes live entirely in RAM; secondary indexes and data live on NVMe SSDs
- Best for: ad targeting, fraud detection, session storage, and leaderboards at 100K+ ops/s
Aerospike's Storage Architecture
Hybrid Memory Storage (HMS)
Aerospike's signature feature is its Hybrid Memory Storage architecture. All primary indexes are stored in DRAM (enabling O(1) key lookups). Record data is stored on NVMe SSDs using Aerospike's own log-structured storage engine that bypasses the Linux page cache and filesystem overhead entirely.
# /etc/aerospike/aerospike.conf
namespace session {
replication-factor 2
nsup-period 120 # namespace supervisor period (seconds)
# Store data on NVMe SSD (bypasses OS page cache)
storage-engine device {
device /dev/nvme0n1
write-block-size 1M
data-in-memory false # use hybrid mode: index in RAM, data on SSD
}
# Memory for primary index (8 bytes per record)
# 1 billion records = 8GB RAM for index
memory-size 16G
}Strong Consistency in Aerospike 7.0
# Enable strong consistency (CP mode) for financial workloads
namespace transactions {
replication-factor 3
strong-consistency true # default in Aerospike 7.0
strong-consistency-allow-expunge true
storage-engine device {
device /dev/nvme0n1
commit-to-device true # sync writes to SSD before ack
}
}Aerospike Client Operations
Python Client Patterns
import aerospike
from aerospike import exception as ex
# Connect to cluster
client = aerospike.client({
'hosts': [('aerospike.internal', 3000)]
}).connect()
# Write a session record with TTL
key = ('sessions', 'user_sessions', 'session-abc123')
bins = {
'user_id': 42,
'ip': '192.168.1.1',
'cart': ['item-1', 'item-2'],
'created_at': 1722000000
}
meta = {'ttl': 3600} # expire in 1 hour
client.put(key, bins, meta=meta)
# Read specific bins (projection)
key_res, meta_res, session = client.get(key, policy={'read_touch_ttl_pct': 50})
print(session['user_id'])
# Atomic increment (no read-modify-write race)
client.increment(key, 'page_views', 1)Secondary Index for Range Queries
import aerospike
from aerospike import predicates as p
client = aerospike.client({'hosts': [('aerospike.internal', 3000)]}).connect()
# Create secondary index
client.index_integer_create(
'sessions', 'user_sessions', 'user_id', 'idx_user_id'
)
# Query using secondary index
query = client.query('sessions', 'user_sessions')
query.where(p.equals('user_id', 42))
results = query.results()
for key, meta, bins in results:
print(bins)Aerospike vs Redis vs Cassandra
| Dimension | Aerospike 7.0 | Redis 8 | Cassandra 4.1 |
|---|---|---|---|
| Read latency (p99) | <1ms (SSD) | <0.5ms (RAM) | 5–20ms |
| Write throughput | 1M+ ops/s (3 nodes) | 500K ops/s | 200K ops/s |
| Data size limit | TB (SSD) | RAM-bounded | TB (disk) |
| Consistency | Strong (CP) | Eventual (cluster) | Tunable |
| TTL support | Per-record TTL | Per-key TTL | Column-level TTL |
| Best use case | Ad tech, fraud, sessions | Caching, queues | IoT, time series |
Aerospike's primary index requires 64 bytes of RAM per record. For 1 billion sessions, that's 64GB of RAM just for indexes. Size your Aerospike cluster with RAM as the primary constraint, not storage.
- Aerospike's Hybrid Memory Storage enables Redis-class latency with SSD-scale data capacity — the best of both worlds for session and ad tech workloads.
- Aerospike 7.0's strong consistency mode (CP) makes it viable for financial and fraud-detection workloads that Redis cluster can't guarantee.
- Primary index lives in RAM (64 bytes/record) — RAM is the sizing constraint, not SSD storage.
- XDR (cross-datacenter replication) in 7.0 provides active-active multi-region with conflict resolution built in.
Working with JusDB on Aerospike
JusDB deploys and tunes Aerospike clusters for ad tech, gaming, and fintech teams requiring consistent sub-millisecond latency at scale. We handle namespace configuration, secondary index design, XDR cross-datacenter setup, and ongoing capacity planning.
Explore JusDB NoSQL Management → | Talk to a DBA
Related reading: