🌐 Distributed SQL
Whether your workload needs a relational database spread across machines, and what that costs before anybody installs one — the ceiling, the three reasons teams adopt this and why only one is throughput, why a commit becomes a conversation, and the latency floor physics sets. Teaches no product.
No lessons published yet — this is the roadmap, so you can see exactly what the course will cover before it lands.
Before you start: PostgreSQL — Series 1, and Series 2. Every decision in this track is a decision you already know how to make on one machine, changed by the rows being spread across several. Series 2 there is indexes, plans and statistics, and Series 2 here is what happens to each of them.
Short on time? The 15 episodes marked core are the shortest path to being productive at work. Start there and pick up the rest whenever a job asks for them.
Series 1 · The Problem, and the Idea
the ceiling, what was tried first, and what a commit becomes
- 01
The Ceiling — One Primary, and Why You Cannot Buy Your Way Past It
coreintermediatecoming soon - 02
Three Reasons Teams Adopt This — and Only One Is Throughput
coreintermediatecoming soon - 03
Replicas, Manual Shards and Middleware — What Teams Do Before This
coreintermediatecoming soon - 04
Consensus, in One Episode — Why a Commit Becomes a Conversation
coreintermediatecoming soon - 05
Project — Decide Whether Your Workload Actually Has This Problem
coreintermediate#projectcoming soon
Series 2 · What Changes in Your Schema
keys, transactions, indexes and joins, all changed by distance
- 01
The Primary Key — Now a Placement Decision, Not Just an Identity
coreadvancedcoming soon - 02
The Sequential Key — One Mistake, Three Products, Dashboards That Look Fine
coreadvancedcoming soon - 03
Locality and Survival Goals — Latency Against How Much Failure You Survive
coreadvancedcoming soon - 04
Transactions Become Retryable — the Application Change Nobody Budgets For
coreadvancedcoming soon - 05
Indexes and Joins When the Rows Are Spread — Which Side Moves, and What It Costs
coreadvancedcoming soon - 06
Project — Take a Working Schema and Predict Which Decisions Break
coreadvanced#projectcoming soon
Series 3 · The Landscape, and the Decision
the four, the other route, physics, and the honest gate
- 01
The Four — What CockroachDB, YugabyteDB, TiDB and Spanner Each Chose
coreadvancedcoming soon - 02
Sharding Middleware — Keeping the Engine You Already Operate
advancedcoming soon - 03
Managed and Serverless — When a Bad Access Pattern Becomes an Invoice
advancedcoming soon - 04
The Latency Floor — Physics, and the Chatty Transaction Nothing Can Fix
coreadvancedcoming soon - 05
When You Do Not Need This — One Postgres Goes Further Than the Proposal Says
coreadvancedcoming soon - 06
Project — Write the Memo, With the Latency Number In It
coreadvanced#projectcoming soon
Where this leads
- CockroachDB — starts from Series 1, and Series 2.
Not here, on purpose
- Any one product, hands-on — covered in CockroachDB, which is this category taught as a running cluster and assumes this course. Here every product is an example of a compromise, never the subject
- SQL itself — covered in Learn SQL. This track changes where the rows are, not the language
- The non-relational data models — covered in NoSQL Concepts, and NoSQL Concepts, Series 4 · 05 names this category and points here. This is the relational answer to the same pressure
- Consensus, quorums and CAP as distributed-systems theory — covered in NoSQL Concepts, Series 3. In this course, Series 1 · 15 covers only what consensus does to one of your commits
- Operating a cluster — provisioning, monitoring, capacity, on-call — covered in Data Ops for the discipline
- Analytical workloads and warehousing — covered in Data Warehousing, and ClickHouse for the engine. These systems are built for transactional work spread across machines, and a large analytical query is not what they are for