MongoDB vs. Aerospike

MongoDB uses a flexible, document-oriented data model to embed related data within a single document structure. Documents are grouped in databases and collections.

While not a graph database or key-value store, MongoDB offers graph traversal capabilities, which allow users to model key-value concepts in documents and conduct vector searches. 

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.

To deliver good performance, MongoDB caches the data on RAM. The working set must also fit on RAM. This increases the running cost and reduces the database's performance predictability.

Since v3.2, MongoDB uses a B-tree-based storage engine (WiredTiger WT) by default, which it recommends for operational databases. WT supports SSDs but treats them as ordinary storage devices and thus cannot get high performance from SSDs.

A single engine covers all-RAM, all-NVMe, and hybrid configurations. In NVMe-based options, including hybrid, durability is a native property of the storage engine, not an add-on. Records are written to NVMe as part of the normal write path, and a write can be configured to commit to the device before it is acknowledged, so an acknowledged write survives a node restart or power loss, with no snapshot interval during which recent writes could be lost. On restart, a node comes back from its persisted data quickly rather than replaying a large log to rebuild an in-memory dataset.

Although MongoDB can be configured for in-memory storage only, most firms deploy it as a persistent document store, keeping indexes and the working data set in memory for performance and persisting user data to disk for durability.

MongoDB was not designed to serve as a caching layer for a back-end store.

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).

MongoDB clients have to connect to a load balancer called Mongos. Mongos is responsible for accessing the cluster nodes to perform the query. This adds an additional network hop that, in high-performant use cases, is not desirable.

Beyond basic CRUD capabilities, the Aerospike Smart Clients handle a great deal on the application's behalf: they track cluster state and refresh their partition map as nodes join, leave, or fail, transparently retry and fail over to a replica on timeouts or node loss, manage connection pooling and load balancing across the cluster, and honor policies such as rack-aware reads.

Coverage extends well beyond the officially supported set. PHP and Ruby have Aerospike-maintained, community-supported clients; Spring Data Aerospike provides an idiomatic Spring layer over the Java client; and community drivers exist for languages such as Elixir, Erlang, and Perl.

Data distribution

Data is distributed in shards of the cluster. The number of shards is defined by the operator, making it a difficult operational task. Some sharding strategies are less automatic than others.

Users must instruct MongoDB to shard data across multiple nodes by selecting one of three sharding strategies (range, hash, or zone) and configuring various components. Insufficient planning can lead to performance and scaling issues later, including poor data distribution, overused/underused shards, added overhead due to chunk migration, and troubleshooting challenges. A sharded cluster needs a minimum of eight nodes, and each added shard requires at least three added nodes to fulfill replica requirements.

Vertical scaling

MongoDB server scaling is a CPU-heavy process. Vertical scaling is supported and can be “cheaper and easier” than sharding. Increasing the resources beyond some point does not result in better performance because of all of the context switches the process requires. Currently, Atlas (cloud offering) can scale vertically to handle four TB databases. For larger databases, horizontal scaling (sharding) must be employed.

Horizontal scaling

Data distribution is not necessarily minimal. In most cases, a significant portion of data must be moved, which takes a long time.

MongoDB has a primary/secondary architecture in each replica set. In addition, Mongos processes act as load balancers in front of the cluster. Then, there are config servers that store the metadata about the cluster. Scaling a cluster may require changes to all of these components.

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.

MongoDB’s recommended number of replicas is 3. It is possible to have RF=2 with an arbiter, but that adds complexity to the architecture. Higher replication factors are possible, but as the architecture is quorum-based, the number of nodes in a replica set must be odd (5,7, ...).

Because MongoDB uses a primary/secondary architecture, failures cause intermittent outages that, on average, take up to 12 seconds.

Node failure doesn't cause long-term loss, but operator intervention at critical points is still required as a cluster with a failed node is in a critical state.

Aerospike automatically detects and responds to many network and node failures to ensure high availability of data without requiring operator intervention.

Aerospike's recommended number of replicas for achieving high availability is 2. Higher replication factors are possible (3,4,5, ...).

Because Aerospike uses a peer-to-peer architecture, failures don't cause intermittent outages. If a node fails, the cluster can still immediately respond to all of the requests related to the failed node.

Aerospike auto-heals itself after a failure, reducing the need for operator intervention during critical events.

