Best Graph Databases in 2026

One developer weighs pros and cons of graph databases and shares his insights into what works best for various use cases.

I am a huge fan of graph databases. Everyone thinks there are only two types of databases: noSQL and SQL. However, graph databases are the future and the best!

Why?

Graph databases store the pointer to its relationships directly. SQL databases require traversing another table with a join or index.

This Is HUGE!
A graph database doesn’t have to traverse a join table to find anything, it just goes directly to the location where the connection or connections are located.

And Regular Scans
In theory, SQL databases should be faster for basic table scans with indexing, sorting or aggregation. However, modern and new (graph) databases have learned from past database needs. And they can arguably scan just as fast with all variables being equal; but every database speed measurement depends on the infrastructures, database settings and scale.

Graph Database Tradeoff
SQL is mature. That is the only certain tradeoff.

TL;DR

We go over classic graph databases, new graph databases and graph databases built on SQL, and we tell what they are best for. The most notable are Progress MarkLogic and SurrealDB.

Dead Graph Databases—R.I.P. 🪦

Before we get into the modern options, let’s take a look at some recently retired databases.

Gel

Rebranded from EdgeDB, Gel was masterclass on how to build a cloud database. It offered built-in authentication, easy schema creation similar to Prisma and a query language that was powerful and concise. It was also built on Python on top of Postgres. That means we know it was stable.

Of course, because it is really Postgres, it is NOT a real graph database, which stores pointers instead of tables under the hood. This means graph traversals would never be natively fast like a true graph database would.

What Happened?
Since the Gel team was mainly Python developers, the entire team joined Vercel to work on Python in the cloud.

Status: Open Source

FaunaDB

I admittedly don’t know much about FaunaDB, but I remember when it came out. It was a noSQL database that could do joins like a graph database. However, it was incredibly unintuitive on how to do them. You basically had to manually create the indexes, which was not easy, and you couldn’t just easily query them like you could Firebase, which was arguably its first competitor. I do, however, believe querying got easier in the last few versions.

It was originally cloud-only, which means you were stuck with vendor lock-in and you couldn’t self-host it. This was one of the many problems. We have since learned that it is written in Scala.

What Happened?
The simple answer is that it ran out of money. I personally believe it didn’t acquire enough users due to the learning curve, but that is just a guess.

Status: Open Source

Dgraph

This is a sore subject for me. I wrote dozens of articles on Dgraph, created several JavaScript tools and even contributed to the core code at one point. There was a small group of us who were dire fans, but just never got what we wanted. We were very active in the community, even through three changes of ownership. I think no one, including the founder, understood the incredible product and potential this database had.

Dgraph was a cloud database that allowed you create a schema to generate a GraphQL endpoint for your database with no coding!

What Happened?
They ran out of money. They had millions in VC money, and they blew it all. The other big problem is that Dgraph didn’t know what it was. I firmly believe if they would have had more money at that time, they could have created something incredible, and time would have fixed a lot of the issues.

Dgraph was originally written in a language called DQL. It was so similar to GraphQL, that the team decided to rewrite query and the schema creation in GraphQL. Facebook and GitHub made GraphQL famous at the time, so this was a high request. However, instead of being natively written, the team decided to compile the GraphQL to DQL, which made it even more confusing. I suspect they didn’t know that the GraphQL Spec couldn’t query every basic use case, and has major holes in it, as designed.

The two languages split the users in half. You have government paying users using it as a graph database without the GraphQL piece, and you have web developers using the GraphQL piece to create apps. Both were half-baked and didn’t have all necessary features. The GraphQL piece had some major unresolved security issues, while DQL couldn’t query some of the basic transversal functions that neo4j could. It needed more algorithms.

It was bought three or four times, had at least two active forks at one point I am aware of, and I believe some of the non-profits or government contracts still use it to this day. It is still kept up, but I haven’t seen any new features in the pipeline other than maintenance.

Status: Open Source

Memory Graph Databases 💾

While not for standard database use, in-memory graph databases are worth mentioning.

MemGraph

If you pay the high price, you can get RBAC, authentication and auditing in MemGraph. The free community edition does not support these features. Like any in-memory database, it is going to be extremely fast but extremely expensive. This is great for caching data when you need to have complex graph queries available. You query in Cypher, first introduced by neo4j.

FalkorDB

Formerly RedisGraph, FalkorDB almost made it to the RIP section. However, FalkorDB is very active and cloud-hosted now. It does have basic access control and uses Cypher as well, but MemGraph is a little more fine-tuned. FalkorDB is not far behind and still compatible with the Redis echosystem.

Non-Native Graph Databases 🛢️

People like to build on top of SQL. We already mentioned Gel, which is retired now. It is also worth mentioning Good Cloud Spanner Graph, built on Spanner Tables in SQL, another SQL graph database, and Oracle Graph Database built on Oracle. If you want to host your own graph layer on top of SQL, you can also look into Puppy Graph.

