The Birth of Graph Databases: How Neo4j Built its Product and Category

Eifrem: The first few years involved a lot of boot strapping. We were consulting, we built systems on graph databases, but we really did not have a product to sell. We also had a very interesting marketing challenge. I am an engineer by background, but I am also a student and a lover of marketing and we decided to take on one of the hardest things you can do in marketing, which is to create our own category in the market. And we figured that as we had already built a transactional high-performance database on a low-budget and low resources, then why not take on another almost impossible project, right?

We had this technology that was clearly valuable and was 1,000 times faster on certain operations, clearly with huge potential for customer value. The challenge was you could take it to market in a variety of ways. You could have positioned it as a database accelerator, to be run side-by-side with a relational database. That would be a perfectly viable way of taking it to market. But we felt that the big prize was to build an entire category of our own and then become the leader of that category. Look at most huge Silicon Valley companies and that is how they were built.

And then Mark Zuckerberg came along and he said on Facebook’s front page ‘we are a utility for the social graph’. Even though he had a consumer website he was talking about graphs. So we put those two words together, graph and database, and started filling them with meaning. And so this is what we mean when we say ‘graph database’: this is what it is good at, and these are the sorts of problems you solve with it.

Dryburgh: You are providing the definition of that category.