GraphQL is a big deal: Why isn’t it the industry standard for database querying?

GraphQL is fast becoming a go-to query language for companies to interact with their data. Although data management is one of the top concerns for a lot of companies, many people don’t really understand what GraphQL does or why it’s so popular. 

On average, the world generates about 2.5 quintillion bytes of data per day. Businesses need a way to collect that data and use it effectively. A lot of data is generated in apps (for instance, a customer service smartphone app that lets clients tell you if they’re satisfied or if they’re having any issues and need help troubleshooting). Apps need a way to get information to the backend; that is, the tools for managing and storing data. Then data can be analyzed to discover problems and develop solutions. And of course, it is bi-directional. Not only do apps send data to backends, but apps need data from the backend. For example, recommendations, the status of a delivery, account balances. And that’s what GraphQL is for: Getting data to and from the backend. It is a more modern API that connects apps to backends.

Although many tech leaders may have heard of GraphQL, they have probably heard a lot more about SQL (Structured Query Language). SQL is essentially the industry standard for database querying, although GraphQL is growing in popularity. 

How does GraphQL compare to SQL, and is there a way to get the benefits of both when performing queries?

GraphQL vs. SQL: The broad view

GraphQL has a relatively simple, readable format for data access. The unique format allows something called “nesting.” Nesting is akin to asking a question within another question to get a more specific answer. For example, instead of just asking for a list of all of the dogs at a particular shelter location, you might ask for a list of all of the dogs and nested details of the breeds of those dogs (pulled from an entirely different, even third party data source). 

GraphQL’s ability to nest queries allows a frontend developer to fetch, in one request, the relevant information from an API. Since GraphQL is almost a universal query language, handling different data sources with ease, you can also query multiple APIs and other data sources at the same time. So GraphQL is the right query language for heterogeneous backends, meaning backends with different kinds of data sources besides just databases. 

SQL is immensely popular as a query language for databases. Unfortunately, it doesn’t work for nested queries across heterogenous data the same way GraphQL does. Plus SQL’s syntax can be complicated. Lastly, SQL was never intended to be universal. SQL works great for different databases, but not so great for APIs. 

GraphQL vs. SQL in action

Let’s say you’re working to restock your company’s inventory and you need to know the tracking number and expected delivery date for two different orders shipping from two different companies. GraphQL would be able to get all that information in one request. 

GraphQL also shows you that information in a hierarchical structure that makes it easy to see the relationship among the pieces of data you requested. In other words, you can see that the date of delivery for your package is related to the tracking number you received. 

For SQL, you might need to make one request to your database for general info on the two different orders. Then you might need to sort through that info to find the names of the shipping companies, followed by another request to each shipping company for tracking numbers. Lastly, based on the tracking number, you could make another request to get the expected delivery dates. Getting all that information would require a lot of code, and it might not be easy to get the syntax just right. I personally have been dealing with SQL databases for decades, and even I often have to look up the syntax for complex queries.

Why is SQL still so popular? 

A GraphQL API schema only permits a subset of operations, depending on the developers who implement that API. In other words, how flexible your queries can be depends on how flexible the API developers are. For example, an API only allows you to search for customers by email. To search customers by city, the application would need to gather up all customers, then filter them one by one. Talk about complicated. 

Or if you’re dealing with sensitive data, you might need to configure your queries and APIs for factors such as controlling who can access the data, or how long the data is cached (temporarily saved) on the backend. Such configurations are a tall order for the average company, but many technologies are now available to manage and configure GraphQL queries and APIs for you. These technologies make GraphQL a viable option for querying APIs, but without such technologies, configuration can be difficult. 

In contrast, SQL is more expressive from the start, which means it makes it easier to tell the system what you want without a lot of extra configuration. One can easily ask any database “for customer John Doe, give me orders whose amount exceeds $100,” using a single line of code. SQL will give you what you need, regardless of the database structure. 

The way I like to say it is this: GraphQL permits flexible queries within the framework set by the developer who built the API. SQL permits universal querying on any database model. So if you’re primarily querying databases, SQL will do the job nicely. 

Is there a way to bridge the divide?

What if you could leverage the expressive attributes of SQL and the flexibility of GraphQL at the same time? There are technologies available that claim to do that, but they are unlikely to become popular because they end up being awkward and complex. The awkwardness arises from attempting to force SQL constructs into GraphQL. But they are different query languages with different purposes. If developers have to learn how to do SQL constructs in GraphQL, they might as well use SQL and connect to the database directly. 

However, all is not lost. We believe GraphQL will become more expressive over time. There are proposals to make GraphQL more expressive. These may eventually become standards. But fundamentally, SQL and GraphQL have different world views, respectively: uniform backends vs. diverse backends, tables vs. hierarchical data, and universal querying vs. limited querying. Consequently, they serve different purposes.

GraphQL, in spite of its popularity as an API query language, is not going to unseat SQL as the primary language for database access. 

Anant Jhingran is CEO and cofounder of StepZen.