Access Patterns (imo). Very few applications I’ve run into have graph hops and pattern matching from a known starting node as their primary access pattern. It’s usually supplemental. Even if you can conceptually think of your data model as a graph (which is something you can commonly do) when your app actually uses your data the main access patterns tend to be selecting by attributes (ie: find account by email address), doing relational joins of 1 or maybe 2 hops, or aggregating summary stats for display to users or exploratory analysis.

Compared to traditional relational databases, graph databases are terrible at all of those. Usually most queries involve a massive scan across all the nodes to find an entry point for a specific pattern and then it matches…but that scan isn’t usually as fast as it is in relational databases, and index structures ontop tend to be more expensive space-wise. Everytime I’ve looked into graph databases (Neo4j, Tigergraph, and Neptune primarily for different projects) we ran benchmarks and things fell over for our use cases very fast.

Don’t take this as saying Graph databases are bad. What they are good at is fast hops and pattern matching across long chains. Like if the main way you primarily used a relational database was doing 5-10 table joins per query, but don’t want the heavy memory usage, latency, and IO that comes with that. I can see a giant knowledge graph style expert system or some interesting weighted path stuff being a good fit. But at the same time, I feel like if you were doing something like that at scale then you’d probably want control over what’s in memory to avoid a bunch of disk access…but I’m probably biased due to the stuff I’ve worked on.

Speaking of the stuff I’ve worked on, one project ended up settling for custom graph application logic ontop of a KV store and it worked out well. The other project used Cayley (opensource graph db) as an in-memory index for a while. We could rebuild it from our db if it went down, but if it was up then we could quickly use Gremlin to do some queries and then flesh out the results by querying Postgres for the rest of the record attributes. It worked fine. But in the end we dropped it and just used two postgres tables with Subject, Verb, and Object columns. Subject and Object are foreign keys to normal relational tables. There was some tuning involved, but in the end it worked just as well and we didn’t have to know/run two services. This is what I’d reach for first for any “graphy” project I come up against and if it fails I’ll at least know what the bottleneck is so I can optimize for it next.

Massive disclaimer: My opinions are colored by the domains I’ve worked in (large scale web services, automated supply chain logistics and tracking, and general user facing web apps).

Graph database author here.

It’s a very interesting question, and you’ve hit the nerve of it. The long and the short of it is that, much like lambda calculus can represent any program, relational algebra can represent pretty much all database queries. The question comes to what you optimize for.

And so, unlike a table-centric view, which has benefits that are much better-known, what happens when you optimize for joins? Because that’s the graph game – deep joins. A graph is one huge set of join tables. So it’s really hard to shard a graph – this is connected to why NoSQL folks are always anti-join. It’s a pain in the rear. Similarly, it’s really easy to write a very expensive graph query, where starting from the other side is much cheaper.

So then we get to the bigger point; in a world where joins are the norm, what the heck are your join tables, ie, schema? And it’s super fluid – which has benefits! – but it’s also very particular. That tends to be the first major hurdle against graph databases: defining your schema/predicates/edge-types and what they mean to you. You’re given a paintbrush and a blank canvas and have to define the world, one edge at a time. And $DEITY help you if you want to share a common schema with others! This is what schema.org is chasing, choosing some bare minimum.

This is followed on by the fact that most of the standards in the graph database world are academic in nature. If I have one regret, it’s trying to follow the W3C with RDF. RDF is fine for import/export but it’s not a great data model. I wanted to standardize. I wanted to do right by the community. But, jeez, it’s just so abstract as to be useless. OWL goes another meta-level and defines properties about properties, and there’s simpler versions of OWL, and there’s RDFS/RDF* which is RDF about RDF and on and on…. it’s super cool that triples alone can represent pretty much anything, but that doesn’t help you much when you’re trying to be efficient or define your schema. Example: There’s a direct connection to the difference between a vector and a linked list – they both represent an ordered set. You can’t do a vector in triples, but you can do a linked list.

