A Case for Graph Databases

We talk with Daniel Kirstenpfad, founder and CTO of sones GmbH about Graph Databases and how they can better model some types of data such as relations in a social networking application.

Can you explain what a graph databases is and why developers would choose one over a tradition database?

Unlike other databases which store their data in rows, columns or key-value pairs a graph database stores all information in a network of nodes and edges. Edges manifest the connection between nodes which effectively represent objects. Because Edges and Nodes are represented as objects (like objects developers are used to) one can assign attributes (sometimes called properties) to them. Adding a direction to an edge ultimately creates a so-called property graph which represents the explicit structure of data inside a graph database.

So unlike other database approaches which only implicitly can form a graph structure a graph database explicitly represents a graph. And while other databases need to use indices and relational helpers (like relational tables which are coupled using JOINs) a graph database can traverse from one object to the next objects because those objects are organized to have index free adjacency.

There are many use-cases where a graph database is the most natural approach. For example in social networks it's easier to use a graph data structure to represents friend relations and do traversals and queries like "get me all the friends of my friends friends". Additionally common graph based algorithms like path-searches are easy to implement by traversing through the graph.

Beside all those great features the sones GraphDB also offers an easy to learn and use query language which allows the user to run ad-hoc queries just like he was used to with SQL databases. The above example would result in a query like: FROM Users u SELECT u.Friends.Friends.Friends WHERE Name = "Daniel"

Can your product run embedded or only as a separate service?

The sones GraphDB can be embedded into almost any application. Because it's written in C# (.NET) it can naturally integrate into an existing .NET environment which can be Microsoft .NET on Windows or Mono on any other platform. With our current products we're focusing on the client-server approach offering different interfaces. For example our product comes with integrated selfhosting REST interface. Selfhosting means you won't need any 3rd party service to host a GraphDB. It comes all included in one package.

We are currently in the process of adding a .NET client library to allow object oriented access to a sones GraphDB server without having to leave the known space of C# and without having to parse through JSON or XML. This library is planned to be available for Java as well.

To drive things even further we're planning on making that client library useable through LINQ.

Were any changes necessary to offer the Windows Azure version?

Giving the complexity of a cloud service infrastructure it was surprisingly easy to allow our GraphDB product to run on Windows Azure. We had to add mostly glue code to help the GraphDB to communicate its status to the Windows Azure infrastructure. All in all it was only new code added to the GraphDB to offer the Windows Azure version. No code needed to be changed in the core and interfaces.

Currently we are adding several new modules to GraphDB - one of which is a module which uses the Azure Page Blob Storage technology to persist a graph database and in doing that allows even more interesting usage scenarios for our customers.

Are there any other graph databases that you would consider a competitor?

There are a number of graph databases available which are mostly tailored especially to meet one or several use-cases and as always it's great for customers to have choice. Since sones started to create an enterprise grade database management system we're aiming to ultimately achieve the goal of creating no more than that. For some use-cases we are seeing competition from products like Infogrid, Neo4j or InfiniteGraph. When it comes to features like an easy to use and intuitive query language, .NET integration or a state-of-the-art data storage technology which allows not only to store graphs but also large binary data along with versions and editions we think we have many unique selling points.

Just because an idea isn't new, doesn't mean there's no case for it. Though it bears a close resemblance to the old "navigational database" model, look at it for what it offers. With all the data stored in memory instead of magnetic tape the approach can be extremely efficient and has a distinct advantage in many common cases. Emil Eifrem (creator of Neo4j) is always quick to point out the spectrum of database models and that they are not one size fits all. I think the whole NoSQL movement really just makes the case that relational doesn't have to be the default answer. It isn't perfect for everything.

Is your profile up-to-date? Please take a moment to review and update.

Email Address

Note: If updating/changing your email, a validation request will be sent

Company name:

Keep current company name

Update Company name to:

Company role:

Keep current company role

Update company role to:

Company size:

Keep current company Size

Update company size to:

Country/Zone:

Keep current country/zone

Update country/zone to:

State/Province/Region:

Keep current state/province/region

Update state/province/region to:

Subscribe to our newsletter?

Subscribe to our industry email notices?

You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.

We notice you're using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.