# Self-hosting ArangoDB: one database for graph, document, and vector search

> Source: <https://dev.to/greatsage_sh/self-hosting-arangodb-one-database-for-graph-document-and-vector-search-1735>
> Published: 2026-07-28 18:05:32+00:00

Most GraphRAG or knowledge-graph setups I've seen end up as three separate systems duct-taped together: Neo4j (or similar) for the graph, Qdrant or pgvector for embeddings, and Postgres or Mongo for the actual document data. Three query languages, three connection pools, three things to back up and monitor. It works, but it's a lot of moving parts for what's conceptually one data problem.

ArangoDB is a multi-model database that does graph, document, and vector search natively, behind one query language (AQL). Instead of joining across systems in application code, you write one query that touches all three.

A traversal query - "find everything two hops out from this node" - reads like this in AQL:

```
FOR v, e, p IN 1..2 OUTBOUND 'products/laptop' GRAPH 'store_graph'
  RETURN { vertex: v, path: p }
```

No separate graph engine, no export/import step to sync it with your document store - the products, the edges, and (if you're doing similarity search over embeddings) the vectors all live in the same collections.

The upstream image is `arangodb/arangodb`

, official, actively maintained:

```
docker run -e ARANGO_ROOT_PASSWORD=changeme -p 8529:8529 -v arangodb_data:/var/lib/arangodb3 arangodb:latest
```

That gets you the web UI and the HTTP/AQL API on port 8529. The volume mount matters - without it your graph disappears on every container restart.

I maintain a one-click Railway template for it if you'd rather not manage the container yourself (auth preconfigured, root password auto-generated, persistent volume already wired up). Full disclosure: I get a kickback if you deploy through it: [https://railway.com/deploy/arangodb-graph-database-for-ai?referralCode=Z1xivh&utm_medium=integration&utm_source=template&utm_campaign=devto](https://railway.com/deploy/arangodb-graph-database-for-ai?referralCode=Z1xivh&utm_medium=integration&utm_source=template&utm_campaign=devto) - but the raw `docker run`

above is functionally the same image, so there's no capability difference either way.

Where ArangoDB actually earns its keep is when you need graph traversal, vector similarity, and document queries in the *same* pipeline - recommendation engines, fraud detection graphs, knowledge-graph RAG - and gluing three separate databases together is the thing you're trying to avoid.

Upstream docs: [https://www.arangodb.com/docs/](https://www.arangodb.com/docs/) - AQL reference: [https://www.arangodb.com/docs/stable/aql/](https://www.arangodb.com/docs/stable/aql/)