Lets Compare – Amazon Neptune vs ArangoDB vs Cassandra vs Cosmos DB vs Neo4j
Key Difference :-
|Name||Amazon Neptune||ArangoDB||Cassandra||Microsoft Azure Cosmos DB||Neo4j|
|Description||Fast, reliable graph database built for the cloud||Native multi-model DBMS for graph, document, key/value and search. All in one engine and accessible with one query language.||Wide-column store based on ideas of BigTable and DynamoDB||Globally distributed, horizontally scalable, multi-model database service||Scalable, ACID-compliant graph database designed with a high-performance distributed cluster architecture, available in self-hosted and cloud offerings|
|Primary database model||Graph DBMS RDF store||Document store Graph DBMS Key-value store Search engine||Wide column store||Document store Graph DBMS Key-value store Wide column store||Graph DBMS|
|DBaaS offerings||ArangoDB Oasis –The Managed Cloud Service of ArangoDB. Oasis provides fully managed, and monitored cluster deployments of any size, with enterprise-grade security. Get started for free and continue for as little as $0,21/hour.||• Aiven for Apache Cassandra: Fully managed, open source NoSQL database specifically designed to be highly available, performant, and scalable. Astra DB: Multi-cloud DBaaS built on Apache Cassandra.||Neo4j Aura: Neo4j’s fully managed cloud service: The zero-admin, always-on graph database for cloud developers.|
|Implementation language||C++||Java||Java, Scala|
|Server operating systems||hosted||Linux|
|Data scheme||schema-free||schema-free||schema-free||schema-free||schema-free and schema-optional|
|SQL||no||no||SQL-like SELECT, DML and DDL statements (CQL)||SQL-like query language||no|
|APIs and other access methods||RDF 1.1 / SPARQL 1.1|
TinkerPop Gremlin 3.3
Graph API (Gremlin)
GraphQL query language
Java & SpringData
JSON style queries
|Proprietary protocol |
Graph API (Gremlin)
RESTful HTTP API
Cypher query language
RESTful HTTP API
Spring Data Neo4j
|Supported programming languages||C#|
MongoDB client drivers written for various programming languages
|Partitioning methods||none||Sharding||Sharding||Sharding||yes using Neo4j Fabric|
|Replication methods||Multi-availability zones high availability, asynchronous replication for up to 15 read replicas||Source-replica replication with configurable replication factor||selectable replication factor||yes||Causal Clustering using Raft protocol|
|MapReduce||no||no||yes||with Hadoop integration||no|
|Consistency concepts||Immediate Consistency||Eventual Consistency |
OneShard (highly available, fault-tolerant deployment mode with ACID semantics)
|Causal and Eventual Consistency configurable in Causal Cluster setup|
Immediate Consistency in stand-alone mode
|Transaction concepts||ACID||ACID||no||Multi-item ACID transactions with snapshot isolation within a partition||ACID|
|User concepts||Access rights for users and roles can be defined via the AWS Identity and Access Management (IAM)||yes||Access rights for users can be defined per object||Access rights can be defined down to the item level||Users, roles and permissions. Pluggable authentication with supported standards (LDAP, Active Directory, Kerberos)|
What you can’t do with MongoDB
- Multi-model: MongoDB is a single-model document database. It does not support any other data models. If your application requires a graph or key/value store, you would have to use a second database technology to support it. Being multi-model, ArangoDB allows you to not only use one database for both, but run ad-hoc queries on data stored in different models.
- Joins: Using and scaling joins over different collections and instances is not supported by MongoDB (scalability depends on the use case).
- Declarative Query Language: MongoDB uses JSON syntax for queries. It does not support a declarative query language. By contrast, ArangoDB developed its own SQL-like query language (AQL) for complex queries, allowing the combination of access patterns in a single query
- Complex Transactions: Use complex transactions to span multiple documents and collections, or to run aggregations. Complete Isolation in the cluster available
ArangoDB is cluster ready for document, key/value and even for graph-models. With ArangoDB 3.x releases further improvements are being made for performant cluster usage with graphs.
ArangoDB is perfectly suitable for high-availability, high-performance or any other use case a document store might be challenged with.
By reducing development effort and enabling data-model flexibility, ArangoDB is designed for fast development and easy scaling. With the Foxx Microservices Framework, you can build production-ready session services within minutes.
What you can’t do with Neo4j
ArangoDB offers the same functionality as Neo4j with more than competitive performance, plus several additional features:
- Multi-Model: Neo4j is a single-model graph database. It does not support any other data models. If your application requires a document or key/value store, you would have to use a second database technology to support it. Being multi-model, ArangoDB allows you to not only use one database for everything,but run ad hoc queries on data stored in different models.
- Scalability: Scaling graph collections over many instances is technically a hard task. But with ArangoDB it is possible to minimize the network-hop problem and run queries highly efficient even against distributed graph data. Neo4j does not support this.
- Performance: In ArangoDB you can use the same collection for a graph and for a document query without performance losses. ArangoDB showed competitive or even better performance.
- Operational costs: ArangoDB can be used for a broad range of use cases and reduces the number of storage products in your technology stack.
Scalability needs and ArangoDB
ArangoDB is cluster ready for graphs, documents and key/values. ArangoDB is suitable for e.g. recommendation engines, personalization, Knowledge Graphs or other graph-related use cases. ArangoDB provides special features for scale-up (Vertex-centric indices) and scale-out (SmartGraphs).
What you can’t do with Cassandra
- Multi-model: Cassandra is a partitioned row-store database. It does not support any other data model. If your application requires a graph or key/value store, you would have to use a second database technology like Titan or DataStax Enterprise Graph to support graphs, thereby adding complexity and costs. Being native multi-model, ArangoDB allows you to use one database for both and also run queries efficiently on data stored in different models.
- Unified Query Language: ArangoDB Query Language (AQL) supports all three data models (k/v, document, graph) with their respective data access patterns (Projections, Joins, Traversals, more). In addition, querying special data types like text or geo-spatial is natively supported by AQL. All data models and data types can be freely combined in a single AQL query. To do the same in Cassandra, one would have to learn CQL and Gremlin for graphs.
- Joins: Also various join operations are supported natively in AQL. ArangoDB even supports join operations at scale with the Satellite Collection feature. With Cassandra, these operations are not possible natively and have to be done client-side with all its security and performance impacts.
- Complex Transactions: Cassandra does not support ACID transactions. With ArangoDB, developers can use complex transactions to span multiple documents and collections, or to run aggregations. ArangoDB supports multi-document & multi-collection transactions (single instance; single document transactions in cluster setting).
- Scalability needs and ArangoDB: ArangoDB is cluster-ready for each model and multi-model usage. Unlimited scale-up capabilities thanks to C++ core balanced with scale-out. ArangoDB cluster architecture supporting independent scaling for serving high read/writes volumes and data storage, if needed.
- Lower TCO: Knowing a multi-model database means applying the same knowledge to diverse use cases and lets developers move much faster. ArangoDB can be used for a broad range of different use cases with native multi-model approach and thereby simplify the needed tech stack and operational footprint.
SQL / AQL – Comparison
The ArangoDB Query Language (AQL) is similar to the Structured Query Language (SQL) in its purpose. Both support reading and modifying collection data, however AQL does not support data definition operations, such as creating and dropping databases, collections and indexes.
Though some of the keywords overlap, AQL syntax differs from SQL. For instance, the SQL
WHERE and AQL
FILTER clauses are equivalent in that they both define conditions for returning results. But, SQL uses predefined sequence to determine where the
WHERE clause must occur in the statement. In AQL, clauses execute from left to right, so the position of a
FILTER clause in the query determines its precedence.
Despite such differences, anyone with an SQL background should have no difficulty in learning AQL. If you run into any problems, we have a table below showing SQL functions and commands with their AQL equivalents.Comparing Relational DBs to multi-model ArangoDB. Get the White Paper
Below is a table with the terms of both systems.
|table joins||collection joins|
|primary key||primary key (automatically present on |