ArangoGraph Reviews

My main use case for ArangoGraph is anomaly detection (UEBA). On our backend team, we ingest access/security  millions of logs through Kafka using Python services, parse them, and dump them into ArangoGraph. We store the data in Arango like collections USER, LOCATION, URL then edges among them like USER_ACCESS_URL, USER_ACCESS_LOCATION. 

Our detection jobs run AQL queries to find anomalies, such as impossible travel and access to risky countries. We then give each user a risk score from 0 to 100.

ArangoGraph keeps users, locations, and urls in one place. It is easy to detect  anomaly behavoiurs. And writing AQL is like writing code in Python. 

One standout feature of ArangoGraph compared to other databases is its native multi-model support.

I choose ArangoGraph over other databases because the biggest driver for us was the native multi-model support. Before this, we were considering keeping JSON logs in a standard document store and syncing the relationship data into a separate graph database such as Neo4j. Managing that dual-write architecture in production was a nightmare. With ArangoGraph, we get a document store and a graph database in one instance, and since we run our workload on GCP, having ArangoGraph handle the managed cloud deployment, sharding, and automated backup keeps our DevOps workload low.

The best features ArangoGraph offers include its native multi-model engine that combines documents, graphs, and key-value storage, eliminating polyglot persistence and dual writes. AQL is incredibly clean and intuitive, allowing seamless handling of aggregation, graph traversal, and joins without switching between SQL and MongoDB queries. Another feature I appreciate is ArangoSearch, an integrated full-text search engine that allows BM25 ranking, fuzzy search, and text matching alongside graph queries without managing a separate Elasticsearch cluster.

If I had to pick just one feature that has the biggest impact on my daily workflow, it would be the unified AQL. Writing backend services in Python or Go, or debugging anomalies in our logs, AQL simplifies my tasks because I do not have to switch between different query languages. In our old setup, tracing an issue required querying a document store first, pulling IDs into application memory, and firing a second query at a graph or search engine. With unified AQL, I write one single declarative block to filter JSON log payloads by timestamp and match specific error strings, making the process faster and simpler.

The AQL query profiler and explain tools built into ArangoGraph console are important features. When dealing with millions of log events across a sharded cluster, distributed graph traversal can get slow over the network. SmartGraphs allow us to shard our collections by service or tenant ID, keeping related nodes on the same physical machine, which keeps our queries super fast.

If I had to highlight areas where ArangoGraph could improve, I would say the learning curve and tooling for AQL are not ideal. Developers coming from a traditional SQL or document store background may find the optimization of graph traversal and memory usage challenging without proper guidance. Better automated query optimization hints or more guided error messages in the console would definitely make onboarding smoother. Another pain point is cost scaling on the managed cloud tier; running deep graph traversals on heavy data volumes can cause memory consumption to spike quickly, leading to unexpected costs as we scale up.

Having more transparent auto-scaling options or better predictive cost alerts in the managed cloud dashboard would be super helpful, as the graph query memory footprint can spike unpredictably depending on the depth of the traversal. A smarter built-in recommendation for sizing or cost optimization based on query patterns would save teams from trial and error. However, everything else has been running smoothly; I do not see many cons.

I gave it an eight out of ten because it is one of the best database solutions I have used for managing unified log streams and graph relationships without overhead. To elevate it to a solid ten, I would want to see a smoother onboarding experience for AQL with better automated query optimization hints, a more robust and responsive built-in web UI visualizer that can handle thousands of nodes during deep root cause analysis without lag, and more predictable cloud cost scaling or smarter auto-scaling recommendations on the managed tier.

I have been using ArangoGraph for more than three years as a backend database.

ArangoGraph has been extremely stable for our production workloads, managing heavy log ingestion and graph traversal efficiently.

ArangoGraph's scalability has been fantastic for our workload; as our log ingestion volume grows via Kafka, the ability to scale our cluster nodes and use SmartGraphs to shard data locally keeps our distributed queries and multi-hop traversals running smoothly without cross-network bottlenecks. The feature for bulk data import allows us to buffer data sets and import in bulk, which is efficient.

