What’s the biggest obstacle to GraphDB adoption?

The recent workshop on Graph Databases in Barcelona sparked an interesting debate among vendors of graph databases about how to accelerate graph database adoption.

I don’t think that debate has been resolved yet. Perhaps this post will help a bit.

Some opinions that I heard were:

  • there are significant differences between the various graph database products on the market (e.g. graphs, property graphs, properties on edges or not, hypergraphs etc.). Unless they are more similar, customers will fear lock-in and not buy any of them. Here is a variation:
  • relational databases only took off once there was agreement on the SQL standard among vendors. We need to cooperate to create a similar language, otherwise graph database adoption will not take off either.
  • most potential users of graph databases have never heard of them. How could they use any if they don’t know they exist?
  • even if possible users know of graph databases, they do not know what the use cases are because use cases and success stories have not broadly been documented.

What do you think the biggest obstacles are for graph database adoption?


  1. Vitor De Mario says on February 28th, 2011 at 6:17 am:

    We also have to consider that the concept of Graph, although very natural to all the participants in this discussion, may not be very clear to those potential users you talked about. Some people may come across a GraphDB, without really knowing what’s a graph, and therefore bypass it completely.

  2. Adrian Blakey says on May 31st, 2011 at 11:40 am:

    It has to be a drop-in replacement for a RDBMS. The world thinks a database is SQL. There is a huge investment in SQL data, knowledge, embedded apps etc. For broad acceptance a graph database has to be just another SQL database – with a a few more features. Databases were commoditized years ago and hence a graph database is just another commodity database. Its unique selling point is not appreciated by the majority of users who have been trained to think in terms of sets and SELECT/FROM/WHERE. Good is good enough.

    It’s similar to the issues that bedeviled Object Databases – I worked for Servio/Gemstone and Ontos/Ontologic. Performance was not a differentiator – Oracle was always faster. We could not compete on size – we had no customers running at scale and Oracle did of course. Sure we could do traversals – but most people wanted queries, and joins with enough indexes worked as well.

    Modelling power was not a differentiator once object-relational mapping components became available. The demand was to make it just like SQL. It was sort of a conundrum, the use cases where it should have fit, scale and representational power were closed off.

    The majority of users do not have use cases that make them dissatisfied with relational databases. There are only a few edge cases who do, who will be adopters – those with huge scalability issues such as successful SaaS vendors. As SaaS vendors they will be reluctant to share the secrets of their competitive edge and do not disseminate their service as a product, further stymieing propagation into the broader market.

    So my prediction is they will never gain broad adoption. The trend is against it. They’ll be relegated to the domain of a few cognoscenti.

  3. burcu co says on January 24th, 2012 at 6:33 am:

    Greate article at all, as a developer, I have a very challenging problem right now and do not know if it can be resolved with graph db. I heardh of graph db on a slide and start to understand if it’s ok for me but still could not understand if it’s. There are lots of things but actually none of them good enough :(

Comments are closed.