logo-StatusNeo
d

WE ARE EXPERTS IN TECHNOLOGY

Let’s Work Together

Image Alt

StatusNeo

Lets Compare – Amazon Neptune vs ArangoDB vs Cassandra vs Cosmos DB vs Neo4j

Key Difference :-

NameAmazon Neptune  ArangoDB  Cassandra  Microsoft Azure Cosmos DB  Neo4j  
DescriptionFast, reliable graph database built for the cloudNative 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 serviceScalable, ACID-compliant graph database designed with a high-performance distributed cluster architecture, available in self-hosted and cloud offerings
Primary database modelGraph DBMS RDF storeDocument store Graph DBMS Key-value store Search engineWide column storeDocument store Graph DBMS Key-value store Wide column storeGraph DBMS
Cloud-based only yesnonoyesno
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 languageC++JavaJava, Scala
Server operating systemshostedLinux
OS X
Windows
BSD
Linux
OS X
Windows
hostedLinux 
OS X
Solaris
Windows
Data schemeschema-freeschema-free schema-freeschema-freeschema-free and schema-optional
SQL nonoSQL-like SELECT, DML and DDL statements (CQL)SQL-like query languageno
APIs and other access methodsRDF 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 languagesC#
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 noJavaScriptnoJavaScriptyes 
TriggersnonoyesJavaScriptyes 
Partitioning methods noneSharding Sharding Sharding yes using Neo4j Fabric
Replication methods Multi-availability zones high availability, asynchronous replication for up to 15 read replicasSource-replica replication with configurable replication factorselectable replication factor yes Causal Clustering using Raft protocol 
MapReduce nono yeswith Hadoop integration no
Consistency concepts Immediate ConsistencyEventual 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 nonoyes 
Transaction concepts ACIDACIDno Multi-item ACID transactions with snapshot isolation within a partitionACID
Concurrency yesyesyesyesyes
Durability yes yesyesyesyes
In-memory capabilities no
User concepts Access rights for users and roles can be defined via the AWS Identity and Access Management (IAM)yesAccess rights for users can be defined per objectAccess rights can be defined down to the item levelUsers, 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.

SQLAQL
databasedatabase
tablecollection
rowdocument
columnattribute
table joinscollection joins
primary keyprimary key (automatically present on _key attribute)
indexindex

Add Comment