Solving the Endgame
Somewhere with few enough pieces on the board, chess stops being estimated and starts being solved. Tablebases are precomputed tables of perfect results — the engine stops calculating and simply reads the answer. Back then, that perfection came at a price measured in gigabytes, and I paid it across a stack of external drives, rationing which endings were worth the disk. Here's how those tables are built, and why they're the purest lookup in all of computer chess.
Perfect answers, read not calculated
A tablebase is a database of perfect results for positions with few pieces: every legal arrangement solved to win, draw, or loss — and, depending on the format, the exact distance to the finish. When the engine reaches a position the tablebase covers, it stops searching entirely and plays flawlessly, because there's nothing left to estimate. This is the one place in chess where the engine has no opinion — only the answer.
Retrograde analysis — working backwards from mate
You can't build a tablebase by searching forward; you build it backward. Start from every possible checkmate — the terminal, lost positions. Then find every position that can reach a lost position in one move: those are won-in-1. Then won-in-2, won-in-3, iterating outward until no new positions are added. When the process stops adding anything, you've labeled every legal position with that material as won, drawn, or lost, with distances attached. It's a fixpoint computation — a transitive closure over the graph of positions — and it involves zero human judgment.
Retrograde analysis is building a materialized transitive-closure table. It's the recursive CTE you'd write to compute reachability — seed with the terminal rows, repeatedly join to find what reaches them, iterate to a fixpoint — except the output is precomputed once and stored so every future query is an O(1) lookup instead of a recursion. The engine doesn't run the closure at play time; it reads the materialized result. That's the whole reason tablebases exist: pay the compute once, read forever.
Thompson, Nalimov, and the generators
The early work belongs to Ken Thompson — the same Bell Labs figure who co-created Unix — who generated 4- and 5-piece endgame sets in the 1980s and 90s and famously used them to find positions humans had misjudged for centuries. In the early 2000s, Eugene Nalimov's generator produced the tables that became the era's standard, indexed by distance to mate; the full 6-piece set was completed in the early-to-mid 2000s. These are the tablebases Fritz and Shredder probed, and the ones I hoarded.
Why I rationed endings across drives
The reason this page has a personal ache in it is the sizes. They explode as you add pieces:
5-man ≈ 7 GB. Full 6-man ≈ 1.2–1.4 TB. 7-man ≈ 140 TB. Each rank of pieces is a different storage era.
In those college years, a full 6-man set was more than a terabyte, and I had maybe 600 GB of external drives to my name. So tablebases became a curation problem: which endings were worth keeping? I kept the ones that actually came up — the pawn endings, the common piece-versus-pawn races — and let the exotic material go. I was, without the vocabulary for it, doing capacity planning: budgeting scarce storage against expected access frequency, evicting the cold data. It felt like collecting; it was really a caching policy with a hard disk quota.
How they got onto your machine — and into the search
You didn't generate these yourself; you bought or downloaded them. ChessBase sold Endgame Turbo CD and DVD sets, and the engine would probe the tables mid-search — the moment its calculation reached a covered position, it swapped estimation for the tablebase's perfect verdict. That probe, deep inside the search tree, is what let a mere estimate at the leaves become a proven result.
Nalimov to Syzygy — DTM, WDL, and DTZ
Nalimov tables index by DTM (Distance to Mate) — the exact move count to forced mate — which is precise but bulky. In 2013 Ronald de Man released the Syzygy format, now standard in Stockfish and Leela and dramatically more compact. Syzygy splits the job into two tables: WDL (win/draw/loss), small enough to probe constantly during search, and DTZ (distance to zeroing — moves to the next pawn move or capture), used to actually convert a won position.
The WDL/DTZ split is a covering index versus the full row. WDL is the narrow, hot index you probe millions of times mid-search — just enough to answer "is this won?" without touching the heavy data. DTZ is the full row you fetch only once you've committed to converting the win. It's the same design instinct as a covering index that answers the common lookup cheaply, with the wide table read reserved for when you actually need the rest of the columns.
The 50-move-rule blind spot, and the leap to 7 pieces
Tablebases exposed something genuinely strange: some positions are mathematically won but require 200, 300, even 500+ moves without a capture or pawn move to force mate. Under the 50-move rule, those "wins" are draws — technically winning, practically drawn, and utterly beyond human comprehension. DTM tables happily report a mate in 517; the rules of over-the-board chess say it's a draw. Syzygy's DTZ metric is at least 50-move-aware, which is part of why it won.
And the frontier kept moving. The 7-piece tablebases were completed in 2012 by the Lomonosov project (roughly 140 TB, DTM metric); the far more compact Syzygy 7-man set followed in 2018 (~18 TB), and that is the set you can query free online — you send a position to a web service and get a perfect answer back. The college student who rationed 6-man tables across drives could, today, just open a browser. From three hard drives to a web request in one generation.
Computed endings, curated openings
It's worth setting this beside its opposite, the opening books. Tablebases are computed: pure retrograde proof, identical for everyone, zero judgment. Opening books are curated: human taste over human games, editable and biased. The end of the game is solved by brute force; the start of the game is solved by taste; the middlegame, where neither reaches, is where the engine actually has to think.
Endgame tablebases — FAQ
How big are the 6-piece tablebases?
The full 6-piece Nalimov set is roughly 1.2–1.4 TB; the 5-piece set is about 7 GB. That jump is why hobbyists in the mid-2000s rationed which 6-man endings to keep. Modern Syzygy tables are far smaller: the Lomonosov 7-piece set (2012) is about 140 TB, the Syzygy 7-piece set (2018) about 18 TB — queried online rather than stored.
What's the difference between Syzygy and Nalimov?
Nalimov (2000s standard, used by Fritz/Shredder) indexes by Distance to Mate. Syzygy (de Man, 2013; used by Stockfish/Leela) is far more compact and splits into WDL (win/draw/loss, probed during search) and DTZ (distance to zeroing, for converting the win), and it's 50-move-rule aware.
How are tablebases computed?
By retrograde analysis: start from all checkmates, find everything that reaches a loss in one move, then two, and iterate to a fixpoint. The result is a perfect win/draw/loss label for every legal position with that material — a transitive-closure computation with no human judgment.
Do tablebases mean chess is solved?
No. They perfectly solve positions with up to 7 pieces, but the full game starts with 32 and the position count is astronomically beyond reach. Tablebases solve the endgame; the opening and middlegame remain unsolved.
Why can a tablebase win be a draw?
Some wins take far more than 50 moves without a capture or pawn move, so the 50-move rule scores them as draws. The position is mathematically won but practically drawn — one of the strangest things tablebases revealed.
- Chessprogramming Wiki — Endgame Tablebases, Retrograde Analysis, Nalimov Tablebases, Syzygy Bases.
- Ken Thompson's early endgame work; Eugene Nalimov's generator and the 6-piece completion.
- Ronald de Man, Syzygy tablebases (2013) — WDL/DTZ format used by Stockfish and Leela.
- Lomonosov 7-piece tablebases (2012, ~140 TB, DTM); the compact Syzygy 7-piece set (2018, ~18 TB) is the one queryable free online (e.g., via Lichess).
- ChessBase Endgame Turbo distribution sets. The drive-rationing account is the author's first-hand experience.
The other kind of stored knowledge
Tablebases are computed; opening books are curated. See the mirror image — or head back to how the engine thinks in the middlegame, where neither reaches.