ScyllaDB vs Aerospike, Wide-Column vs. Key/Value

Wide-column flexibility doesn’t have to come at the expense of performance — see where the two models differ, where each one wins, and why you no longer have to choose

Aerospike published a paid benchmark to show it’s faster. Color me surprised…it defined the winner as itself. Aerospike benchmarked the one workload its architecture is built for. This article shares the fuller picture: what a wide-column database does that a key-value store can’t, why that’s a genuinely harder engineering problem, and how — even with broader capabilities — ScyllaDB still beats Aerospike at its own (rather limited) game.

Let’s start by giving Aerospike its due. It’s a very good key/value database. Caching keys in RAM while values sit on fast NVMe is a clever design for a simple K/V model: you get excellent throughput and superb low latency. But when a vendor enters your backyard with a benchmark, the right response is to educate the market on what the numbers leave out. The challenge also inspired us to build a pure K/V option of our own. (More on that later.)

ScyllaDB is a more sophisticated database. It belongs to the wide-column NoSQL family, a strict superset of key/value. The model gives every row a full set of clustering keys. A single row can hold millions of independent entries, and any one cell can be read or written without touching the rest. High availability and disaster recovery are baked into the model, along with configurable replication, local and global indexes, best-in-class elasticity, and a managed service with bring-your-own-cloud, encryption, bring-your-own-keys, and security built in.

This post explains why wide-column flexibility doesn’t have to come at the expense of performance. We’ll show where the two models differ, where each one wins, and why you no longer have to choose.

Wide-column (KKV) vs key/value (KV)

A key/value store is a collection of rows, each with a key and a value. That value might be a single element or a set of bins, but they all share one unit of allocation. A wide-column database, by contrast, can host millions of independent cells in each row. Think of it as a key-key-value: a partition key locates the row, and ordered clustering keys locate multiple cells within it.

Clustering keys unlock real access patterns

Because clustering keys allow you to sort, ScyllaDB is a natural time-series database. Partition by sensor_id, cluster by timestamp, and “fetch every reading for sensor A between Tuesday and Friday” becomes an efficient range scan. The same shape powers messaging, event logs, IoT, and ML feature stores.

A few of the patterns this enables:

Time-series: latest-N is a cheap head read

PRIMARY KEY ((sensor_id), reading_ts) WITH CLUSTERING ORDER BY (reading_ts DESC)
-- Range slice: WHERE sensor_id=? AND reading_ts >= ? AND reading_ts < ?

Use partition keys as partition IDs and time buckets as clustering keys. It’s a classic time-series use case with features like TTL, time window compaction strategies, and easy tiering of time-based storage.

Messaging (the Discord shape): order comes for free

PRIMARY KEY ((channel_id, bucket), message_id) WITH CLUSTERING ORDER BY (message_id DESC)

And more patterns, not just time-based…

Leaderboard: the top of the partition IS the ranking

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

Key-key-value / generic attribute store

Emulate a map of independently updatable fields per entity by clustering on the attribute name. This is the cell-level-update advantage over plain K/V —  no read-modify-write, explained below.

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

Adjacency list / graph edges

Partition per vertex, cluster by edge type then neighbor, so you can slice “all FOLLOWS edges for user X.”

PRIMARY KEY ((vertex_id), edge_type, target_id)

Append-only event log / event sourcing

Immutable events ordered within an aggregate. Replay is a single partition scan.

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

Partition/topic sharding for smaller building blocks

PRIMARY KEY ((celebrity_id, shard), post_ts)

A key/value store can only approximate some of these patterns, typically by relying on secondary indexes and their overhead, or by stuffing ever-growing lists into a single bin (which bloats records and creates bottlenecks).

Look Ma, no read-modify-write!

When a K/V store needs to update a single element inside a large value, it can’t touch just that element (since the element shares storage units with other fields written in the past or even in parallel). It has to read the whole object, merge the change in memory, and write the whole thing back. That’s the read-modify-write (RMW) tax, and it shows up as write amplification.

Aerospike provides optimized concurrency control for users through a generation number exchanged between client and server:

When concurrent accesses touch the same cell, this makes a ton of sense. But within a large partition, it produces an enormous amount of false sharing.

ScyllaDB updates a single cell directly. A log-structured merge (LSM) tree reconciles cells later, in the background, using I/O schedulers and compaction controllers that run on low-priority idle time. No user involvement is required, and there’s no impact on latency.

KKV handles more

