ArangoDB: a multi-model database for documents, graphs and key-values

What ArangoDB solves, and who it is aimed at

Most applications start with one data model and grow a second one beside it. The user table lives in a relational store, the activity feed in a document store, the recommendation graph in a graph database, and the glue between them is application code plus a queue. ArangoDB's pitch is that you keep all three shapes in one engine. Every node in a graph is a JSON document, relationships are stored as edges, and the same collections answer key-value lookups. The README describes this as a "native multi-model database with flexible data models for documents, graphs, and key-values".

The audience is therefore teams whose data is genuinely connected and whose schema is not fixed. A fraud graph, a product catalogue with cross-sell edges, an identity graph: these are workloads where a join across four tables is normal and where the shape of the records changes between customers. ArangoDB is written in C++ and the README claims it "can handle even very large datasets efficiently", which is a claim about the engine, not a benchmark you should take on faith. If your workload is a single collection of flat records with no relationships, the multi-model part buys you nothing and you pay for it in operational complexity.

Documents, edges and AQL in one engine

The mechanism is easier to follow if you separate storage from query. Storage is collections of JSON documents. A graph is not a separate subsystem: it is two document collections, one for vertices and one for edges, where an edge document carries the _from and _to fields pointing at vertex documents. That is why the README can say every graph node is a JSON document and that data is "easily imported from your existing document database".

Querying happens through AQL, described in the README as a "powerful query language" covering CRUD, filters, aggregations, joins, graph traversals and ranked full-text search. AQL is SQL-like but reads documents rather than rows, and a traversal is a first-class construct rather than a recursive CTE. ArangoSearch is the second mechanism: an indexing and ranking engine built into the server rather than bolted on, which is what makes the full-text and ranking parts of AQL possible without shipping data to a separate search cluster.

On top of that sit the deployment shapes. A single server is the simple case. A cluster shards collections across machines, and the README lists EnterpriseGraphs, SmartGraphs and SmartJoins as the features that make graph sharding efficient, plus OneShard for combining single-server performance with cluster resilience. Note where those names sit: the README presents them under scalability features and describes the Enterprise Edition as the one "for commercial use and without a dataset size limit", so the sharding story and the licence story are entangled.

Installing ArangoDB and running a first graph query

The README gives two paths. You can download and install a package from the downloads page, then start the server with the arangod binary if the installer did not already do it. Or you can skip the installer entirely and run the official container, which is the fastest way to see whether the query language fits your mental model.

The Docker command below is copied from the README. It starts a detached container, sets the root password through ARANGO_ROOT_PASSWORD, and publishes the server's default port 8529 on the host.

docker run -d -e ARANGO_ROOT_PASSWORD=test123 -p 8529:8529 arangodb

After that, the README says to point your browser at http://127.0.0.1:8529/ and log in as root with the password you set. You should see the web interface, which the README lists as one of the core features alongside the command-line tools. That interface is where you create your first collection and run AQL without writing any client code.

The README does not document the AQL syntax itself; it points to the documentation site and to ArangoDB University for that. So the honest next step is to open the web interface, create a collection, insert a document, and read the query reference before you design a schema around traversals. What the README does establish is the shape of the thing: one server process, one port, one query language across all three data models.

Where ArangoDB is the wrong choice

The multi-model design is a bet that you will use more than one model. If you will not, you are carrying a graph engine and a search engine you never call, and every upgrade, backup and capacity decision now involves a larger surface than a single-model store would have. That is not a defect, but it is a real cost, and the README does not pretend otherwise: it sells the combination, not the individual pieces.

The second limitation is the licence boundary. The README states that ArangoDB is available in a free Community Edition and an Enterprise Edition "for commercial use and without a dataset size limit". Read that carefully. Features that matter at scale, including EnterpriseGraphs, SmartGraphs, SmartJoins, OneShard, Hot Backups, Encryption 360, Data Masking and Auditing, are listed in the README under scalability features rather than under core features, which is a strong hint about which edition they belong to. The repository's LICENSE file is marked NOASSERTION here, and a LICENSES-OTHER-COMPONENTS.md file sits at the top level, so the licence terms are not a single line you can read off the README. Verify them against the actual files before you plan a commercial deployment.

The third is operational. A cluster with sharding and replication is more moving parts than a single-node database, and the README's claim of "automatic failover" and "horizontal scalability" describes capability, not a difficulty level. Teams without someone who owns database operations should start on the single server and stay there until the data volume forces the question.

ArangoDB compared with Neo4j and MongoDB

The two comparisons people search for are ArangoDB vs Neo4j and ArangoDB vs MongoDB, and the difference in each case is the same axis: how many models live in one engine.

Neo4j is a graph database first. Its storage and query language are built around traversals, and it does not present itself as a document store or a key-value store with a unified query language. If your workload is almost entirely graph traversal and you want the engine tuned for exactly that, a dedicated graph database is the more focused tool. ArangoDB's counter-argument is that real applications mix traversal with document filtering and aggregation, and that doing both in one AQL query avoids exporting subgraphs to application code.

MongoDB is a document database first. Documents and aggregation are the centre, and graph operations are not the primary abstraction. If your data is documents with occasional references, and you resolve those references in application code or with lookups, MongoDB is the simpler fit and its ecosystem is larger. ArangoDB's counter-argument is the same as against Neo4j, from the other direction: when the references become multi-level traversals, a document store makes you write the traversal yourself.

Neither comparison is settled by feature lists. The question to ask is how many of your queries would change shape if the second model disappeared.

Maintenance, releases and what to verify before upgrading

The repository is not archived and the last push was on 2026-09-21, so the codebase is being worked on. That is the extent of what the available facts support about maintenance; there is no release history in the project's own listing, and the README points to the Release Notes in the documentation for what changed in each version rather than listing versions itself.

For upgrade planning, the repository layout is the useful signal. There is a CHANGELOG at the top level, an ARANGO-VERSION file, a VERSIONS file, a Documentation directory and an Installation directory. The README does not document rollback, and it does not describe a supported downgrade path, so the CHANGELOG and the release notes are where you would look for breaking changes before moving a production cluster.

Licensing needs the same care. The LICENSE file is present but the repository metadata reports NOASSERTION, and LICENSES-OTHER-COMPONENTS.md exists because the server bundles third-party components. The README distinguishes a Community Edition from an Enterprise Edition for commercial use. Which terms apply to your deployment is a question for the licence files and, if the answer affects revenue, for your legal team; nothing in the README settles it.

Editorial conclusion

Adopt ArangoDB when your queries need to walk relationships and your documents do not fit a fixed schema, and you are willing to run a C++ server with its own query language. Do not adopt it if you only need a key-value cache or a plain document store, because a single-model system will be simpler to operate. Before committing, verify which licence file applies to the edition you want, confirm whether the sharding and backup features you need sit in Community or Enterprise, and check the CHANGELOG for the changes between the version you install and the one you plan to run in production.

Frequently asked questions

Official sources

1. arangodb/arangodb on GitHub
2. Issues
3. Project website
4. README