Couchbase vs. Aerospike

Couchbase is a distributed NoSQL document database. It is the result of a merger between the Membase and Apache CouchDB code bases.

It features a memory-first architecture to achieve high performance, automatically managing a caching layer to keep frequently accessed data in memory.

Memory is allocated on a per-node basis, and different nodes can be configured to run different services (e.g., analytics, text search, data, indexing, query, eventing, and backup).

Aerospike is a distributed, multi-threaded database. It is engineered to get the most out of compute, network, and I/O resources. 

Aerospike focuses on the minute details of CPU, shared memory, processor cache, and NVMe. 

Its Hybrid Memory Architecture™ (HMA) enables the use of flash storage (SSD, PCIe, NVMe) in parallel to perform reads at sub-millisecond latencies at very high throughput (100K to 1M+ TPS), even under  heavy write loads. This enables enormous vertical scaleup at a 5x lower total cost of ownership (TCO) than pure RAM.

Aerospike bypasses the operating system’s file system and directly utilizes a flash device as a block device using a custom data layout.

Aerospike uses multi-threading extensively to achieve maximum parallelism for all major functions and exploits the power of modern multi-core processors.

Couchbase users model their data as JSON-based documents, each of which can have varied schemas. Both scalar data types and nested structures are supported.

Couchbase can also be used to model key-value data as JSON documents.

Aerospike distributes and stores  sets of records contained in namespaces (akin to “databases”). Each record has a key and named fields (“bins”). A bin can contain different types of data from the simple (e.g., integer, string) to the complex (e.g., nested data in a list of maps of sets).

This provides considerable schema flexibility.

Aerospike supports fast processing of Collection Data Types (CDTs) which contain any number of scalar data type elements and nesting elements such as lists and maps. Nested data types can be treated exactly as a document.

Aerospike’s structure enables users to model, store, and manage key-value data, JSON documents, and graph data with high performance at scale.

Designed for distributed environments, Couchbase clusters consist of one or more nodes that each operate independently as peers.

While Couchbase can automatically detect changes in cluster status, data rebalancing requires manual operation (unless using Kubernetes). Unbalanced clusters may experience performance issues. Additionally, if nodes containing the sole remaining vBuckets of the target data go offline, that data will be unavailable until the nodes are restored.

Aerospike was designed from the outset as a distributed database. All nodes are aware of each other. 

Aerospike features a Smart Client™ that automatically distributes both data and traffic to all the nodes in a cluster. 

Automatic client load balancing improves both performance and correctness. This ensures a single hop to data for the lowest possible latencies.

Couchbase’s default storage engine (Couchstore) uses a B-tree based structure. Certain aspects of this engine can introduce write overhead:  e.g., block compression isn’t supported, and compaction is single-threaded and not incremental.

Couchbase recently introduced its Magma engine to address these issues, which combines LSM trees and a segment log approach from log-structured file systems.

Couchbase promotes Magma as a way to reduce write amplification, drive down memory requirements, and exploit SSDs more efficiently. Presently, there is little performance data available for customers’ production use of Magma.

Users can choose from Hybrid Memory Architecture (HMA, flash and RAM), in-memory, or all-flash configurations.

All of these configurations are part of the Aerospike unified storage engine format, which employs an efficient flat format for a consistent development experience.

Aerospike’s HMA leverages the unique properties of flash storage (SSDs) by treating them as raw block devices and utilizing a custom file format. This approach bypasses the file system, block, and page cache layers, resulting in fast performance that scales without heavy reliance on RAM.

Couchbase ensures strong consistency for direct document access by routing all reads and writes of a specific document to a single node within the cluster, thus maintaining a single active version of any document. This model guarantees that operations on a document are immediately consistent.

Couchbase is a strongly consistent database too but offers variables to allow itself to modify consistency levels for availability, transforming it into an AP system.

To date, Couchbase has not validated their strong consistency via Jepsen testing.

Aerospike provides distinct high availability (AP) and (strong consistency) (CP) modes to support varying customer use cases.

The independent Jepsen testing in 2018 validated Aerospike’s claim of strong consistency. Strong consistency mode prevents stale reads, dirty reads, and data loss.

