Tech, ExplainedData platforms and AI
Product

Distributed SQL database

PostgreSQL that spreads across continents.

BEFORE ITAFTER ITDistributed SQL databaseYugabyteCOVERSPostgreSQL-compatibleAutomaticsplittingMulti-regionSurvives failuresRelational databasehandsover itsapp unchangedruns as arentedserviceDatabase as aservice (DBaaS)CONCEPTS IT USESRedundancyOpen source business modelBEFORE ITAFTER ITDistributed SQL databaseYugabyteCOVERSPostgreSQL-compatibleAutomaticsplittingMulti-regionSurvivesfailuresRelationaldatabasehandsover itsapp unchangedruns as arentedserviceDatabase as aservice (DBaaS)CONCEPTS IT USESRedundancyOpen source business modelBEFORE ITRelational database↓ hands over its app unchangedDistributed SQL databaseYugabytePostgreSQL-compatibleAutomatic splittingMulti-regionSurvives failuresAFTER IT↓ runs as a rented serviceDatabase as a service (DBaaS)CONCEPTS IT USESRedundancyOpen source business model
The distributed SQL database takes over an app written for a relational database without changes, and is rented as a managed database service that runs its machines.
opens a page inside this one a page in the same scene a page in another scene a concept page a label only, with no page

A distributed SQL database is a relational database that spreads its data across many machines, and even across cloud regions, while the app still sees one ordinary database that it queries in SQL. A cloud region is a group of data centres in one city. Many distributed SQL databases are built to work like PostgreSQL, the popular free relational database. So an app written for PostgreSQL can use them without changes.

Why is one machine not enough? An ordinary relational database runs on one main server. When the app grows, that server runs out of processing power or memory. And if the server fails, the app stops until a standby copy takes over. Splitting the data across servers by hand is possible, but the app's code then has to know which server holds which customer.

A distributed SQL database does the splitting itself. It cuts each table into pieces, and keeps every piece in three copies on three different machines. A change counts as saved only when at least two of the three copies have recorded it. This is called consensus. So if one machine or even one whole region fails, the other copies still hold every saved change, and the database keeps working. This idea is called redundancy. The cost is time. A write that must reach copies in two cities takes several milliseconds longer than a write on one machine.

Take a stock trading app based in Mumbai. At 9:15 a.m., when the stock market opens, lakhs of investors place orders within the first minute. The app's database runs on nine machines, three each in cloud regions in Mumbai, Hyderabad and Delhi. Each order is saved only after copies in two regions have recorded it. One morning, a power fault takes the Mumbai region offline. The copies in Hyderabad and Delhi still hold a majority of every piece. Within a few seconds the database carries on taking orders, and no saved order is lost. Every copy stays inside India, which matters, because Indian rules require many kinds of financial data to be stored in India.

The same design lets a global company keep each customer's data near that customer, in a region on their own continent.

Several distributed SQL databases are open source, and their makers earn by selling a managed version and support; the open source business model explains how. Many buyers rent one as database as a service (DBaaS), so that someone else runs the machines.

How is it different from an ordinary relational database? The tables, the SQL and the transactions are the same. The difference is underneath: the data lives on many machines, and the database survives the loss of some of them. The data still has to be copied to a warehouse for analysis, as the page on OLTP and OLAP explains.

Tech, Explained is a part of ingrid.fyi. Every page explains one piece of technology in plain words.