Values in the K/V model are limited in size and treated as an atomic blob, which is exactly what exposes them to the RMW cost above, but also what makes them easy to cache and locate on disk. Aerospike takes a better approach than Redis: it caches keys in RAM and fetches values from disk. Since value size is bounded, a single disk access is enough. It’s a simple, effective design, and it performs well. Latency is excellent: at most one I/O is required to bring data into RAM, and modern NVMe can do that in tens of microseconds.

Wide-column adds complexity, a challenge for the engineers who build the database but a benefit for the people who use it. A single key can point to a giant partition; ScyllaDB has customers running terabyte partitions. We don’t recommend it, but the flexibility is there.

The ScyllaDB engine does much more than fetch a blob. Since partition size is unknown ahead of time, multiple memory allocations happen during parsing, and multiple I/O accesses may be needed to fetch a partition range. For an example of the data structure and I/O accesses required for such partition ranges, see How ScyllaDB’s Trie-Based Index Delivers Up to 3X More Throughput.

• To guarantee consistency for parallel readers and writers, ScyllaDB uses MVCC (multi-version concurrency control), so readers get consistent results.
• Users can range-scan subsets of partitions, reading terabytes in a single query.
• The cache has to operate at row level, not partition level.
• Tombstones, the markers for deleted data, can’t be a single marker; ScyllaDB supports range tombstones.

Altogether, this is a fundamentally harder problem.

Operational costs of keeping the index in RAM

Aerospike stores its primary index in RAM at a fixed 64 bytes per key. That design decision has three consequences: slow boot, poor efficiency on small values, and wasted storage density.

Slow boot. Because the model assumes every key lives in RAM, a node must rebuild its entire index on startup. We’ve seen this take 30 minutes. A new node joining the cluster has to build its index before it’s useful, which slows elasticity, and rolling restarts become operationally heavier as a result.

Poor efficiency on small values. Aerospike’s index costs 64 bytes of RAM per key regardless of value size. At 1 KB records, that’s a 1:16 RAM-to-disk ratio — reasonable compared to Redis, but a costly limiting factor as datasets grow. At 256 B records, the ratio drops to 1:4, and you end up provisioning enormous amounts of RAM for a mediocre result. ScyllaDB commonly runs at a 1:100 RAM-to-disk ratio, and we’re pushing that toward 1:1000 through ongoing engineering work: moving metadata objects from RAM to disk and expanding tiered storage support. For large datasets, that ratio determines how many nodes you provision. There’s an interactive tool on this comparison page that lets you plug in your own record size and key count.

The same 6 TB dataset: eight emptier Aerospike nodes vs two dense ScyllaDB nodes

Dense instances go wasted. A RAM-bound index caps how much disk a node can usefully hold, so Aerospike can’t make effective use of storage-dense instance families like AWS i8ge, i7ie, or i3en. The sponsored Aerospike benchmark reveals this directly: 6 TB of raw data spread across 8 i4g.4xlarge nodes, with roughly 15 TB of storage per zone. That’s about 40% utilization; you’re paying for empty disk on a deliberately less dense instance family. ScyllaDB can host the same 6 TB on 2 i8ge.3xlarge nodes, one per zone, at 12 vCPUs and 7.5 TB each, running at 80% utilization and capable of going up to 90%. Most deployments become data-bound over time as datasets grow; a RAM-bound index forces you to run more, emptier machines to compensate.

How the more complex model performs

Despite all that complexity, ScyllaDB matches, and in a fair fight beats, Aerospike’s best published benchmark numbers. Aerospike’s software license doesn’t permit third-party benchmarking of their database, so our methodology is to reproduce their published ScyllaDB benchmarks on equivalent hardware and rerun them ourselves.

In August 2021, Aerospike published a petabyte-scale whitepaper claiming 5 million TPS for a read-only workload and 3.7 million TPS for an 80/20 read-write mix, on 20 i3en.24xlarge nodes.

We reproduced the test on 20 i3en.metal nodes with the same CPU count, RAM, and storage. ScyllaDB sustained 7 million operations per second for reads or writes at single-digit millisecond latencies, and 7.5 million inserts per second at 4ms P99 latency. Aerospike had a slight edge on P99 latency; ScyllaDB had 40% higher throughput.

• Benchmarking Petabyte-Scale NoSQL Workloads with ScyllaDB (July 2022)
• Operating at Monstrous New Scales: Benchmarking Petabyte Workloads on ScyllaDB (February 2022)
• Running Operational Workloads with Aerospike at Petabyte Scale in the Cloud on 20 Nodes (August 2021)

