YugobyteDB founders, when they started building the database itself, they wanted to build a database which can provide high availability like Amazon Aurora while supporting all the RDBMS features and also provide a distributed capability like Spanner where you can horizontally scale the relational workload as well as support your distribution. So, obviously, when coming to the actual topic, when it comes to the GraphQL itself, GraphQL is pretty simple how you get started. You have a GraphQL server, you connect it to your database, and you can start working with building your APIs.
As and when you finish building your API, you get to this problem where how do you scale your services, right? One of the harder problems is to scale your database workload itself. So, the database can reach its resource limitations, you might have to do query limiting, the latencies might increase. In order to that distributed SQL will help where you can keep adding new nodes to the cluster and it can easily scale out the workload without having much management things that as a developer you'll have to do. You just run a cli command on the graphical UI, you just say, scale from 500 transactions to 1000 transactions, it will automatically figure out what needs to be done behind the scenes and scale out the cluster.
And also apart from scaling out the database there's like few things that you have to take care when you want to run always on kind of a service, right? Obviously, where you deploy your database, whether you deploy it in your one region or a different cloud that matters. With distributed SQL like you got by DB, you are able to make use of the geo distribution topologies we support and you can either deploy across different availability zones, regions or cloud. Recently, we had that Amazon cloud outage right where both east and west regions went down for that many of the internet scale applications like popular apps went down. In order to avoid such a thing you would want to deploy your applications on two different clouds so that one of the main things you would want to do in such cases is to have your data tier available across the globe or across the geographical locations. That's how distributed SQL topologies will help to continue your business so that you don't have a lot of financial loss. And also you're able to do things like geo-partitioning and data compliance. In Nougatbyte, there is a concept of row-level data placement where based on a certain column, like a geographical location, E.U. or U.S., you can have certain rows only reside in the server of that particular region. Such that you would not have to manually take care of the compliance. The database will do it for you. That's how we have been able to develop this database from ground up for the cloud-native architecture, keeping the modern database technologies and data tier requirements in mind.
One of the things for us to make sure that Nougatbyte can work for the GraphQL kind of workloads, what we did is we took GraphQL subscription and we wanted to scale it out linearly, so that we know whenever we are going to the customer or the actual production workload itself, what we are able to do and obviously numbers talk all the time. We started with a simple three-node cluster where we were handling around 25,000 subscriptions and we were able to linearly scale out that workload, the GraphQL workload, it was a simple GraphQL workload which we had serving through Hasura, but the database itself was able to scale to handle 25,000 transactions to a million subscriptions such that we didn't have to do a lot of things. The same architecture was able to scale to 1 million subscribers just by adding new nodes to the database. So you can start small, as and when your GraphQL workload or the services or the API that you are serving through GraphQL kind of increases or increases in use, you can keep adding new nodes. So it will be much simpler than adding read replicas or other things because the distributed SQL database knows how to place the data and how to route the query traffic and kind of all the other things that are required for handling a distributed kind of a process is already built into the database. That's how we are able to easily scale out the database.
If you are interested in this particular piece of exercise, you can go ahead and see our GitHub. You can go to Navigate to Yugabyte and Yugabyte GraphQL Apps. You will see that. Obviously, you might be thinking how do I try it out, right? It's an open source database. You can just download the database on your Mac laptop and you can just quickly start it up. And also we are providing – recently we announced our Yugabyte Cloud platform where you can go ahead and start a free trial instance of Yugabyte DB and play around with your GraphQL workloads. It is super simple. It kind of takes care of all the install and manage part of running the database and also it supports linear scalability. It will be super easy for you to get started and if you have any questions regarding how you can get started with cloud or Yugabyte DB, please reach out to us. You can reach out to us on our Slack. We will be always active on Slack and also we are actively hiring a lot. We are now a unicorn company. If you are interested in solving distributed SQL or some of the GraphQL related workloads with Yugabyte DB, please feel free to see our careers page.
Comments