Cassandra vs Aerospike

Cassandra is a distributed wide column store where data resides in rows, each with its own set of columns, which can be described as tabular but not quite a table. Rows are sorted using clustering keys.

Cassandra has a JSON data type,  but document-based operations are not supported. Thus, operations on JSON elements can only be applied on the client side. This adds extra latency to these operations from the client fetching the record over the network.  

Cassandra does not support graph use cases, though some vendors have provided graph database support in the past on their commercial versions.

Primary access pattern is key-value, with value types including string, integer, double, blob/byte, boolean, lists (ordered or unordered), and maps (unordered, key-ordered, or value-ordered), HyperLogLog, and geospatial.

Aerospike allows multiple different data types to be stored under a single key using separate bins (analogous to columns in relational databases), providing additional flexibility.

Aerospike supports declarative secondary indexing on individual bins or on entries in a list or map.

Cassandra proudly references users with tens of thousands of nodes, exemplifying its horizontal scalability. Adding nodes is Cassandra’s means of scaling. 

Cassandra uses consistent hashing to distribute data across nodes. 

It employs Virtual Nodes (vnodes) to split the hash ring into chunks reducing data movement when adding/removing nodes. 

They also employ incremental data movement in the background minimizing impact on performance.

Aerospike distributes data across logical partitions evenly spread over nodes; adding or removing a node migrates only the partitions that must move, minimizing data movement. It also scales vertically by exploiting NVMe, multi-core CPUs, and fast networking, with a peer-to-peer architecture in which no node has a special role.

Cassandra is designed for availability and partition tolerance (AP). It has not passed the Jepsen test for strong consistency. 

Its tunable consistency requires programmers to understand nine consistency level settings and select what is appropriate for their operational needs, taking availability, latency, throughput, and data correctness into account.

Cassandra’s quorum-based consistency algorithm requires 2N+1 copies to handle N failures. Cassandra automatically detects and responds to many network and node failures to ensure high availability of data without requiring operator intervention.

Aerospike offers distinct AP and CP modes per namespace, and neither mode makes the usual hard trade-off implied by the CAP theorem (Consistency, Availability, Partition tolerance). Its AP mode still replicates quickly enough that the eventual-consistency window stays tight, well short of what teams typically brace for with an AP system. Its CP mode doesn't sacrifice availability to the degree many CP databases do, since consensus happens per partition rather than across the whole cluster, and read and write consistency levels are configurable rather than requiring every replica to acknowledge. Its strong-consistency mode was validated by Jepsen testing and prevents stale reads, dirty reads, and data loss.

Aerospike offers true distributed multi-record Atomicity, Consistency, Isolation, Durability (ACID) transactions that provide strict serializability, the strongest correctness guarantee available in a distributed database. Transactions spanning multiple records and their replicas execute as if in a single real-time order, preventing not only stale and dirty reads but subtler anomalies like causal reverse, where a later transaction's effects become visible without an earlier, causally related one also being visible. Few distributed databases, relational or NoSQL, offer this guarantee at all.

Cassandra users typically configure the system to automatically maintain three copies (RF3) of data for high availability.

Cassandra has a read_repair feature allowing tuning for data inconsistencies to be repaired automatically on an as-read basis, but it is selective and has performance impacts. 

The repair function can also be executed proactively and comprehensively, but is resource intensive.

Aerospike users typically maintain replication factor two (RF2) (one primary, one replica copy) for high availability. 

Aerospike automatically detects and responds to many network and node failures (“self-healing”) to ensure high availability of data, prevent data loss or performance degradations without requiring operator intervention.

Both synchronous and asynchronous data replication are supported.  

Synchronous, with multi-data center replication. 

Asynchronous: Replication between clusters is eventually consistent, but this can become delayed depending on the write consistency level.

Aerospike offers two multi-site models with very different consistency characteristics.

The first is asynchronous active-active replication via Cross-Datacenter Replication (XDR), which supports star, one-way, and mesh topologies with filtered replication. Because each cluster accepts local writes and ships them asynchronously, the same record can be updated in more than one cluster before replication catches up, so conflicts are resolved by last-write-wins, either whole-record or, with bin convergence enabled, at the individual field level, so writes to different fields both survive.

Last-write-wins has an important limitation: it converges every copy to the same final state but does not preserve intermediate updates, and it depends on reasonably synchronized clocks. That makes XDR active-active a good fit where the latest value is what matters (session state, profiles, last-known location, and caches) and a poor fit where every update must be counted (wallets, ledgers, and inventory). Often the right fix is a data-modeling one: if you model changes additively in a Collection Data Type (appending each update rather than overwriting a value), concurrent updates land as distinct entries and the merged record accumulates every contribution, letting many "every update counts" workloads use async active-active safely.

The second model, synchronous active-active via multi-site clustering, forms one cluster spanning data centers and uses strong-consistency mode to prevent conflicts entirely, so no committed write is lost. The trade-off is the physics of synchronous replication: each write pays the inter-site round trip, so it needs low-latency (typically metro or regional) links, or a tolerance of higher latency for database writes.

Cassandra employs a log-structured merge (LSM) tree for storage. LSM trees are designed to efficiently manage writes, but tend to slow reads. 

To mitigate potential read performance challenges, operators can employ any of the following:

• Bloom Filters for probabilistic checking before conducting full seeks

• Cache frequently accessed data in the Memtable and/or row cache

