So, technically, you can do deep traversals quicker. A few notes:
1. Few use cases truly need low-latency deep traversal on realtime data (>5 hops). There are some well known ones like fraud detection in payment processing and, possibly, social media recommendation engines. But I am not even sure how latest social media engines work, and whether they still rely on graph DBs.
2. However, in practice the advantage is often marginal. With modern analytical databases, or even an optimized PostgreSQL (ltree, materialized views, pgrouting, pg_duckdb, etc), you often get more than good enough performance. In addition those traditional SQL DBs scale with hardware more easily than graph databases. So, you can always use the lever: "Throw more hardware at it."
3. Even Graph DBs don't get good traversal performance under all conditions without hand tuning. For example, there is the "super node" issue, a node with an abnormally high number of connections (edges). And if you still need hand-tuning, you might as well choose something more versatile.
4. The ecosystem of a PostgreSQL and other popular DBs is just unbeaten. With graph DBs, you often prematurely put yourself in a corner that you don't want to be in.
Hence, my recommendation. Unless you are really sure that a graph DB is the right fit for your use case, start with something else, and go the graph db way when you have established a true need.
If you look under the hood there is usually nothing special about graph databases that will make them more performant. If you lay out a query plan side-by side between e.g. Postgres and Neo4J, they will look identical, just that the leaf-nodes in Postgres will be a table-scan, while in Neo4J they will be either a vertex-scan or a edge-scan (which can both be seen as special cases of a table-scan).
As someone that has worked a lot with graph databases in the past, I'd largely recommend not using them. The price you pay in terms of worse ecosystem and less battle-tested maintenance tooling is not worth it to just have better syntax.
Response: https://blog.ladybugdb.com/post/better-graph-database-ball/
I like how PG19 with PGQ will kill lots of companies and startups.
[edit] To elaborate: tuning read and write performance is difficult, essentially everything must be indexed. This results in an explosion in data size--so data that might be X TB in csv format becomes maybe 10X when you consider all the indexes and bloat from the graph db's storage format. Which brings us to the topic of compression: there isn't any. Moreover, graph dbs are basically all quite immature compared to other db software, they haven't seen the test of production to the same degree, nor have they gotten the same attention in terms of bugfixes, performance tuning, etc. So they often have very sharp edges that you encounter under load. So if you like spending tons of money and time on zero value work, choose a graph db!
[another edit] Another problem with graph dbs is they encourage laziness in data modelling. I would echo others' recommendations here: just start with SQL. If it gets to the point where you actually need a graph query language--and you've already appropriately considered your life choices and determined that there's some value to what you're doing--only then should you consider trying to implement something on a graph query engine. But I'm not aware of one that is actually good. That's the problem. If you're at the point where you absolutely need a graph database you are probably at the point where you need to build your own. And you'll probably fail like all the other ones.
[1] https://neo4j.com/blog/government/graph-technology-pole-posi...
Edit: typo
- custom app security
- social media
I also think cypher is a brilliant way to query a graph.
IMO, you're better off just using Postgres/etc, modeling your graph data there, and pulling in subsets of your graph for in-memory analysis. This is for the 99% of enterprises that aren't doing online streaming graph analysis on TB-scale graphs, and the other 1% should probably figure out something tailored* to their specific business model.
* Graph algorithms are more accessible than ever with GenAI code, and efficiently modeling a graph in memory is trivial (it's just structs with pointers to other edges/nodes, plus its nice to have full control over the memory layout).
* Columnar storage * Compressed Sparse Row on disk * Factorized joins * ASP joins, WCO Joins
Details: https://vldb.org/cidrdb/2023/kuzu-graph-database-management-...
The main innovation is the "REL table". You can think of it as a many-to-many relationship table on steroids with optimizations at the storage layer and join algorithms.
Definition of what makes something a graph database (apart from the query language) is contested. But we seem to be moving towards: build a reasonable relational database and then add a "REL table" to it with join optimizations.