Graph Technology Landscape 2019
Few years ago I decided that one day I would create a Graph Technology Landscape map, which would be useful for everyone who wants to discover the players around graph technologies. I started to collect the companies and products, but my research has never manifested into a proper blog post. Till now. I am happy to announce, that the first version of my landscape is published, I hope we can consider this as a start of a long journey.
A little background about this post: A few years ago when I started to take my first baby steps in the land of big data, I found the Matt Turck Big Data Landscape picture on the internet. I was impressed; I was able to spend hours staring at it on the wall at the office. It was like a treasure map with lots of new areas to discover! It was my best guide to follow the trends of technologies every year, and I always used that picture in my presentations to describe the role of graph technologies in the Big Data World. I realised that graph technologies should have a landscape too. It took a while, but it is here!
This landscape is not something that a market research company created, this is something I created with passion and love, because I believe in graphs. It is it is highly probable that it is not perfect, and of course, we at GraphAware see this entire World through our “Neo4j expert” eyeglasses. We consider this just as a starting point, and the goal is to collect community feedbacks, and include them into our next graph technology landscape. As a colleague of mine used to say: “If you build it, they will come.”
“Fortunately”, it is a big challenge! That’s because graph databases are the fastest growing category in databases (based on the db-engines.com), and there are many changes every day. We are sure this will continue to be the case in 2019. Graph databases and graph technology will be hot topics again this year and we are looking forward to seeing it.
To see the landscape at full size, click here. To view a full list of participants in spreadsheet format, click here.
Let me share a few thoughts about the picture and the categories I used. During the research phase I had to define a few rules I tried to follow during the whole process:
These were the general rules I applied. Now let’s spend a few words about the the categories.
I simply used two categories here. One for graph databases, and one for all other non-native graphy solutions. So the category “Multi-model / RDF” can contain key-value, document, sparse matrix, and RDF storage models. I did not create distinct categories for each storage model, because sometimes they use a hybrid solution to store graphs.
If you decide to host your graph data in the cloud, then you have several options. If you choose infrastructure-as-a-service (IAAS), you can select one of the major players and just run a VPS server with your graph database on it. It can be almost any cloud hosting provider. But here we only listed the vendors which by our knowledge support running a graph database as a droplet/cluster/addon. In the platform-as-a-service category (PAAS) we listed the vendors which let you use a graph database out of the box in the cloud.
In this category we listed the data ingestion tools which are perfect fit for a graph database. Some of them are Neo4j specific, like GraphAware Databridge or the recently released new version of the Neo4j ETL tool, but there are other tools which are more universal, like Talend, or a Kafka, or a Pentaho Kettle. Norconex also released a Neo4j loader extension to their crawlers. We are pretty sure there are other integration frameworks out there, but these are the ones we usually see during our client projects.
We think that a database technology does not sell itself, you have to impress your audience with something that is visible and meaningful for the end user.