The customer support was good; I would rate it an eight out of ten.

Before ArangoGraph, we used a mix of MongoDB for document storage, Neo4j for graph relationships, and Elasticsearch for full-text search. We switched because maintaining that polyglot setup with dual writes and sync pipelines was a maintenance nightmare; consolidating everything into ArangoGraph eliminated all that glue code and made our architecture much easier to manage.

Pricing and setup were straightforward; using the managed cloud tier on GCP involved quick setup without heavy infrastructure lifting. We have definitely seen a solid return on investment by consolidating our document storage, graph traversal, and full-text search into one unified ArangoGraph cluster.

The experience with pricing, setup cost, and licensing has been good, and the support team of ArangoGraph is very supportive; it has been a great experience overall.

Before choosing ArangoGraph, we evaluated options such as Neo4j combined with MongoDB and Elasticsearch. We opted for ArangoGraph since its native multi-model engine eliminated the complexity of syncing data across multiple separate systems, and it has proven extremely stable for our production workloads, reliably handling heavy log ingestion and graph traversal.

I would rate ArangoGraph an eight out of ten overall, as it is a phenomenal database engine for our use case.

Regarding ArangoGraph's AI capabilities, I think the governance and security they have built are solid. Since we work heavily with ML anomaly detection models, having native support for vector embedding alongside graph relationships and full-text search is powerful for building knowledge graphs and handling context retrieval without needing an external vector database. From a security and governance perspective, the managed cloud tier gives us great peace of mind with features such as enterprise-grade encryption, secure VPC pairing, fine-grained access control, and automated compliance backups.

The accuracy and reliability of ArangoGraph's outputs, especially in AI and vector search aspects, are solid. It combines vector embedding directly with graph traversal and full-text search, ensuring context retrieval for our ML models remains precise. We have not encountered data hallucination or query reliability issues under heavy log ingestion.

We have deployed ArangoGraph on a public cloud as well as on-premises. For our public cloud deployment, we use GCP to deploy ArangoGraph utilizing their fully managed public cloud service.

If I could give advice to anyone considering using ArangoGraph, I would say definitely dive into it if you are tired of managing a messy multi-database stack. The native multi-model design and unified AQL will save tons of architectural headaches. Just plan your indexing and test your graph traversals early to maintain performance as your data scales.

ArangoGraph's best use case is relationship mapping, such as finding connections between entities like which user interacted with which product through which channels. Graph traversal queries make this extremely fast and intuitive.

ArangoGraph changed the way our teams think about data. Instead of thinking in tables and rows, we started thinking in relationships and connections. This mental shift improved our overall data modeling approach across the entire project. The graph traversal features were transformative; finding second and third degree relationships between entities that would have required multiple complex SQL joins was simply solved with a straightforward AQL query in ArangoGraph. This directly improved our application's recommendation logic performance.

ArangoGraph has several concrete positive impacts on our organization. The first and most significant was database consolidation; before ArangoGraph, we were running Neo4j for graph data and MongoDB for document storage separately. Replacing both with one ArangoGraph reduced our infrastructure cost by roughly 40% and eliminated the operational overhead of managing two separate database systems.

The second impact was query performance improvement; our recommendation engine querying that previously took 800 to 900 milliseconds across two databases came down to under 100 milliseconds with ArangoGraph, which is nearly a 90% improvement in our response time. This directly improved our application's user experience.

The third was developer productivity; once the team learned AQL, development speed increased noticeably. Features that required writing separate queries for graph and document data now only needed one AQL query, leading to an estimated 30 to 35% reduction in backend development time for data-related features. Finally, onboarding new team members became faster as they only needed to learn one database system instead of two, significantly saving training time.

Out of all the positive impacts, developer productivity had the biggest effect on our team's day-to-day work. The reason is straightforward; our team was small, so every hour saved in development directly translated to faster feature delivery and better product quality. Before ArangoGraph, a typical data feature required our developers to context switch consistently—writing a Cypher query for Neo4j, then switching to MongoDB query syntax for document data, and finally combining the results in the application code. That back and forth was mentally exhausting and error-prone.