I know I’m rambling a little, but now I’ll get to the turn; I still think there’s gold in them hills. The reason it’s not popular is all of the above and more, but it can be really useful! Especially when your problem is graph-shaped! I’ve implemented this a few times, and things like mapping, and social networks, and data networks, and document-origin-tracing – generally anything that would take a lot of joins – turn out swimmingly. Things that look more like tables (my example is always the back of a baseball card) look kind of nuts in the graph world, and things that look like a graph are wild in third normal form.

So I think there’s a time and a place for graph databases. I just think that a combination of the above counter-arguments and the underlying needs are few enough that it’s under-explored and over-politicized. They work great in isolation, ironically enough.

I’m happy to chat more, but that’s my quick take. Right tool, right job. It’s a shame about how that part of database theory has gone.

Oh boy. It’s a meme amongst my friends at Google that half the software engineers want to build you a graph database because they are such a cool problem to solve (especially for people who have been drilled by algorithmic coding interview prep).

But in all seriousness:

1. I’ve seen them used on flashy data science projects, and the way the data was modeled conceptually was very hard to understand.
2. Related to that: people (including me) already have trouble with relational data modeling. Nobody wants to admit this, but there are so many choices and so many ways to create a bit of a mess! At least the relational model gives me guarantees, and document (JSON) stores give me maximum flexibility. Graph models feel like the worst of both worlds.
3. I don’t know of an established one that has the same reputation for maturity as for example Postgres. Neo4j maybe comes close.
4. They are just newer, so they lack those decades of common knowledge about performance characteristics, libraries, cloud offerings, integrations with other tools, etc.

So in short, they rarely warrant the additional complexity, and unless you really know what you’re doing, they are a risky bet. 99% of all (non-blob) data in the industry is just simple data with a clear schema and static relations, or unstructured data best modeled as JSON. And in both cases, data “in the enterprise” (which is the market TigerGraph wants) is usually a huge fucking mess, and I’m not sure a graph model would change that.

But I agree otherwise that graph models are really cool and appealing, and I would love to have a good use case for one.

Set theory is hard

Graph theory is very hard

I’m going to come at this from another angle– past the initial reasons for the success of SQL (and relational DBs), they owe much of their success to the availability of learning materials and environments for people. It’s easy for people to learn SQL but looking up any SQLite tutorial and running it right then and there on their laptop.

Where’s the SQLite for graph databases? Where can a beginner get practice without arduous setup? There may be solutions that come close, but not close enough.

There is a ton of tutorials how to make Postgres perform, and if I do nothing it is still fine-ish at moderate sizes. And usually only tables you use in a query affect its performance. With graph databases… I once had a small piece perform well enough, but not when stored in the same graph as the other data with completely different vertex and edge namespaces (and the purpose was for this small piece to encode filtering logic, with yet another kind of edges used to select the actual data afterwards).

Oh well, so back to Postgres it is for the project, and messy filtering can continue living in application code…

I guess if people want to build them, at some point accumulation of knowledge how to build them and how to use them will make it easier not to do the stupid mistakes I did in that experiment. Or maybe new architectures will make those ways of slapping things together acceptable!

Disclaimer: It’s been around 10 years since I was involved in creating a social network.

If I remember correctly we had a few discussions, because social networks are kind of a poster example for graphs, but one point was sharding. There were known-to-work solutions if you were using relational DBs but we didn’t know of any proven thing for the graph databases around. Also we weren’t a startup so no “revolutionizing the world by inventing the best new graph db”, and in the end a lot of it was trying to not spend the innovation budget on something like this, boring is better, as we were supposed to hand off the thing to the company we were building it for, so operationally it should be easy to run. Of course easy is relative, but mysql (or postgres?) was a known fact. Oh, and not to forget: in the end you can model the graph relations quite easily with a RDBMS, so why bother?

Too expensive (neo4j licensing, Neptune instances) or not fast enough even when expensive (Neptune)

We have > 20TB of data and expire it after N months, so we are slightly delete-heavy. We also take advantage of the fact it’s a graph database to spot where we made connections immediately on adding nodes - for a good user experience - so bulk loads aren’t an option for making things cheaper / faster.

Good question, I’ve asked myself the same thing a few times. As others have noted a lot of issues seem to be around scaling, and expensive (or even crazy-expensive) hosted services. I think there’s also an extent to which they’re perceived as a very specific tool for a very specific task, but in my experience they’re usable in a much more general context than just a friends graph or a recommendation engine.

