Switching from Aerospike: A Technical Comparison¶

At a glance¶

• Key-Key-Value, not just Key-Value. Clustering keys give every row millions of independently addressable cells. ScyllaDB updates each cell directly (vs. Aerospike’s read-modify-write).

• Indexes don’t live in RAM. Aerospike always pins 64 bytes per key in memory. ScyllaDB serves comparable latency straight from NVMe. RAM is cache rather than a constraint.

• Dense instances, fully used. Limited disk:RAM ratios lock Aerospike out of i8ge / i7ie / i3en-class hardware. ScyllaDB runs them at 90% utilization.

One write, or read-modify-write?¶

In a K/V model, the row is the unit of allocation. Updating a single element inside a large value bin means reading the whole object, merging the change, and writing it all back (so two I/O actions instead of one). ScyllaDB updates a single cell directly; the LSM tree merges cells in the background using idle-time I/O schedulers and compaction controllers, without any user involvement or performance impact.

The same clustering keys make ScyllaDB a natural time-series database: partition by sensor_id, cluster by timestamp, and range queries become sequential reads straight off disk. This is well-suited for event logs, messaging, IoT, AI feature stores. K/V can only fake this with secondary indexes or by overloading bins with ever-growing lists.

PRIMARY KEY ((sensor_id), reading_ts)
WITH CLUSTERING ORDER BY (reading_ts DESC)

PRIMARY KEY ((sensor_id, day), reading_ts)
-- day = '2026-06-14'

PRIMARY KEY ((channel_id, bucket), message_id)
WITH CLUSTERING ORDER BY (message_id DESC)
-- message_id = Snowflake / TimeUUID

PRIMARY KEY ((user_id), year, month, day, event_id)

PRIMARY KEY ((game_id, season), score, player_id)
WITH CLUSTERING ORDER BY (score DESC, player_id ASC)

PRIMARY KEY ((entity_id), attr_name)
-- rows of (attr_name, value)

-- base:   PRIMARY KEY ((user_id))
-- lookup: PRIMARY KEY ((email), user_id)

PRIMARY KEY ((vertex_id), edge_type, target_id)

PRIMARY KEY ((aggregate_id), event_seq)
WITH CLUSTERING ORDER BY (event_seq ASC)

PRIMARY KEY ((celebrity_id, shard), post_ts)
-- shard in 0..N

PRIMARY KEY ((tenant_id), status, updated_ts)
WITH CLUSTERING ORDER BY (status ASC, updated_ts DESC)

KKV is harder to build, but it pays off¶

Aerospike’s model is elegant precisely because it’s simple. Values are bounded atomic blobs, so they’re easy to cache and easy to locate. Just a single NVMe read (tens of microseconds) brings data to RAM. A wide-column store can’t take that shortcut, and we won’t pretend otherwise.

A single key can point to a giant partition. We have customers running a 1 TB partition (it’s not recommended, but the flexibility is there). Because partition size is unknown upfront, the engine has to do far more than fetch-a-blob:

• MVCC — Multi-version concurrency control so parallel readers and writers see consistent results across a partition that may be mid-write.

• Row-level cache — Caching has to work at row granularity, not whole-partition. You can’t evict or populate a terabyte as one unit.

• Range tombstones — Deletes aren’t a single marker; whole ranges of clustering keys can be tombstoned and must be reconciled on read.

• Multi-allocation parsing — Unknown partition sizes mean multiple memory allocations during parsing instead of one fixed-size slot.

• Multi-I/O range reads — Fetching a slice of a partition may require several disk accesses, scheduled so they never stall user traffic.

• Range scans — Users can scan arbitrary subsets of a partition — a query surface a pure K/V store simply doesn’t expose.

Altogether, this is a fundamentally harder problem. And ScyllaDB still matches Aerospike’s best benchmarks. The performance advantage of KV comes with a cost — read on for where each model wins.

64 bytes per key — in RAM, always¶

