StatusNeo

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
Cloud-based only	yes	no	no	yes	no
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 OS X Windows	BSD Linux OS X Windows	hosted	Linux  OS X Solaris Windows
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	AQL Foxx Framework Graph API (Gremlin) GraphQL query language HTTP API Java & SpringData JSON style queries VelocyPack/VelocyStream	Proprietary protocol  Thrift	DocumentDB API Graph API (Gremlin) MongoDB API RESTful HTTP API Table API	Bolt protocol Cypher query language Java API Neo4j-OGM  RESTful HTTP API Spring Data Neo4j TinkerPop 3
Supported programming languages	C# Go Java JavaScript PHP Python Ruby Scala	C# C++ Clojure Elixir Go Java JavaScript (Node.js) PHP Python R Rust	C# C++ Clojure Erlang Go Haskell Java JavaScript  Perl PHP Python Ruby Scala	.Net C# Java JavaScript JavaScript (Node.js) MongoDB client drivers written for various programming languages Python	.Net Clojure Elixir Go Groovy Haskell Java JavaScript Perl PHP Python Ruby Scala
Server-side scripts	no	JavaScript	no	JavaScript	yes
Triggers	no	no	yes	JavaScript	yes
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  Immediate Consistency OneShard (highly available, fault-tolerant deployment mode with ACID semantics)	Eventual Consistency Immediate Consistency	Bounded Staleness Consistent Prefix Eventual Consistency Immediate Consistency  Session Consistency	Causal and Eventual Consistency configurable in Causal Cluster setup Immediate Consistency in stand-alone mode
Foreign keys	yes	yes	no	no	yes
Transaction concepts	ACID	ACID	no	Multi-item ACID transactions with snapshot isolation within a partition	ACID
Concurrency	yes	yes	yes	yes	yes
Durability	yes	yes	yes	yes	yes
In-memory capabilities			no
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
• Extensibility: Additionally, ArangoDB allows you to use existing or run your own data-centric microservices in a dedicated JavaScript framework: Foxx.

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.
• Extensibility:Use existing data-centric microservices or run your own in a dedicated JavaScript framework within ArangoDB, providing a single API call for complex graph traversals.
• 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.
• Extensibility: Use existing data-centric microservices or run your own in a dedicated JavaScript framework Foxx within ArangoDB, providing e.g. a single API call for complex graph traversals.
• 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.

SQL	AQL
database	database
table	collection
row	document
column	attribute
table joins	collection joins
primary key	primary key (automatically present on _key attribute)
index	index