I co-run a niche event listing site & app with a comparatively small (30k verified users and 130k historical events) dataset that uses Neo4J community edition as the main/general-purpose database. We came for the deep relationship traversal and pre-provided graph algorithms to help with recommendations, stayed for the natural-feeling data modelling in Cypher (the Neo4J declarative query language), and over time became more dependent on APOC, the (genuinely) “Awesome” procedure library.

Getting good query performance can be unexpectedly complex or simple depending on what you try to do and which end of the relationship path you start from conceptually as well as practically, but with good support for subqueries and conditional query execution you can pretty much always find a way to do what you need.

It was operationally quite painful when we started using it in 2014, but we don’t find it so now, and for people like us who don’t have to scale it to the moon, in many cases I can think of I’d honestly prefer to use Cypher to build out the world edge by edge rather than SQL and schemas, not only because of the flexibility but because it just feels more natural to model relationships that way. It also used to be pretty fiddly to model dates and times or spatial elements in the graph because there were’t any native types to support it, so you had to do stuff like creating a “time tree” of days/months/years as nodes and relationships between them - but date/time/instant/durations are all built-in now, along with some lat-long and geo stuff that doesn’t need extra plugins, and it’s pretty much all there.

I wonder if there’s still a perception that some of the stuff we take for granted in an RDBMS isn’t there, and whether that affects people’s decisions only to use graph stores for traditionally graph-specific domains? Not saying everyone should use graphs for everything, at all, but in a lot of situations modelling real-world relationships in data, I think that perception is definitely out of date, and a lot of people might benefit from trying it in a graph.

If I had to do it all in Gremilin or Tinkerpop or similar I’d bail pretty fast, but match (person)-[:likes]->(thing) return person.id is so much more intuitive than select id from person, thing, person_thing pt where thing.id = pt.t_id and person.id = pt.p_id or whatever that I find myself thinking model questions through in Cypher really intuitively, or at least by seeing the concept of the query build up sort-of-visually in front of me as I write it. Multiple labels like (match p:Person) (or match (p:Person:Admin)) give you easy indexes and constraints as well as a flexible kind of grouping mechanism.

I’d love it if more graph DBs supported (open)Cypher, but even then unless they implemented a lot of the APOC I’d find myself missing that. AgensGraph supports SQL and Cypher, a while back it was a pgsql fork which seemed like too much trouble to think about, seems it’s become a pgsql extension since then so it might be a lot easier to deal with operationally now.

There are other interesting multi-model systems like OrientDB but it’s yet another query language and how much time does anyone really have?

Flexibility, I think. Relational databases are hard to beat in the general case. Perhaps specialised databases are better for some specific cases, but relational databases can offer an acceptable solution to those problems and handle everything else too. There are also consistency benefits to keeping everything in the same database rather than splitting between multiple ones.

Others have mentioned the issue with determining boundaries when spreading a graph over multiple DB nodes. This means many people end up using a single DB instance for the graph. But at that point—for many use cases—loading the entire graph into memory in your process that’s doing some analysis/processing is simpler and more efficient than sending queries to a database.

Like any “why isn’t ___ more popular” question I’m sure this will attract a lot of plausible-sounding anecdotes but, like all such questions, the answer is almost certainly that tech fashion just didn’t go that way, it went some other way for no reason at all except happenstance. Why didn’t OS/2 become more popular? You can describe the history there but there’s no why, it just did. An identical world with one fewer butterfly probably went another way instead and they’re just as sure about why it went that way. If graph databases did become more popular you’d have the same folk explaining why it’s obvious that it happened that way.

But for a baseless anecdote of my own: SQL can model graphs, if poorly, and there are some great SQL databases that already exist, so most people with a graph problem just write it as a SQL problem instead because they learnt how to use it in school and already know it and their friends and coworkers know it. Writing a database is difficult, hard work. Especially if you care about correctness. The number of people in the world that can do it is finite and for whatever historical set of reasonless circumstances they’re concentrated in the SQL space instead and that feeds itself.

Apart from being difficult to implement efficiently, most services don’t have that kind of data to make use of graph databases.