MongoDB supports causal consistency, strong consistency, and multi-record transactions (MRT).

Both readers and writers of records must use the correct configuration for their requests to make their requests consistent.

To achieve consistency, MongoDB requires the majority (more than half) of the nodes of a replica set to respond. (if RF=3, 2 nodes).

MongoDB uses a custom protocol based on the replica set operations log (oplog) to achieve consistency. Although this protocol is based on Raft, it has many differences and improvements.

MongoDB’s support for causal consistency uses a quorum-based approach (RAFT consensus) in which heartbeats are exchanged per raft group. Growth in data volumes leads to more raft groups, more heartbeat checks, and more CPU consumption.

Causal consistency guarantees that causally related operations appear in the same order on all processes.  This is considered a form of  “available under partition” support. In addition, applications can instruct MongoDB to enforce linearizability when reading and writing operations on the primary copy.

Passed Jepsen tests.

Aerospike supports strong consistency.

Aerospike consistency level is applied on the namespace level. No user can mistakenly write an inconsistent record into an otherwise consistent set.

Aerospike only needs a response from a single node to answer a read request consistently.

Aerospike uses a proprietary (roster-based) protocol that exchanges heartbeats between nodes, allowing CPU consumption to remain constant as data density per node increases.

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 read from primary or any replica of data, and allow unavailable read from primary, any replica, or an unavailable partition.

Passed Jespen tests.

MongoDB supports multi-data center replication in two ways:

1. Sharded distribution The shard key defines which data center stores the shard in which each record must be stored. The user has control over where to store the data, but the data will be only local to that data center. Local read and write requests will be fast, but the requests from the other data centers will be very slow.

2. Replicaset distribution The nodes of a single replica set can be deployed on multiple data centers. The reads can happen locally but the writes of only one data center will be fast. The other data centers will be slow. In case of a failure, the leader selection operation will cause unpredictable performance issues. Expanding the cluster where either of these two methods is used would be difficult.

MongoDB asynchronously replicates data between the primary copy and replicas, subject to certain restrictions (e.g., replica sets can have up to 50 members but no more than seven voting members). Replica set tags can be configured and referenced in client applications to promote performance and cost-efficiency objectives.

Offers Atlas Edge Server and Atlas Device Sync for edge-to-core computing.

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.

A MongoDB query can use multiple indexes.

Based on B-tree structures, MongoDB indexes can be defined for primary and secondary key values, including compound indexes that collect on sort data on two or more fields. With few exceptions, all indexes must be kept in RAM (along with the working data set).

Indexes are stored in both memory and disk. For best performance, it is recommended to have enough memory to keep all of the indexes in memory.

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.

MongoDB Query Language (MQL) provides CRUD (create, read, update, and delete) operations tailored for document processing.  Complex operators, aggregations, and specialized operators (e.g., geospatial) are supported. Query federation supported via Atlas Data Federation (cloud offering).

MongoDB Connector for Business Intelligence supports SQL queries, translating queries and data between a MongoDB instance and third-party SQL tools. Wide range of SQL operators supported.

Aerospike Quick Look (AQL) offers SQL-like querying capabilities combined with advanced features like secondary indexing, expressions, and user-defined functions (UDFs). It integrates with popular SQL-based tools while providing a native API for developers to leverage Aerospike's full performance potential.

Aerospike recommends using its native API for optimal performance and full control over data access.

• The Aerospike API allows the implementation of specific SQL operations, such as SELECT, UPDATE, CREATE, and DELETE, with fine-grained performance control.

• Aerospike's data modeling approach aims to minimize the need for SQL constructs like JOINs to maximize performance and scalability benefits.

SQL access is available via Aerospike-built connectors, optimized for high performance with Spark and Presto/Trino. Application developers can use simple SQL with JDBC and the community-contributed JDBC Connector.

The Aerospike Spark connector can read data from Aerospike namespaces using up to 32K Spark partitions. Predicate filtering and scan-by-partition also promote strong performance.

JOINs, unions, intersections, aggregations, and other sophisticated SQL operations are fully supported. Query federation is supported, and the use of secondary indexes is supported.

Connectors for Spark, Kafka, SQL, and other technologies are available. At least some are optimized to use MongoDB’s aggregation pipeline and secondary indexes.

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.