What is a Graph Database? | Why GraphQL is Not a Graph Database
GraphQL is a query language and a server-side runtime (typically served over HTTP). However, you may have also heard of graph databases. What does GraphQL have to do with graph databases? Not so much.
In this post, we’ll clear up any confusion you may have about GraphQL and graph databases by learning about what graph databases are, the main ideas behind them, when they’re most valuable, and how they differ from GraphQL.
What is a graph database?
Graph databases are databases explicitly designed for the analysis of relationships. That is, we use graph databases when we’re interested in the analysis of relationships between data — not necessarily when we’re building the data store for your typical backend application.
Analysis instead of transactions
Let’s understand graph databases by comparing them to something we’re familiar with: relational databases. With relational databases, the big selling point — at least from your typical backend application use case — is the fact that you get data integrity and constraints. We have to pre-define a data model, build it, and only then are the bounds upon which data can be created, read, updated, and deleted from within it realized. A pre-defined model is often critical for business applications, specifically the ability to enforce how data enters the database transactionally.
Graph databases don’t require a pre-defined data model. The idea of constraints is much more relaxed. We use graph databases to infer conclusions about our data later. Graph databases are more useful for data scientists who need to perform queries on relationships that would be otherwise extremely expensive (and perhaps impossible) from a relational standpoint.
Nodes, edges, properties
Data enters a graph database through the abstractions of nodes, edges, and properties — all of which can be extended later on in the future without affecting existing functionality.
- Nodes represent entities (like
- Edges represent relationships between nodes (like the relationship between a
Student). Edges also have directionality to them. For example, you could say that a
- Properties exist to describe edges with more detail or to describe potential behaviors. For example, a
Teacheredge could contain properties that describe the
semesterin which the class was taken.
Common use cases
What are some common use cases for graph databases? Some of the most popular use cases are:
- Fraud detection
- Recommendation engines
- IT network management
- Graph algorithm computation
What is the relationship between GraphQL and graph databases?
Fundamentally, there is no relationship. Besides the fact that GraphQL and graph databases have the word “graph” in their name, they were designed for two entirely separate purposes.
GraphQL, the query language, was created to make it easier for app developers fetch data by asking specifically for what they want, while graph databases were designed to allow for performant analysis of relationships between entities.
Are there any advantages to using a graph database as your data source for your GraphQL API?
The main advantage I can think of for using a graph database as a data source is a shared mental model between edges, nodes, and properties between GraphQL and graph databases. You can model your GraphQL schema similarly to the way we think about the main abstractions in graph databases.
However, it’s a good idea to consider what you’re building. For many developers building standard web applications that rely on transactions and a constrained data model, a relational database may be a better choice.
In conclusion, GraphQL and graph databases are both graph-related by design, but we use them for entirely separate purposes. GraphQL is the query language used to design and query your company’s data graph in a typical web application architecture. In contrast, graph databases are a specialized type of database to analyze your data and draw useful conclusions.