• Partition keys

• Sparse indexes (but with a storage cost)

• Compaction in merging smaller SSTables into larger ones reducing the number of files that need to be searched.

Aerospike employs a specialized log-structured file system that is optimized for the use of flash drives (SSDs) as primary data storage. 

Instead of appending writes to large log files and deferring compaction to a CPU and disk I/O-intensive operation, Aerospike uses raw-device block writes and lightweight defragmentation.

Users can choose from hybrid memory (flash and RAM), all RAM, or all flash configurations.

Cassandra is written in Java, a higher-level language. JVM garbage collection (GC) can affect latency. This is often the cause of the large spikes you’ll see in P99 and other tail latency stats with Cassandra.

Aerospike is written in C with deep underpinnings in networking, storage, and database expertise. It thus avoids Java runtime inefficiencies and, as a lower-level language, can optimize the hardware and directly manage memory, avoiding the overhead of garbage collection.

Primary: Primary indexes are standard.

Secondary: Significant data access latencies can occur if secondary index queries do not also use the partitioning key (primary key) as a filtering predicate. This is because secondary indexes are partition-based and index only the rows of a partition. 

Third-party alternatives have emerged to address the limitations of native Cassandra secondary indexes. These include storage-attached indexes (SAI) and SSTable-attached secondary indexes (SASI). SAI has limits, like covering only equality-based lookups. SASI, developed by Apple, does not index types like lists and maps.

Aerospike uses a proprietary partitioned data structure for its indexes, employing fine-grained individual locks to reduce memory contention across partitions. These structures ensure that frequently accessed data has locality and falls within a single cache line, reducing cache misses and data stalls. For example, the index entry in Aerospike is exactly 64 bytes, the same size as an X86 64-bit cache line.

By default, secondary indexes are kept in DRAM for fast access and are co-located with the primary index, but they can also be stored on SSD to save on memory.

Each secondary index entry references only primary and replicated records local to the node. When a query involving a secondary index executes, records are read in parallel from all nodes; results are aggregated on each node and then returned to the Aerospike client layer for return to the application.

Firms can also opt to store all user and index data (both primary and secondary) on SSDs to improve cost efficiency while still maintaining single-digit millisecond response times.

However, Aerospike can only use a single index in each query.

Various open source and third-party offerings provide access to Cassandra. Performance, capabilities and technical support vary. Community offers suggestions for roll-your-own  integration with many popular technologies.

Aerospike provides optimized connectors for Kafka, Spark, Presto/Trino, JMS, Pulsar, Event Stream Processing (ESP), Elasticsearch, LangChain, LangGraph, and others, giving analytics, AI, and event-processing tools broad access to Aerospike data.

Cassandra cannot be configured as an in-memory only platform, which is for highest performance.

To increase write performance, Cassandra temporarily stores writes in memory before flushing to disk for persistence. 

Caching of frequently accessed data, however, along with memory allocation tuning can be done.

Flexible configuration options enable Aerospike to act as: 

(1) a high-speed cache to an existing relational or non-relational data store to promote real-time data access and offload work from the back end 

or 

(2) an ultra-fast real-time data management platform with persistence. 

Aerospike can store all data and indexes in DRAM, all data and indexes on SSDs (Flash), or a combination of the two (data on SSDs and indexes in DRAM). As of Aerospike 7.1, adds support for NVMe-compatible, low-cost cloud block storage, and common enterprise networked attached storage (NAS).

Cassandra operators can employ a Tenant ID in the Partition Key to ensure data from different tenants is stored and queried separately. However, this could lead to data skew/imbalance across nodes if tenant data varies greatly.

Cassandra operators can also implement separate keyspaces for clear separation and easy management. However, it requires more operational overhead and potential resource allocation issues.

Within one cluster, Aerospike provides separate namespaces, role-based access control with sets, rate quotas, and per-set storage limits, practical tools for sharing infrastructure across tenants. This is soft multi-tenancy: it lets more tenants share the same cluster, but because they still share underlying resources, isolation is never as complete as giving each tenant dedicated hardware.

Where strict isolation matters, Aerospike's efficiency makes dedicated per-tenant clusters viable: it runs very well on modest hardware (nodes with as few as two vCPUs), so a fleet of small, fully isolated clusters is economically reasonable, unlike a RAM-bound, process-per-core engine.

Cassandra is designed to run on low-cost commodity servers and promotes adding more nodes to address growing workloads and data volumes. Specific hardware or networking exploitation is at odds with this design approach.

Massively multi-threaded within one process (throughput rises with core count instead of more processes); NVMe storage accessed as a raw block device, with cloud block storage and NAS also supported; Application Device Queues with supported NICs to cut context switching; and indexes (and optionally data) in RAM, with hybrid and all-NVMe layouts per namespace.

Each database change generates duplicate CDC records. For example, nine copies of three regions and RF=3. Complex workarounds and algorithms must be introduced to process and resolve these.

Aerospike's change notification is not a bolt-on; it rides on the same components that power XDR, battle-tested in large global deployments. As records change, the engine publishes them through that replication path to Kafka, Pulsar, JMS, Elasticsearch, or any HTTP endpoint via Event Stream Processing (ESP). Capture is granular: rapid writes to a hot record are compacted to the latest version, and a change is acknowledged only once it has been delivered, so a downstream outage doesn't lose data.