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.

Designed as an operational distributed database, Aerospike employs a specialized log-structured file system that optimizes using flash drives (SSDs) as primary data storage without heavy dependence on RAM for performance.

Aerospike uses SSDs as raw devices, employing a proprietary log-structured file system rather than relying on file system, block, and page cache layers for I/O.  This provides distinct performance and reliability advantages. Aerospike uses raw-device block writes and lightweight defragmentation.

Firms can choose from hybrid memory (indexes-only in DRAM and data on Flash), all DRAM (i.e. in-memory), all-flash, and as of Aerospike 7.1, support for NVMe-compatible, low-cost cloud block storage, and common enterprise networked attached storage (NAS).

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 clients (Smart Clients) are aware of the data distribution across the cluster; therefore, they can send their requests directly to the node responsible for storing the data. This reduces the network hops required, improving the database's performance.

Aerospike’s Smart Client layer maintains a dynamic partition map that identifies the primary node for each partition. This enables the client layer to route read or write requests directly to the correct nodes without any 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 many nodes based on its SSD-friendly Hybrid Memory Architecture and flexible configuration options.

Data distribution

Aerospike distributes data across cluster nodes automatically. When a node joins or leaves the cluster, the data is automatically redistributed.

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.

Vertical scaling

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. (There is no theoretical upper limit for the amount of resources that can be added to a single node.)

Horizontal scaling

The data distribution is random; therefore, scaling an Aerospike cluster in and out results in less data movement. Also, Aerospike follows a peer-to-peer architecture, meaning that no node has a special role. In this architecture, the load gets equally distributed across all the 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.

Supports multi-site deployments for varied business purposes: Continuous operations, fast localized data access, disaster recovery, global transaction processing, edge-to-core computing, and more. 

Asynchronous active-active replication (via Cross Datacenter Replication, XDR): is achieved in sub-millisecond or single-digit milliseconds. All or part of the data in two or more independent data centers gets replicated asynchronously. The replication can be one way or two ways.

The clients can read and write from the data center close to them.

The expected lag between data centers is in the order of a few milliseconds. Optimizations to minimize transfer of frequently updated data.

XDR also supports selective replication (i.e., data filtering) and performance optimizations to minimize transfer of frequently updated data.

Synchronous active-active replication (via multi-site clustering): A single cluster is formed across multiple data centers. Achieved in part via rack awareness, pegging primary and replica partitions to distinct data centers. Automatically enforces strong data consistency.

The clients can read data from the node close to them; the expected latency will be less than a millisecond. However, the write requests may need to be written in a different data center, which may increase the latency to a few hundred milliseconds.

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.