The Bottom-Line Business Benefits of Distributed Multi-Master Relational Databases

Today’s applications—including enterprise applica­tions—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 bot­tom-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 sin­gle instance of their databases located in a single data center or cloud region. Users located close to where the database is run­ning 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 appli­cation, the impaired user experience may result in customer churn.

A distributed “multi-master” database can be configured to run in a geographi­cally 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 prevent­ing lost sales and customer churn.

Now let’s look at ultra-high availability. What do we mean by that? Clearly, down­time is to be avoided, since it means frus­trated customers and lost business, depend­ing 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 pri­mary system is down.

There are several problems with this approach. First, in the cloud, the read rep­licas will likely be in nearby availability zones in the same region. The cloud pro­viders do have multi-hour failures of entire regions from time to time. In fact, this hap­pened 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 organi­zations have not done so. Additionally, with many popular open source databases such as Postgres, it is not possible to conduct software maintenance and upgrades with­out taking the entire system down.

A fully distributed multi-master data­base addresses these shortcomings. Since there are multiple nodes handling read and write traffic, a failure at one node sim­ply requires database requests to be redi­rected to any of the surviving nodes. Since the system is designed to be geographi­cally distributed, running across multi­ple regions is straightforward. Software upgrades can be performed node by node, avoiding the dreaded “scheduled mainte­nance” 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 multi­ple regions. With a distributed multi-master database, it can do so simply and cost-effec­tively. 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 defi­nitely 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-men­tioned 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 dis­tributed 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 dis­tributed 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.