Aerospike keeps its primary index in RAM: a fixed 64 bytes per key, regardless of record size, scaling linearly with key count. Small partitions are where it hurts most — at 200 B records the key-to-data ratio approaches 1:3.5. ScyllaDB scales independently of memory: roughly 100 GB of data per 1 GB of RAM, with no hard ceiling on keys per node. The table below shows when RAM starts driving your infrastructure bill.

Dense instances are wasted on Aerospike¶

Because the key cache must live in RAM, Aerospike has a limited disk:RAM ratio and can’t take advantage of storage-dense families like AWS i8ge, i7ie, i3en. Look at the hardware Aerospike chose for its own 2026 benchmark: 6 TB of raw data on 8× i4g.4xlarge, with 15 TB of storage per zone. That’s roughly 40% utilization — so you’re paying for disk that sits empty, on a deliberately less-dense instance family.

This matters more over time. Most deployments become data-bound — the dataset grows until storage, not compute, dominates sizing. That’s exactly where Aerospike’s RAM-for-index architecture forces you onto more (and emptier) nodes.

Two more costs of keeping the index in RAM:

• Slow boot — up to 30 min. The model assumes every key is cached in RAM, so a node rebuilds its entire index on boot. This takes as long as 30 minutes. Elasticity suffers (new nodes must build their index), and rolling restarts get heavier. Flushing the key cache to disk before reboot helps, but it’s still slower and more complex than a KKV model that has no such limitation.

• Small partitions wreck RAM efficiency. Each key needs 64 bytes of RAM. With 128–256 B values, the key-to-data ratio gets ugly and you provision enormous amounts of RAM for a mediocre result. See the table above to compare RAM required and overhead for ScyllaDB KKV vs Aerospike KV at different record sizes.

Flexibility, without giving up the win¶

Despite managing all the complexity outlined above, ScyllaDB still beats Aerospike’s best published numbers in a head-to-head comparison. We keep up with their chosen workload, and we also do it while offering a data model their architecture can’t express.

7M+ ops/sec — 2021 benchmark, we repeated theirs at petabyte scale. Aerospike claimed 5M TPS read-only and 3.7M TPS 80/20 on 20 i3en.24xlarge. ScyllaDB hit 7M ops/sec and 7.5M inserts at 4ms P99 — 40% higher throughput on the same hardware class. See the petabyte benchmark blog and the presentation.

On par — 2026 McKnight Group benchmark, corrected config. The paid benchmark used incorrect configs: RF3 vs RF2, an old YCSB client. When ScyllaDB reran it with a corrected configuration, our wide-column KKV model matched throughput and the P99 was only 1–2ms higher at multi-terabyte scale. See the Aerospike whitepaper or prove it on your workload.

Meet Logstor — our native K/V mode¶

With demand for pure K/V and the chance to solve the easier problem optimally, we built our own K/V-only format. It keeps the advantages of ScyllaDB — tablets, DBaaS, advanced consistency options — and adds a simple value type to push performance even further. We call it Logstor, after the LSA (log-structured allocator) that already manages ScyllaDB’s in-RAM memory. Logstor applies the same algorithm to managing space on disk.

• Use KKV when you need the data model. Time-series, messaging, hierarchies, leaderboards, range scans, secondary indexes, multi-cell updates without RMW. The wide-column flexibility is the point.

• Use Logstor KV when it’s genuinely key/value. Simple lookups by key with a bounded value — Aerospike’s home turf. Logstor delivers better performance than Aerospike on that workload, with ScyllaDB’s elasticity and DBaaS underneath.

One platform, two storage engines, your choice per workload. For some use cases KKV is the right tool; for others the new KV format is. Either way, you stay on the same elastic, fully-managed, multi-region database — and either way you beat the alternative on its own terms.

And there’s more coming beyond raw performance — including fresh benchmark results on the current i8g generation, not just the older hardware.

Feature by feature¶

How do Aerospike and ScyllaDB compare on flexibility, efficiency, scaling, resiliency, and DBaaS capabilities? Explore each category below.

You don’t have to compromise¶

Teams can enjoy the best DBaaS, elasticity and HA while having a feature-rich wide-column DB or even a K/V store with the best results in the industry. Reach out to our engineering team.

• Book a strategy session

• Get started free