cloudparts

Aerospike

A distributed key-value database written in C that keeps its index in RAM and its records on SSDs, for steady sub-millisecond lookups on terabytes of data.

What it is
Key-value stores
Type
Commercial product
Made by
Aerospike, Inc.
License
AGPL-3.0 (Community Edition server), Apache 2.0 (clients); Enterprise Edition proprietary
Facts checked
24 October 2026
Website Source code

What it is

Aerospike stores records under keys, grouped into namespaces (like databases) and sets (like tables); a record holds named bins, like columns, whose types come from their values. Each namespace picks its own storage: records can live in RAM or, more cheaply, on SSDs, where Aerospike writes to the flash device directly and bypasses the file system. The primary index stays in RAM by default and costs 64 bytes per record whatever the record’s size, so a lookup is one hash and one device read. Records can expire with a time to live.

A key is hashed with RIPEMD-160, and 12 bits of the digest pick one of 4,096 partitions per namespace, spread evenly over the nodes. Each partition has one master copy and replicas on other nodes, two copies in total being the common setting, and the cluster rebalances partitions by itself when nodes join or leave. Clients learn the partition map and send each request straight to the node that owns the key, with no proxy in between. Cross-datacenter replication (XDR) ships changes to clusters elsewhere.

A namespace runs in one of two modes. Availability mode, the default, keeps serving during network splits but can lose writes or return stale data. Strong consistency mode, available in the Enterprise Edition and the managed cloud, never loses an acknowledged write and offers linearizable reads. Aerospike 8.0, released in January 2025, added transactions across records in one namespace with strict serializability; 8.2, from September 2026, is the current release. The Community Edition server is AGPL-3.0, while strong consistency, index-on-flash and other features are in the paid Enterprise Edition.

Why teams pick it

  • Predictable latency at large data sizes: index in RAM, data on SSD, one device read per lookup
  • Smart clients go straight to the node that owns a key, and partitions rebalance on their own
  • Choose per namespace between availability and strong consistency, with multi-record transactions since 8.0
  • Much cheaper per terabyte than keeping everything in memory, as Redis or Memcached do

Watch out for

  • Every record costs 64 bytes of RAM in the index on every node that holds a copy, so billions of tiny records need a lot of memory
  • Strong consistency, index-on-flash and other operational features are only in the paid Enterprise Edition
  • In the default availability mode, a network split can lose acknowledged writes or serve stale reads
  • Transactions stay within one namespace

Good for

Specs

Compare with alternatives →
Data model
Records of named bins under keys, grouped in namespaces and sets
Query language
Key-value operations through smart client libraries
Transactions
Multi-record within one namespace, strictly serializable (since 8.0)
Consistency
Per namespace: availability mode (default) or strong consistency (Enterprise)
How it scales
4,096 hash partitions per namespace, rebalanced automatically
Replication
One master and replicas per partition; two copies is common
Multi-region
Cross-datacenter replication (XDR) to other clusters
Storage engine
Primary index in RAM (64 bytes per record); data in RAM or on raw SSD
Written in
C
Ways to run it
Self-hosted Community (AGPL) or Enterprise Edition, or Aerospike’s managed cloud

Alternatives

What all key-value stores have in common →Compare side by side →
Amazon DynamoDBAWSAWS’s serverless key-value and document database, with single-digit-millisecond reads at any size.ScyllaDBCommercialA C++ rewrite of Cassandra’s design with one shard per CPU core, speaking both CQL and the DynamoDB API.ValkeyOpen sourceAlso good for sub-millisecond lookupsThe Linux Foundation’s BSD-licensed fork of Redis 7.2.4: an in-memory key-value server that Redis clients can talk to unchanged.FoundationDBOpen sourceAlso good for serializable transactions across keysAn ordered, distributed key-value store with strictly serializable ACID transactions across the whole cluster, built as a small core that other databases are layered on.ManhattanCommercialTwitter’s in-house, multi-tenant distributed key-value store, eventually consistent by default with opt-in strong consistency per dataset, which serves Tweets, users and direct messages.Workers KVCommercialCloudflare’s global key-value store that keeps data in a few central stores and caches it in the data centers where it is read, so reads are fast and writes take up to a minute to show up everywhere.

See it in a real stack

No architecture uses Aerospike yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2010–2026

Aerospike started as Citrusleaf, a key-value database sold from 2010. In August 2012 the company and product were renamed Aerospike, and the same year it bought AlchemyDB and folded in its features. Its design kept indexes in memory and let the records themselves live on flash, written without a file system in between.

In 2014 Aerospike open-sourced the server under the AGPL and its client libraries under Apache 2.0, while keeping an Enterprise Edition. Version 4.0 in 2018 added a strong consistency mode beside the default available one, and 6.x added JSON documents and queries. Aerospike 8.0 in January 2025 brought distributed ACID transactions across records, and it now also offers graph and vector search models alongside key-value and documents.

Why it’s built this way

Index in RAM, records on SSD
SSDs hold far more data per dollar than RAM. Keeping only the fixed-size index in memory means finding a record never touches disk, and reading it takes one device read.
Write to raw flash, not files
Bypassing the file system gives Aerospike control over how data is laid out and written on SSDs, and removes a layer of caching and overhead.
A fixed set of partitions and smart clients
With 4,096 partitions per namespace and the map held by clients, every request goes to the right node in one hop and rebalancing moves whole partitions.

Timeline

  1. 2010

    Sold as Citrusleaf

  2. 2012

    Renamed Aerospike; acquires AlchemyDB

  3. 2014

    Server open-sourced under AGPL-3.0, clients under Apache 2.0

  4. 2018

    Version 4.0 adds a strong consistency mode

  5. 2025

    Aerospike 8.0 adds transactions across records

  6. 2026

    Aerospike 8.2 released in September

Sources7 · facts checked 24 October 2026

Improve this page on GitHub