With strong consistency, each write can be configured for linearizability (provides a single linear view among all clients) or session consistency (an individual process sees the sequential set of updates).  

Each read can be configured for linearizability, session consistency, allow replica reads (read from master or any replica of data), and allow unavailable responses (read from the master, any replica, or an unavailable partition).

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

High Availability (AP)/partition tolerant mode emphasizes data availability over consistency in failure scenarios.

Modes and consistency levels can be defined at the namespace level (database level).

The client SDK maintains a copy of the Couchbase cluster map (a hashmap), including where each data partition (vBucket) resides. Hashing a document’s key enables the SDK to locate the responsible vBucket so the client can work directly with the appropriate node to access target data. 

Aerospike’s Smart Client™ layer maintains a dynamic partition map that identifies the master node for each partition. This enables the client layer to route the read or write request directly to the correct node without additional network hops. 

Since Aerospike writes synchronously to all copies of the data, there is no delay for a quorum read across the cluster to get a consistent version of the data.

Scaling up or scaling out is dependent on the type(s) of services running on nodes. For example, horizontal scaling (scale out) is recommended for data nodes while vertical scaling (scale up) is recommended for index and query nodes.

Maintaining the minimum recommended 20% of data (“working set”) in memory, with  the remainder on disk, can lead to clusters of many nodes as data volumes scale to hundreds  of terabytes to petabytes when using the default storage engine. Furthermore, as data volumes grow and workloads become more varied, an increased likelihood of cache misses can lead to unpredictable data access latencies.

Couchbase’s architecture imposes practical limits on scaling up each node. These limits vary depending on the underlying storage engine in use.

Couchbase’s Multi-Dimensional Scaling (MDS) – adding or removing individual service instances and whole services – provides flexibility but requires careful planning. 

Aerospike handles massive customer growth without having to add a lot of nodes, based on its SSD-friendly Hybrid Memory Architecture^TM and flexible configuration options. 

Aerospike exploits SSDs, multi-core CPUs, and other hardware and networking technologies to scale vertically, making efficient use of these resources. You can scale by adding SSDs.

Aerospike automatically shards data into 4,096 logical partitions evenly distributed across cluster nodes. When cluster nodes are added, partitions from other cluster nodes are automatically migrated to the new node,  resulting in very little data movement. The Aerospike data rebalancing mechanism distributes query volume evenly across all cluster nodes.

Supports multi-site deployments for varied business purposes, including continuous operations, fast localized data access, disaster recovery, global transaction processing, edge-to-core computing, and more. Cross Datacenter Replication is asynchronous.

Both synchronous and asynchronous data replication are supported for varied business purposes, such as continuous operations, fast localized data access, disaster recovery, global transaction processing, edge-to-core computing, and more.

Synchronous replication, with multi-site clustering (MSC) via rack awareness, pegs primary and replica partitions to distinct data centers. Synchronous replication automatically enforces strong data consistency.

Asynchronous replication via Cross Datacenter Replication (XDR) is achieved in sub-millisecond or single-digit milliseconds. XDR also supports selective replication (i.e., data filtering) and performance optimizations to minimize transfer of frequently updated data.

Several connectors are available from Couchbase to popular offerings, namely, Elasticsearch, Kafka, Spark, Tableau, and ODBC/JDBC drivers. Community contributions are generally welcome for these connectors;  performance optimizations vary. These connectors provide broader access to Couchbase from external offerings.

Performance-optimized connectors for Aerospike are available for many popular open source and third-party offerings,  including Kafka, Spark, Presto-Trino, JMS, Pulsar, Event Stream Processing (ESP), and Elasticsearch. These connectors, in turn, provide broader access to Aerospike from popular enterprise tools for business analytics, AI, event processing, and more.

Couchbase offers three levels of containment - buckets, scopes, and collections - to support multi-tenancy. It provides fine-grained access control and backup/restore options. Some of these features are new as of this writing (i.e., production-ready in release 7.0 or later).

Aerospike’s key features for multi-tenancy are separate namespaces (databases), role-based access control in conjunction with sets (akin to RDBMS tables), operational rate quotas, and user-specified storage limits to cap data set size.