GraphQL is a big problem: why isn’t it the industry standard for database queries?

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

On average, the world generates approximately 2.5 trillion 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 example, a customer service smartphone app that allows customers to see if they are satisfied or if they have problems and need help solving problems). 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’s 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.

While 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 queries, although GraphQL is growing in popularity.

How does GraphQL compare to SQL and is there a way to take advantage of both when running queries?

GraphQL vs SQL: The Broad View

GraphQL has a relatively simple, readable format for data access. The unique format allows for something called ‘nesting’. Nesting is akin to asking a question inside another question to get a more specific answer. For example, instead of just asking for a list of all dogs in a given shelter, you could ask for a list of all dogs and nested details of those dogs’ breeds (drawn from an entirely different, even third party data source).

GraphQL’s query nesting capability allows a frontend developer to retrieve the relevant information from an API in a single request. Since GraphQL is almost a universal query language, which allows you to easily process different data sources, 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 types of data sources besides just databases.

SQL is immensely popular as a database query language. Unfortunately, it doesn’t work for nested queries across heterogeneous data in the same way as GraphQL. In addition, the syntax of SQL can be complicated. Finally, SQL was never meant to be universal. SQL works fine for various databases, but not so great for APIs.

GraphQL vs SQL in action

Suppose you are in the process of restocking your company’s inventory and you need to know the tracking number and expected delivery date for two different orders shipped by two different companies. GraphQL could 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 between the pieces of data you’ve requested. In other words, you can see that the delivery date of your package is related to the tracking number you received.

For SQL, you may need to make one request to your database for general information about the two different orders. Then you may have to search that information to find the names of the shipping companies, followed by another request to each shipping company for tracking numbers. Finally, based on the tracking number, you can make one more request to get the expected delivery dates. Getting all that information would require a lot of code, and getting the syntax just right might not be easy. Personally, I’ve been working 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 scheme allows only a subset of operations, depending on the developers implementing that API. In other words, how flexible your searches can be depends on how flexible the API developers are. For example, an API allows you to search for customers only by email. To search customers by city, the application should collect all customers and then filter them one by one. Talk about complicated.

Or if you’re dealing with sensitive data, you may need to configure your queries and APIs for factors such as determining who can access the data or how long the data is cached (temporarily stored) in the backend. Such configurations are a tall order for the average business, 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 configuration can be difficult without such technologies.

In contrast, SQL is more expressive from the start, meaning it’s easier to tell the system what you want without a lot of extra configuration. You can easily ask any database “for customer John Doe, give me orders over $100”, using a single line of code. SQL gives you what you need regardless of the database structure.

As I like to say, GraphQL allows flexible queries within the framework set by the developer who built the API. SQL enables universal queries on any database model. So if you mainly search databases, SQL will do the job well.

Is there a way to bridge the gap?

What if you could leverage the expressive features of SQL and the flexibility of GraphQL at the same time? There are technologies out there that claim to do that, but they are unlikely to become popular as they end up being clunky and complex. The clumsiness stems from attempts to force SQL constructs in GraphQL. But they are different search languages ​​with different goals. If developers need to learn how to do SQL constructs in GraphQL, they might as well use SQL and connect directly to the database.

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 worldviews: unified backends versus diverse backends, tables versus hierarchical data, and universal queries versus constrained queries. As a result, they serve different purposes.

GraphQL, despite its popularity as an API query language, will not deprive SQL as the primary language for database access.

Anant Jhingran is CEO and co-founder of StepZen.