Key Features

  • Multi-Model Database
    Model your data using flexible combinations of key-value pairs, documents and graphs. If you are used to Domain-Driven Design you will love the way to model the data according to your domain without any need for a ORM or the like.

    json documents

    JSON Documents

    ArangoDB is a “document-oriented database”; it basically provides access to documents which are stored in collections. If you are new to NoSQL databases, think of documents as rows in a non-normalized table and of collections as tables for the time being. There is no need to define a schema beforehand. Therefore these kind of databases are often called schemaless.

    graph store


    Documents in ArangoDB are uniquely identified by keys, allowing key/value storage. They can be connected, allowing you to treat and query them as graphs. So, you can chose which model fits best to your needs or combine the models in a convenient way.

    Documents can be very simple or as complex as you like, they can be nested and different types of indexes are supported.

    Most other NoSQL databases don’t support transactions at all or at most single-document transaction semantic. ArangoDB even supports transactions with as many documents involved as you need and even across collections.



    A specialized binary data file format is used for disk storage. Structure data is stored separately from the documents and shared between documents with the same structure (i.e., with the same attribute names and types). Sharing the structure data between multiple documents greatly reduces disk storage space and memory usage for documents.

  • Sharding
    The following figure shows a basic sharding scenario: The application has one very large collection called “products”. This collection is too large to stay on one server, so it is sharded over three servers by a user defined or automatically chosen key. For simplicity of the example there is only one coordinator who dispatches requests and returns responses, you can configure multi independent coordinators to distribute load as well. The coordinator analyzes the query/operation and decides which parts of the cluster to interact with.



    Setting up a ArangoDB cluster for sharding is accomplished in a few minutes. If you want to dive deeper into the subject, we recommend the technical overview.

    You can set up slaves for each part of the cluster and use them to back up the data and as a replacement in case one part of the cluster stops working. In the “Easy failover and recover” release we will provide hot failover as well as dynamic changes to the cluster layout.

    One main goal for sharding in ArangoDB is to keep things as easy as possible. The admin interface may be run from a server within your cluster, another server or even your local machine not exposed to the internet at all. We have dialogs to set up a cluster, a dashboard with statistics on health and RAM usage and options to start and turn down the cluster.

    Per default the cluster uses the internal _key attribute as a sharding key. Alternatively you can choose one or more attributes of the collection as user defined sharding key. In case you want to use a unique index as a secondary index that attribute must be used as a sharding key.

    For more detailed information you can look at the Whitepaper for Sharding

  • Foxx – Extensible through JS
    ArangoDB can be extended using JavaScript. The JavaScript-code is executed directly in the database using Google’s lightning fast V8 engine. This can be useful in many different situations:

    Foxx architecture

    • You want to execute data-intensive operations directly in the database.
    • You want to aggregate data from multiple queries into a single response.
    • You want to implement your own graph traversal algorithm, touching millions of node.
    • You want to modify many documents in a multi-collection transaction.

    ArangoDB can respond arbitrary HTTP requests directly through the Foxx application framework. This makes ArangoDB a combined database/application server. There is a permission system included. Foxx makes it easy to create API for single page application.

    If you want to learn more about Foxx, checkout Foxx for more information.

  • Powerful querying with AQL
    AQL (ArangoDB Query Language) is a declarative query language similar to SQL. Other options are REST and querying by example.

    Many NOSQL databases suffer from rather limited query facilities compared to SQL, e.g. they do not support joins. This usually leads to lots of work in the application code where you have to stick everything together by yourself. ArangoDB does better.

    ArangoDB does not support pure SQL, as SQL is too limited to cover the different data models in ArangoDB. For example, a nested list structures inside a document or a graph traversal. Following is an example how you can work with subqueries.

    This is easier and more structured than the same procedure with SQL.

    There is no way to query such structures as the graph traversal in standard SQL, and deviating from standard SQL does not make much sense. This is why we came up with AQL. AQL supports joins, graph queries, list iteration, results filtering, results projection, sorting, variables, grouping, aggregate functions, unions, and intersections.

    Here is an example for a group by criteria in AQL:

    ArangoDB offers two ways to access graph data: “Path traversals” are small programs written in JavaScript – this general approach is very similar to Neo4j where you write the traversals in Java.
    For standard use cases, programming might be too much effort. So ArangoDB’s query language AQL supports graphs as well.

  • Joins, Joins, Joins
    Using documents or aggregates in a schemaless document database is a big plus of NoSQL. Sometimes it would be nice to combine data from different collections as easily as in SQL. ArangoDB’s powerful query language AQL offers you just this.

    As an example lets find all user older than thirty and return their data together with the city data.

    You can even aggregate data without the need of complicated map-reduce tasks. This would return group users by age and return their names.

  • Strong Consistency
    Relational databases have a long history of strong consistency guarantees with ACID transaction semantics. In the NoSQL world, these guarantees have often been sacrificed on the altar of performance and scalability.
    However, recently people have realized again how much ACID can simplify application development.

    Transactions in ArangoDB are atomic, consistent, isolated, and durable (ACID).

    ArangoDB support the following ACID properties:

    • atomicity: Makes transactions either complete in their entirety or have no effect at all.
    • consistency: Ensures that no constraints or other invariants will be violated during or after any transaction.
    • isolation: Will hide the modifications of a transaction from other transactions until the transaction commits.
    • durability: Makes sure that operations from transactions that have committed will be made persistent. The amount of transaction durability is configurable in ArangoDB, as is the durability on collection level.
    These guarantees are even available if you modify many documents from different collections.

Comments are closed.