After switching to ArangoGraph, that entire workflow collapsed into a single AQL query. Developers stayed in one mental context, using one query language with one database connection, and the cognitive load reduction was immediately noticeable. A feature that previously took developers two to three days to build and test across two databases now only takes about a day in ArangoGraph, which is a 30 to 35% time savings compounded across every sprint, every feature, and every developer. This also improved code quality; less glue code stitching results from multiple databases means fewer bugs, a cleaner codebase, and easier code reviews. While cost savings and performance were important, developer productivity was the change we felt most tangibly every single day.

ArangoGraph's best features include the multi-model capability, which allows it to handle graphs, documents, and key values all in a single engine, making it a huge differentiator. AQL, or ArangoGraph Query Language, is incredibly powerful; you can traverse graphs, filter documents, and aggregate data all in one query. Once learned, it feels more natural than SQL for relationship-heavy data. The Visual Graph Explorer allows you to see your entire data as a connected graph on screen, invaluable for spotting modeling issues instantly. Smart Graphs intelligently distribute graphs across cluster nodes to minimize network scope during traversals, resulting in dramatically faster query performance at scale.

In my daily work, I definitely rely on AQL, the ArangoGraph Query Language, out of all those features. Everything we did in ArangoGraph ultimately comes down to querying data, whether finding relationships between entities, filtering documents, or arranging results for our analytical pipelines. AQL is something we used every single day. Its flexibility is exceptional; an AQL query could traverse a graph, filter by document properties, and return aggregate results all at once. In a traditional SQL setup, this would have required multiple queries across multiple databases. For example, in my recommendation engine, we wrote an AQL query that started from a user node, traversed product nodes while filtering by ability and score, and returned ranked recommendations—all in one query. The power in a single statement is something I had never experienced before. While the Visual Graph Explorer was a close second in value, especially during development and debugging, AQL was what I lived in daily. That is why we almost always use AQL.

In terms of features, the most underrated aspect I wish more people knew about is Foxx Microservices. Most people who use ArangoGraph focus on the graph and multi-model capabilities, which makes sense, but Foxx surprised me when I discovered it. Foxx allows you to write custom REST APIs and endpoints directly inside the database using JavaScript. Instead of building a separate backend service to expose certain data operations, you can write the logic right inside ArangoGraph and expose it as an API. This was transformative for our project; we had certain complex graph traversal operations that needed to be exposed as endpoints, and instead of building separate Node.js services, we wrote Foxx Microservices directly in the database, significantly reducing our backend complexity and improving performance since the logic runs right where the data lives.

The first and biggest pain point I noticed was the AQL learning curve; for developers coming from an SQL background, AQL feels initially unfamiliar. There are no widely available online courses or bootcamps teaching AQL in the way that there are for SQL or even Cypher. Better structured learning resources and interactive tutorials would significantly lower the barrier to entry. The second pain point is pricing transparency; cost estimations at scale are not straightforward. When planning for infrastructure growth, it is difficult to predict exactly how costs will scale with increasing nodes, edges, and query volume. A proper cost calculator on their website would be extremely helpful. The third pain point is query optimizer limitations; for very complex multi-level graph traversals, the query optimizer sometimes makes suboptimal execution choices, requiring us to manually hint the optimizer in certain cases, which should not be necessary in a mature database platform. Finally, the ecosystem maturity is another concern; compared to MongoDB or PostgreSQL, the community and third-party tooling around ArangoGraph are still relatively small, resulting in fewer Stack Overflow answers, fewer integrations, and fewer tutorials. None of these are deal-breakers, but they reflect the growing pains of a platform that is still maturing. The core technology itself is generally excellent.