In early 2026, Aerospike published another benchmark, this one run by McKnight Group on Aerospike’s behalf. Unsurprisingly, its database came out ahead, the result of a long list of misconfigurations. A few examples:

• Replication factor 3 for ScyllaDB against replication factor 2 for Aerospike, even though ScyllaDB supports RF=2.
• An old, unmaintained YCSB Cassandra client instead of a current ScyllaDB driver with shard and tablet awareness. A modern ScyllaDB driver performs 3–4x better.
• Several other configuration choices that stacked the deck the same way.

The new benchmark also references our 2022 measurements, and in doing so explains why ScyllaDB showed superior throughput back then: storage density. That benchmark used i3en nodes, with a RAM-to-storage ratio of 1:78. At that ratio, Aerospike’s standard mode can’t work, so the vendor’s own benchmark runners switched it to flash mode, storing keys on disk as well. The result was ScyllaDB with 40% better throughput. In similar storage-bound cases, the TCO gap widens further, since Aerospike charges high per-terabyte rates.

We reran the ScyllaDB side with a corrected configuration and matched Aerospike’s throughput using our standard KKV log-structured merge tree. ScyllaDB’s P99 latency came in 1–2ms higher than Aerospike’s, only at P99, not at P50. The KKV model does more work per operation and may require multiple disk I/O accesses. We’re not going to pretend otherwise.

One note on what that benchmark actually tested: key/value only, the one schema Aerospike supports, with large 2 KB values that mask the all-index-in-RAM problem. It skipped single-cell RMW updates, node failures, and scaling events, precisely the conditions where the model difference shows up. We’re proud of the shard-per-core architecture that lets us extract maximum throughput from the hardware, and the tablet architecture that drives elastic scale.

But the 1–2ms P99 difference on that workload was real. It’s the cost of running a more complex KKV model that does more work per operation, and there are plenty of pure K/V use cases like it. Teams running those workloads on Redis or Aerospike often end up overprovisioning RAM to compensate. That’s what led us to build a storage format that keeps ScyllaDB’s shard-per-core architecture, schedulers, and elastic scale, while cutting I/O accesses to the minimum for simple K/V workloads: Logstor.

Meet Logstor, ScyllaDB’s new native K/V format

Logstor inherits everything that makes ScyllaDB ScyllaDB: tablets, the managed service, advanced consistency options, and adds a simple value type to push performance further. It’s named after the LSA (log-structured allocator) that already manages ScyllaDB’s in-RAM memory; Logstor applies that same algorithm to managing space on disk.

For some workloads, the wide-column KKV format is the right tool. For others, genuinely simple key/value lookups, the new K/V format is the better choice, and in those cases Logstor outperforms Aerospike. We’re completing results on the current i8g generation and will publish them soon. Either way, teams can now run both workload types on a single, elastic, fully managed database: ScyllaDB.

What the ScyllaDB managed service brings

Teams also choose ScyllaDB for reasons beyond performance. ScyllaDB Cloud has run data-intensive production workloads since 2019 for teams including Tripadvisor, SAS, Freshworks, and Supercell. It offers:

• Elasticity via tablets and ScyllaDB X Cloud: scale from 500K to 2M OPS in about 10 minutes.
• Schema for type enforcement and safety, plus a more relaxed DynamoDB-compatible API.
• Configurable consistency: global quorum, each-quorum (per data center), and per-query consistency levels, along with advanced networking, compression, and workload prioritization.
• Native multi-DC with eventually consistent active-active replication and local reads and writes, not CDC bolted on between data centers.
• Control over availability-versus-cost trade-offs, from replication factor 2 to quorum-based majority of 3 or 5.
• Global, local, and materialized view indexes.
• Simultaneous scale up and out: fully utilize large nodes while adding nodes in parallel.
• 24×7 support with a 15-minute SLA and the leading rating among NoSQL providers on G2.
• API compatibility with both Cassandra and DynamoDB.

You don’t need to compromise

Your team can have a best-in-class managed service, elasticity, and high availability, along with access to both a feature-rich wide-column database and a pure key/value store that holds its own in the industry. Pick the model that fits each workload and run both on the same elastic, fully managed ScyllaDB platform.

Like every vendor, we can show you a synthetic benchmark where we win. We’d rather prove it on your own workload. Our engineers can help you get started and share strategies for an accurate comparison.