Everything You Need to Know about Distributed SQL
Distributed SQL is generating a lot of buzz lately, and for good reason. Relational databases are trusted by every company in the world to run their mission-critical applications. But as the first innovators began shifting to online business and customer engagement, relational databases couldn’t keep up. NoSQL databases captured the spotlight with their ability to support modern web applications with massive workloads, but they did so by sacrificing consistency and data integrity. Distributed SQL is the best of both worlds.
A distributed SQL database is made up of multiple database instances working together (i.e., nodes in a cluster), with each one storing and querying a subset of the data rather than all of it. Simply add more instances to increase storage capacity and/or query performance. And of course, in order to guarantee strong consistency, all copies of data (i.e., replicas) are synchronously written at the same time.
Let’s go through a few examples where distributed SQL is a good fit:
Until recently, there haven’t been a lot of options when it comes to scaling relational databases. The first was to scale up, to replace an existing server with an even bigger one. And when the biggest commodity server was no longer enough, some companies turned to hardware appliances such as Oracle Exadata. The second was to scale out with sharding. This became an alternative for tech giants with deep engineering expertise and anyone else unwilling or unable to spend millions of dollars on a hardware appliance. However, while more cost-effective than scaling up, sharding tends to be brittle, difficult to maintain and limited in scope — often specialized to support specific applications and queries. With distributed SQL you get uncompromising scalability for any application without having to spend a fortune on a hardware appliance or accept the limitations and technical burden of sharding.
Database workloads are often quite variable. Distributed SQL is engineered to ramp up capacity in response to seasonal and business requirements. It lets you run with a few resources when that’s all that is needed, and quickly add more to handle spikes in your business. This elasticity is critical for a myriad of applications.
The ability to adapt to changing conditions on the fly is a key differentiator from other SQL iterations. Distributed SQL allows you to add nodes on-demand and scale-out. It also eliminates the issue of having to change your shard key or modifying how the data is split. Trust me — no one wants to spend their time sharding.
Some distributed SQL databases can also spread data across various database instances, constantly checking to ensure that the most optimal, efficient distribution of data is in use. If there is a change in customer behavior or there are new applications, it’s looking to see if moving the data around a little bit here and a little bit there will enhance performance.
