openskills.info
Course catalog
Course Preview

Distributed SQL Databases

Distributed SQL databases store relational data across several machines while presenting one SQL database to applications. They coordinate replicas and transactions so the database can keep consistent data as it scales or survives machine and site failures.

itDatabases and data storage

Don't Panic — Distributed SQL Databases

A distributed SQL database is what happens when a relational database refuses to choose between tables and more machines. It still accepts SQL, indexes, constraints, and transactions. Behind the polite counter, it divides the keyspace into partitions, makes replicas, and asks those replicas to agree before a change counts. The application sees one database. The database sees a surprisingly large amount of geography.

Before this arrangement, teams usually chose a conventional relational server or manually split data across several of them. The first choice keeps coordination nearby but eventually meets one machine's limits. The second spreads storage, then quietly gives the application a second job: know which shard owns a row and coordinate anything that crosses shards. Distributed SQL moves much of that plumbing into the database. It does not put the network in a cupboard under the stairs.

The useful mental picture is partitioning plus replication. A partition is a unit of distinct data placement; a replica is a copy of that unit. Splitting a partition makes more ownership units. Adding replicas helps a unit survive failures or serve suitable reads. They are different levers, which is fortunate because a system confusing its levers is usually busy inventing new forms of inconvenience.

Then comes the quorum, the set of voting replicas needed to approve a change. With three voting replicas, two can continue when one fails. One alone cannot safely keep accepting conflicting writes. This means a cluster can look alive while a particular partition is unavailable. That is not a contradiction. It is the database declining to turn an uncertain story into a confident lie.

The surprise is that SQL does not erase placement. A primary key that keeps new writes at one ordered edge can create a hot partition. A transaction that touches several partitions needs more coordination than one that stays local. A quorum across regions survives a wider failure but adds wide-area delay to writes. Familiar statements therefore acquire unfamiliar costs, like a small dog discovering it has inherited a railway.

The Course tab explains the layers and write path. Slides compress the tradeoffs into a map. Cheatsheet is where to keep the vocabulary, quorum arithmetic, key rules, and incident signals nearby. Field Notes names the production mistakes that arrive after the sales diagram has gone home. Reference links lead to the product-specific contract, because isolation defaults, retry behavior, and read choices are details that deserve more respect than a broad label.

Where this skill leads

Relevant careers

See how this topic contributes to broader role-level skill maps.

Sources