One thing I really wish ArangoGraph would improve is the Visual Graph Explorer performance. It is a fantastic feature conceptually, but when the graph grows beyond a certain size, say fifty thousand plus nodes, the explorer becomes noticeably sluggish. Rendering a large graph in the browser gets heavy, so a smarter sampling or progressive loading approach would make it much more usable at scale. Another small but frustrating issue is the error messaging in AQL; when a query fails, the error messages can sometimes be cryptic and unhelpful. As a developer, you often spend more time debugging the error messages than actually fixing the query. More descriptive and actionable error messages would save a lot of developer frustration. Lastly, I would also appreciate a dark mode option for the UI; it sounds minor, but developers spend long hours in the interface, and a dark mode option is something the community has been requesting for a long time. These are not critical issues, but they are the type of polish that separates a good product from a truly great one.

A few more improvements I have not mentioned include better GraphQL support, as ArangoGraph has some GraphQL integration, but it is not seamless. Many modern applications are built on GraphQL, and having first-class GraphQL support would make ArangoGraph much more accessible to frontend developers who are not familiar with AQL. Improved data import tools are also needed; migrating existing data into ArangoGraph from other databases like PostgreSQL or MongoDB has been more manual than expected. A proper migration wizard with schema mapping and data transformation built in would significantly reduce onboarding friction. Lastly, better Kubernetes integration would benefit teams running hybrid or on-premises deployments, with native Kubernetes operators being more mature and better documented, as we have seen several community complaints regarding this during our research phase. These improvements would really elevate ArangoGraph from a great database to a complete graph intelligence ecosystem.

I have been using ArangoGraph for about one year, primarily for a data pipelines project where we need a graph-based relationships mapping between entities.

My practical advice for anyone considering ArangoGraph is to think in graphs before starting. Before writing a single line of code or creating any collections, sit down with your team and map out your entities and relationships on a whiteboard. ArangoGraph rewards good upfront data modeling; a poorly designed schema is very hard to fix later. Secondly, invest seriously in learning AQL early; do not underestimate this. AQL is the key that unlocks everything ArangoGraph can do, so spending the first week learning AQL syntax and patterns before diving into anything else will pay dividends throughout the entire project. Start with an ArangoGraph free trial; do not commit to a paid plan until you have run real queries against your actual data. The trial is generous enough to validate your use case properly. Also, use the Visual Graph Explorer during development; it sounds like a nice-to-have but is actually extremely valuable for catching data modeling mistakes early, before they become expensive product problems. Join the ArangoGraph community forum as the official documentation has gaps, especially for advanced features; the community fills those gaps remarkably well. Lastly, do not use ArangoGraph for everything; it excels at relationship-heavy data, while a traditional relational database is still better for purely transactional workloads. Use the right tools for the right job.

A few final thoughts I would share are that ArangoGraph is genuinely one of the most underappreciated databases in the market today. The multi-model approach, the power of AQL, and the unique features like Foxx Microservices put it in a league of its own. However, because it is not backed by a hyperscaler like AWS or Google, it does not get the attention it deserves. The timing for ArangoGraph could not be better with knowledge graphs becoming increasingly important for AI applications like RAG pipelines and LLM grounding. ArangoGraph is perfectly positioned to become a critical piece of modern AI infrastructure. For Indian developers and startups, especially, ArangoGraph with AWS Mumbai region deployment is an excellent combination of low latency, reasonable pricing at startup scale, and zero infrastructure overhead, making it very attractive for lean teams. I hope this review helps other technology buyers make informed decisions; ArangoGraph has real strengths and real areas for improvement, and I have aimed to represent both honestly throughout this interview. My overall rating for ArangoGraph is eight out of ten.

My main use case for ArangoGraph is to build a bridge between us and the client to showcase applications such as social networks, recommendation engines, fraud detection, network and dependency analysis, knowledge graphs, and graph RAG applications, as well as supply chain and logistics tasks. I use the enterprise edition, which provides community and open-source options.

Out of all those use cases, the RAG solution is the project that stands out to me as especially interesting and challenging, as it provides the highest impact. This is currently one of the hottest use cases. Imagine an enterprise chatbot that, instead of storing documents in isolated chunks, works with AI to understand who owns a service, which projects depend on it, who the manager is, and what incidents have occurred recently. These things can be easily tracked from ArangoGraph tools. Instead of storing documents separately, we create a knowledge graph that maps employees to projects, applications to services they depend on, and everything else properly. This delivers significant impact on enterprise-grade AI assistants and graphical RAG orchestration and architecture.

