What is a graph database? Do you really need one, and if yes, how do you choose?
Do you really know the answers to those questions? Maybe you are in the 51% of organizations using graph databases as per Forrester? Either way, joining us at Connected Data London can help find, or check, your answers.
Although graph databases have been around for more than 15 years, it was the move of AWS and Microsoft in the domain that attracted widespread interest. If they are into this, there must be a reason, right?
Sure there is. Everyone wants to know more, few can really keep up and provide answers. And as this hitherto niche domain is in the mainstream now, the dynamics are changing dramatically. Besides new entries, existing players keep evolving.
The track & the deal
This is why we have a dedicated track on Graph Databases, featuring talks and panels on graph database models and features, as well as the latest research in the field.
The track is curated by our co-organizer George Anadiotis, and will be hosting speakers and panelists such as Thorsten Liebig from Derivo, who will be sharing his experience working with LPG and RDF graph databases, and our sponsor TigerGraph who will be participating in our panel.
George has been working with a number of graph databases since 2005, when he implemented his first graph database prototype. This includes award-winning R&D, startups, enterprise deployments, and consulting the (then) top Graph Database vendor on distributed queries in 2008.
He has been active as an analyst, consultant and entrepreneur since 2012. Some highlights include defining and analyzing Agile Business Intelligence long before the Gartners of the world, working with the likes of Hortonworks, SAP, and more.
George has also been monitoring graph databases for ever, and publishing the definitive graph database newsletter since 2018.
By joining CDL you will not only get access to a top class event, but also get an exclusive offer to access this premium research report at 20% discount.
Get your CDL tickets by the 5th of August, and get 20% off for the Year of the Graph Report.
If you are looking for
- Up to date, comprehensive and unbiased research
- A data-driven methodology, combining metrics and experience on business and technical aspects
- Personalized advice for the lens you need to look at the domain
Then the Year of the Graph Report is what you need.
“Impressive work. Well done. I’m not aware of another source that is as comprehensive as this one. Thank you for that as it’s providing me value from a graph market research perspective”.
Jonathan Lacefield, Senior Director of Product Management, DataStax Enterprise Server
“Kudos to you for your relentless work on informing the community about their options in the graph sphere. Think the report will be highly appreciated – it’s on a whole different level!”
Jan Stücke, Head of Communications, ArangoDB
“Anadiotis may understand MarkLogic even better than we do ourselves”
Rob Lawrence, former Director or Strategic Programs, MarkLogic
Some of the key points we will be discussing:
It is important to define what a graph database is and what it is not. While a number of solutions may offer some graph-related features, most commonly analytic capabilities, we define graphs databases as the ones having the ability to fully support operational applications utilizing a graph data model and API.
The major choice to be made when it comes to graph databases is the one regarding graph data models – LPG versus RDF. Databases based on each of those tend to have specific characteristics, making them more suitable for specific use cases.
Not being based exclusively on a graph data model does not necessarily mean being ruled out as a graph database solution. Multi-model graph databases also support data models such as key-value and document in addition to supporting either LPG or RDF. This makes for a more diverse platform, albeit possibly at the expense of optimizing for graph.
Cloud-only solutions from AWS and Microsoft are different, not just from other solutions but also from each other. Although their features in terms of scalability and availability appear similar, they have different technical features and are at different maturity points.