Apache AGE

While there isn’t a cloud version of Apache AGE that I could find, this is a popular Postgres Extension written in C that allows you to perform Cypher queries on your Postgres Database. Again, it doesn’t change the query engine itself to magically store the pointers, but it does give more querying capabilities.

PostgreSQL 19

Recently released, Version 19 of PostgreSQL allows you to create graph columns and query the graphs using a cypher-like querying system. If you’re going to stick with Postgres, this is your best bet.

JanusGraph

JanusGraph will be able to crazy scale and is technically faster than any graph database built on top of SQL, but it is not a native graph database either. It is built on a Key Value Database. However, this may not matter when dealing with billions of nodes.

Classic Graph Databases 🕒

There are the big dogs.

Progress MarkLogic

First commercial release in 2003, Progress MarkLogic is one of the oldest and best graph databases, especially when your sources are of different types. This enterprise multi-model database supports documents, search and RDF triples. You use SPARQL to query and create document-centric permissions for fine-grained security. It is built for sematic webs rather than property graphs.

And, of course, it is now owned by the Telerik and Kendo UI parent company, Progress Software:

GraphDB

Released a year later in 2004 (originally OWLIM) and rebranded in 2008, GraphDB
is best for semantic reasoning for an RDF triple store database. It can be good for knowledge graphs with linked data integration.

AllegroGraph

Very similar to GraphDB and released in 2004, the AllegroGraph database is another RDF knowledge graph database. It is perhaps better at graph analytics than GraphDB, but there is no open-source edition.

Stardog

In 2010, we saw another RDF database, except it specializes in virtual graph mapping to query external data sources live. If you need a dynamic RDF database, Stardog is your choice.

OrientDB

Launched in 2010, OrientDB is known as the first multi-model NoSQL database; MarkLogic didn’t have the multi-model features until later. This database can scale horizontally, but known more for the NoSQL part.

Neo4j

Definitely the most popular graph database, which came out in 2007, Neo4j is the granddaddy of graph databases, known for creating the Cypher query language and being the classic standard for property graphs.

It can be hosted anywhere, although for fine-grained RBAC, you need to pay for the enterprise edition. It is probably the most mature, but not the fastest.

Cosmos DB

Cosmos DB is Microsoft’s graph database, released in 2017, keeping you locked in to the Azure ecosystem. It is also mainly a noSQL database with a graph structure. Supports both Cypher and Gremlin.

Amazon Neptune

Amazon Neptune is Amazon’s graph database released in 2018, keeping you stuck on Amazon. Again, be sure you want to stay on their infrastructure. This is great for speed and property graphs. Supports both Cypher and Gremlin.

ArangoDB

Known full being one of the first true multi-model databases from 2012, with ArangoDB you can store graphs, documents or tables. It uses a custom query language, AQL, to get the data.

NebulaGraph ⚠️

NebulaGraph is built to scale for a great graph cloud service that came out in 2019. However, I would NEVER recommend using it, as any database home to China carries a huge security risk for your data.

TigerGraph

TigerGraph impresses me. Released in 2017, It is a graph-native database that can scale, has RBAC, is open-source and is built for analytics. However, it has a steep learning curve, and not as friendly to web developers as neo4j.

New Graph Databases

SurrealDB

I’m a huge fan of SurrealDB. It has the potential to be everything a database should be. It has built in authentication, RBAC, functions, algorithm creation, full-text search, schemas and more. It is very new, so I’m curious to see where it goes. I am currently an Ambassador for the database. I don’t know that you can find all these features in any other database on the list.

Helix-DB

Helix-DB is not feature rich, but there is something to be said in doing something well. Built to scale knowledge graphs, vectors, temporals, full-text search and more, I found the learning curve extremely simple. I would definitely recommend it.

TypeDB

TypeDB is best for describing things. You store items as objects as an entity, attribute or relation. This is a very unique database that allows you to store data as types, inherit items and query like a graph.

Aerospike Graph

Massively scalable, high-performance graph database. Developer-ready with the lowest total cost of ownership. The Aerospike Graph Services compute engine is a distributed, scale-out implementation of the open-source Apache Tinkerpop framework.

Winners

Like everything, it depends. Here’s where I would declare winners:

Best RDF and Multi-model Database

• MarkLogic ✅

Best Features and Future Potential

• SurrealDB

Best Pure Graph Database for Analytics

• TigerGraph

Best In-Memory Database

• MemGraph

Best for SQL Users

• Postgres 19

Best Learning Curve

• HelixDB

Best for Microsoft Azure

• Cosmos DB

Best for Amazon Web Services

• Neptune

Best for Google Cloud

• Spanner Graph

Graph databases will be the future; I just wish they replaced relational databases completely. I’m tired of joins when we can store the connections directly as pointers.

If you want a great graph database to start off with for your web app, check out SurrealDB.

However, when you’re ready for an enterprise ready database for querying multi-model complexities, MarkLogic is the way to go!