Those improvements show up for my team and client in that managers are able to track who is doing what easily within a group. Additionally, during discovery sessions with clients, we previously spent considerable time understanding requirements and providing feedback before scheduling follow-up sessions. Instead, we can now collect everything instantly in an organized place and speak back to the client immediately.

ArangoGraph has positively impacted my organization by enabling discovery sessions that we can close within two weeks instead of keeping them open for a month, reducing delays by nearly 50 percent. This has also led to cost savings for my team and client because we can get statements of work signed instantly and start work without delay.

The best features ArangoGraph offers are the graphical database, document database, key-value database, and search capabilities, all unified under a single query language like AQL on one platform.

Out of those features, the one my team uses most is the key-value database, which helps us map all discovery events in a schedule or proper manner more effectively.

The features that stand out to me about ArangoGraph include identity and governance, zero-trust analysis, threat hunting, and privilege escalation detection. These can be easily graphed over our database, allowing us to track them efficiently. Although these may seem small, they help non-technical staff carefully review the information.

ArangoGraph can be improved in terms of pricing, as enterprise pricing is quite hefty.

I would also note that the AI feature in the UI can be improved. I find the accuracy and reliability of ArangoGraph's output to not be exactly as expected, though some issues can be managed.

I have been using ArangoGraph for beyond three years.

ArangoGraph's scalability is highly rated by us. Day by day, our workloads continue to increase, and ArangoGraph still displays the graph without any redundancy.

Customer support for ArangoGraph is great, and their response is quite quick.

Before ArangoGraph, we used Neo4j. We switched from Neo4j to ArangoGraph because companies typically choose ArangoGraph over Neo4j when they want more than just a graph database. ArangoGraph offers multi-model capabilities versus pure graph functionality, combining two to three types of data to prepare a graph accordingly. ArangoGraph supports graph data, documents, JSON files, key-value data, search capabilities, and value-based AI workloads. This multi-model approach is why enterprises choose ArangoGraph.

If others are looking into using ArangoGraph, my advice is that if they want to input different data and group it to see statistics, they can confidently choose ArangoGraph. I would rate this product a 7 out of 10.

A specific example of how I used ArangoGraph for supply chain visibility involved having information about buyers and suppliers throughout the world, creating supply chain visibility to connect these dots, which I accomplished using ArangoGraph.

This involved the import and export of custom data throughout the world.

If I had to use other providers for the same tasks, the general cost would be higher, and since ArangoGraph operates somewhat like SQL, it allows me to use my current pipeline as it is, which has been helpful in speeding up the process.

When it comes to valuable graph-based analytics, I found tools for pointing out concentrated risk, identifying bridges in the network, performing risk analysis, and achieving tier visibility to be particularly useful.

In terms of accuracy and reliability of output related to ArangoGraph's AI capabilities, I find it reliable, but it lacks domain-specific knowledge and insider guardrails from the company using ArangoGraph, which is something that should be added on the company's side.

Regarding ArangoGraph's AI capabilities, I don't feel I have any issues with its governance and security.

ArangoGraph is deployed in my organization currently using public cloud.

I use GCP as my cloud provider.

My advice for those looking into using ArangoGraph is that it depends on their use case and finances. First, I recommend exploring other providers and finding the best fit, which depends on factors like workload, pricing, scalability, and security.

My main use case for ArangoGraph is to build a customer graph in order to create a relation between customer and end users. I connect all the user related data together between the orders that they made from the supplier and customers.

The user interface is the best feature that ArangoGraph offers. The simplicity of the user interface is very appealing to me. ArangoGraph has positively impacted my organization as we made a 30% saving in order to build this graph. The savings were achieved mostly through time cost.

I think that ArangoGraph can be improved.

I have been using ArangoGraph for six months.

I advise others looking into using ArangoGraph to speed up the development using all the features that the product provides. I gave this review a rating of 8.