iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
There was no overall winner in Ahmed Amer’s 2026 comparison of five managed graph databases. Memgraph was fastest on the tested short traversals and lookups; Neo4j AuraDB was fastest on a full-graph citation aggregation; and ArangoDB’s mixed-workload throughput barely changed as concurrency rose from 10 to 40 clients. Those are results from one free-tier/trial setup—not a general ranking of the database engines.
What did the benchmark compare?
Amer’s article, posted August 27, 2026, compared CognoDB Cloud, Neo4j AuraDB, Memgraph Cloud, FalkorDB Cloud, and ArangoDB Oasis. Each service ran against the same logical dataset and query workloads, driven from one client machine. The instances were free-tier or trial deployments, not resource-matched systems.
The dataset was SNAP’s cit-HepTh high-energy-physics theory citation network: 27,770 papers and 352,807 directed citation edges, covering January 1993 through April 2003. It was represented as Paper nodes connected by CITES relationships. Because the source data did not have a second attribute for filtered lookups, the benchmark added a synthetic bucket = id % 100 property. Stanford SNAP’s dataset page describes the graph; its cited provenance includes publications from 2003 and 2005.
Recommended Free Tools
The workloads covered ingestion, one-, two-, and three-hop traversals, primary-key and indexed/filtered lookups, a full-graph citation aggregation returning the top 20 papers, and a mixed workload with 80% reads and 20% writes. Read tests used 10 warm-up iterations followed by 100 measured iterations. Concurrent mixed tests ran for 10 seconds at each client count.
#1 Best Overall
Which database was “best” for each measured task?
The latency figures below are medians (p50) reported by Amer’s 2026 benchmark. Lower latency is faster. They describe this dataset, service configuration, client, and deployment—not performance on other workloads or tiers.
One-hop traversal
| Service | Reported p50 latency |
|---|---|
| Memgraph Cloud | 69.4 ms |
| Neo4j AuraDB | 77.4 ms |
| CognoDB Cloud | 139.9 ms |
| ArangoDB Oasis | 173.8 ms |
| FalkorDB Cloud | 193.0 ms |
Memgraph had the lowest reported one-hop median. The article also reports that Memgraph led the tested traversal and lookup queries overall, but the available results here do not provide individual figures for every traversal depth or lookup type. That means the one-hop values should not be treated as a complete ranking of all those queries.
Rank #2
Full-graph top-20 citation aggregation
| Service | Reported p50 latency |
|---|---|
| Neo4j AuraDB | 185.2 ms |
| Memgraph Cloud | 266.7 ms |
| FalkorDB Cloud | 402.0 ms |
| CognoDB Cloud | 1,799.1 ms |
| ArangoDB Oasis | 4,058.0 ms |
Neo4j AuraDB led this aggregation even though Memgraph led the one-hop traversal. The change in ranking is the central practical lesson: performance depends on query shape, so a result for traversing from a node does not predict the result for scanning and aggregating the whole graph.
How did throughput change with concurrency?
The benchmark’s mixed workload combined 80% reads with 20% writes. The table shows the reported throughput at 10 and 40 clients; the final column is the approximate increase calculated from those reported values.
Rank #3
| Service | 10 clients | 40 clients | Approximate change |
|---|---|---|---|
| Memgraph Cloud | 136.4 ops/sec | 497.1 ops/sec | 3.6× |
| Neo4j AuraDB | 111.4 ops/sec | 442.6 ops/sec | 4.0× |
| CognoDB Cloud | 63.4 ops/sec | 246.7 ops/sec | 3.9× |
| FalkorDB Cloud | 50.0 ops/sec | 203.2 ops/sec | 4.1× |
| ArangoDB Oasis | 15.8 ops/sec | 16.6 ops/sec | 1.05× |
ArangoDB’s reported throughput was nearly flat across the two tested concurrency levels. Amer confirmed that the edge index was used and reported no planner warnings. The article suggests a connection-pool limit, HTTP/REST overhead, or an instance resource ceiling as possible explanations, but does not establish which—if any—caused the result. It is evidence of the measured scaling behavior in this setup, not proof of a general ArangoDB limitation.
Why isn’t this a controlled engine-only ranking?
The services did not have equivalent resources. The benchmark repository reports CognoDB at 0.5 vCPU and 512 MB RAM; Memgraph on a 14-day trial with 2 CPUs and 2 GB RAM; FalkorDB’s documented free-tier limit as 100 MB; and ArangoDB on a 4 GB trial deployment. Neo4j’s free-tier CPU and RAM were not disclosed. These are the configurations reported for this comparison, not a normalized hardware test.
Rank #4
The apparent mismatch between FalkorDB’s documented 100 MB free-tier limit and the dataset loading successfully was not independently verified by the author. It should not be used to infer a different limit or configuration.
Free tools Windows power users keep installed
One-click scans. No signup required.
Regions also differed: CognoDB and Neo4j landed in us-east4, Memgraph was in Frankfurt, and FalkorDB was in AWS ap-south-1. The comparison did not deliberately match deployment regions, and the author notes that regional latency may have affected query times. With a single client machine and unequal instance resources, the figures combine engine behavior with service configuration, geography, and access path.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.What implementation details affect how to read the results?
FalkorDB connection path
The repository says the Bolt endpoint failed to connect in this benchmark environment, so the author used FalkorDB’s native RESP client. This is a report about that environment; it is not evidence that the service generally lacks Bolt support. Different clients or protocols can affect a comparison, so the connection method should be recorded when reproducing it.
CognoDB compatibility
Amer reports that the same Neo4j driver code worked with CognoDB after changing the connection credentials and URI. That is useful evidence of compatibility in this benchmark, not a universal guarantee for every driver feature, version, or application.
How should you use these results to choose a service?
Use the comparison to identify what to test, rather than to select a provider from a single headline ranking. Start with the work your application actually performs and compare services under a setup that resembles its expected data volume, geography, and load.
Quick Recap
- Define representative queries. Include the traversal depths, point lookups, filtered lookups, aggregations, and read/write balance your application needs. Keep result sizes comparable; a query returning more data is not directly comparable to one returning less.
- Use your data or a representative graph. Record node and edge counts, properties, indexes, and data distribution. If synthetic properties are necessary, document how they were generated.
- Match the deployment conditions. Place the client and services in the regions you expect to use. Compare equivalent resource tiers where possible; if that is not possible, report each allocation instead of presenting the outcome as an engine-only result.
- Keep the run procedure consistent. Record the driver and protocol, warm-up period, measured iterations, concurrency, test duration, and query shape. Repeat runs if you need to assess variability rather than relying on a single reported median.
- Test the production-like concurrency range. Measure both latency and throughput at the client counts you expect, including any point where performance stops scaling or errors appear.
- Check operational needs as well as speed. Validate compatibility with your existing client code and inspect the observability, indexing, and deployment behavior your team needs. The cited comparison provides performance results and some implementation notes, not a comprehensive operational evaluation.
- Reproduce before committing. Amer’s linked article and repository include scripts, queries, caveats, and rerun instructions. Use those materials alongside your own workload; the published measurements have not been independently replicated here.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
