Graph Database as a General-Purpose Database
Last time, we tackled the differences between relational databases and graph databases as well as the good and poor fits for graph databases. This week, we’re going to discuss how you can use a native graph database as a general-purpose database. Also, check out the GraphStuff.FM podcast!
Many applications – especially in enterprises – aren’t backed by a single database. Oftentimes you have to pick your own tech stack with many different systems working together. Think of a general-purpose database as your first and your main database, which you’re going to use as your source of truth as you’re building out your application.
Ecosystem Integration
The first thing you should think about when determining which database would be a good fit for your general-purpose database is the ecosystem of framework and language integrations that exist for this database. With the tech stack that you have chosen for your application in mind, you need to ask: Is there an integration with this database and the technology that I’m interested in using? How easily can it be integrated into my tech stack? That is going to be one of the most limiting factors.
So if we think about this for a Neo4j graph database, it’s important to understand what ecosystem of integrations exist for Neo4j. There is quite a good range of language drivers out there that you can use to integrate Neo4j into your application. So what languages can I use to integrate Neo4j into my application. There are also all sorts of tooling at the framework level that make it easier to integrate Neo4j into your architecture as a first database. These are things like the GraphQL integration for Neo4j, the Spring Data Neo4j project, the Django integration for Neo4j and connectors such as the Spark Connector, the Kafka connector, or the JDBC driver for Neo4j.
Why Use Graph Database as a General-Purpose Database?
Now that we’ve identified whether we have the means and mechanisms to connect up the database with our framework, the next question is: Why would I consider using a graph database as my general-purpose database?
The really powerful thing about graph databases is speedy prototyping. If you want to ask your data how you can get away with murder in the quickest possible way, you don’t have to declare a schema. You don’t have to go through a protracted process to quickly start answering questions. The beauty of a graph database is, you just need to think about your data model and loosely think about how your entities are connected to each other. In a relatively short amount of time, you’ll have something that you can start loading data with. You get your data in, and it immediately captures your domain. So it can start answering questions straight away.
It figures out what the schema is as you’re putting data into the database. And as you start querying, you’re getting feedback, the answers to your questions. You can pull a project together very quickly.
And then, if you want to start looking at how you can optimize how your data is stored, the structure of your data in the database, you can now make changes relatively easily with the data as it stands in the database without necessarily having to get rid of everything and load it back in again. So this is a really powerful way of being able to rapidly prototype projects. You can answer questions quickly, and it gives you the edge of being able to get going as fast as possible.
The idea of intuitiveness in a graph model is much more closely aligned with how we think of data, and really especially how we work with data in our applications. It makes that whole process so much faster. We spend a lot of time thinking about building API applications, and oftentimes the way that we interact with an API is really in the context of relationships. So it really makes sense to model, store and query data as a graph, as you’re building out my applications.
Conclusion
Hopefully, we’ve got you all curious and keen to explore this new database paradigm. There are some options for you to check out, and what we would recommend as a starting point is to have a look at the Neo4j Sandbox.
We’ve got a blank one that if you are feeling adventurous and want to go and build something based on looking at the various documentations. But for those of you who just want to have a look and have a gentle guided journey, we have examples of recommendations, fraud detection, etc. already built in there. What you’ll find in that is pre-canned data, as well as walkthrough guides. So it will show you the data model, it will show you the queries, and this is a nice way to dip your toe in the water, and just have a look at what’s going on.
Will It Graph? Identifying A Good Fit For Graph Databases — Part 3 was originally published in Neo4j Developer Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.
