Today’s applications—including enterprise applications—need to be always on and always available and often must serve a global base of users who expect almost instantaneous response times regardless of where they are located.
Meeting these challenges doesn’t just mean happier users: There are direct bottom-line benefits for every business able to tackle the underlying issues of low latency and ultra-high availability. Because of the fundamental role the database plays in every application tech stack, the most logical place to tackle these issues is at the database layer. One of the best and most cost-effective ways to do this is by deploying applications on top of a distributed relational database.
Let’s first consider the problem of data latency. Many applications run with a single instance of their databases located in a single data center or cloud region. Users located close to where the database is running will see fast response times, but those on the opposite coast or across an ocean will see much slower response times. For an ecommerce application, slow page loads result in lost sales as the buyer loses patience and goes to a competitor site or reconsiders the purchase. For a SaaS application, the impaired user experience may result in customer churn.
A distributed “multi-master” database can be configured to run in a geographically distributed cluster of nodes, each of which can accept read and write traffic. This makes it possible to strategically place copies of the database closer to where the users are connecting to the network. This significantly reduces data latency, yielding consistently faster page loads and preventing lost sales and customer churn.
Now let’s look at ultra-high availability. What do we mean by that? Clearly, downtime is to be avoided, since it means frustrated customers and lost business, depending on how long and widespread the outage is. An application is highly available if it can continue running in the wake of hardware and data center outages. Many application and database architects will configure and read replicas of their databases in one or more geographically separated data centers, allowing for a failover to occur when the primary system is down.
There are several problems with this approach. First, in the cloud, the read replicas will likely be in nearby availability zones in the same region. The cloud providers do have multi-hour failures of entire regions from time to time. In fact, this happened in recent weeks with both AWS’s us-east-1 region (its largest) and Google’s europe-west-9 region, causing many hours of downtime for applications solely reliant on them. It can be difficult to architect and implement a multi-region failover solution, which is a major reason why many organizations have not done so. Additionally, with many popular open source databases such as Postgres, it is not possible to conduct software maintenance and upgrades without taking the entire system down.
A fully distributed multi-master database addresses these shortcomings. Since there are multiple nodes handling read and write traffic, a failure at one node simply requires database requests to be redirected to any of the surviving nodes. Since the system is designed to be geographically distributed, running across multiple regions is straightforward. Software upgrades can be performed node by node, avoiding the dreaded “scheduled maintenance” windows.
Perhaps you’ve been in the awkward position of having to explain to your CEO or board why your application was down when your cloud provider had a regional outage. After they absorb the concept of cloud regions, you are inevitably asked why the application is unable to run across multiple regions. With a distributed multi-master database, it can do so simply and cost-effectively. By the way, if you are a CEO or a board member of a SaaS company, you might want to ask your team if the company’s app can withstand a cloud region outage!
Finally, why are we specifically talking about relational databases here? It is definitely the case that the benefits of distributed databases have been available in the NoSQL world for a good number of years. However, many existing enterprise applications are built on top of relational databases, which are more flexible and have a greater array of tools and talent to support them. The above-mentioned benefits can be opened to existing applications by redeploying them on top of a distributed relational database, often with limited changes to application code. This migration can be done in conjunction with a move from an expensive legacy database solution to an open source database such as Postgres, thereby saving a great deal of money in licensing fees. Postgres is now the most popular open source database among developers, so this will make both your developers and your users happy.
To sum up, moving applications to a distributed multi-master relational database can drive substantial bottom-line benefits. These benefits come in the form of either a reduction in lost sales and customer churn through lower latency or through downtime avoidance thanks to the multi-master distributed architecture. And, almost as a bonus, you’ll have happier users and customers— and happier developers too if you also make the move to an open source database.