Tablebases: The Only Part That Is Not an Estimate
For seven pieces or fewer, every position has been solved exhaustively. What a tablebase knows, what it cannot tell you, and the rule that stops some wins.
· 4 min read

Everything else an engine tells you is an estimate produced by searching part of the tree. A tablebase is different in kind. For positions within its reach, the answer was computed exhaustively and stored, and there is nothing left to be uncertain about.
What is covered
Every legal position with seven pieces or fewer, including both kings, has been solved. Six-piece tablebases are small enough to keep on a laptop; the seven-piece set runs to around 140 terabytes, which is why most people query it online rather than holding it.
The eight-piece problem is not being worked on seriously, because the storage requirement grows by roughly two orders of magnitude per piece.
How they were built
Backwards. Start from every position that is checkmate, which is trivially a loss for the side to move. Then find every position that can reach one of those in a single move, and mark it a win. Then every position where all moves lead to positions marked as wins for the opponent, and mark it a loss. Repeat until nothing changes.
The result is complete because nothing was skipped, which is why the answer is a fact rather than an opinion.
What it tells you, and what it does not
| Question | Tablebase answer |
|---|---|
| Is this position won, drawn or lost? | Exactly, with certainty |
| How many moves to mate with perfect play? | Exactly |
| Which move preserves the result? | Every one, listed |
| Is this position easy for a human to win? | No opinion |
| What plan should I follow? | None offered |
That last pair is the practical limitation. Tablebase play is often incomprehensible: pieces move to squares no principle would suggest, because the database is following the shortest path through a space it has memorised rather than executing an idea. You can copy the moves and you will not learn anything transferable from them.
The fifty-move rule cuts wins off
Some tablebase wins take longer than the rules allow. The longest known seven-piece win runs to 549 moves with perfect play, and the fifty-move rule ends the game as a draw long before that.
This creates a genuine gap between the theoretical result and the result you can achieve. A position marked as won may be drawable in a real game, and tablebases that account for this report a different answer than those measuring pure distance to mate. When a tool distinguishes them, it is worth reading which measure it is using.
When it matters in practice
Two situations. First, verifying whether an endgame you reached was actually winnable, which resolves the argument definitively rather than leaving it to an engine's estimate.
Second, and more useful, learning the handful of endgames that come up often enough to be worth knowing exactly: rook and pawn against rook, queen against pawn on the seventh, bishop and knight mate. For these, the tablebase gives you a correct answer to check your understanding against, which is exactly what practising an endgame against an engine that plays it perfectly provides.
For anything larger than seven pieces, you are back to estimates, and everything about reading evaluations applies again.
Why tablebase moves look wrong
Watching perfect play in a won endgame is a strange experience. The king walks away from the pawn it is escorting. A rook goes to a square where it appears to do nothing. Pieces circle for ten moves and then, without any visible change, the position collapses.
None of this is a plan in the sense a book would teach. The database is walking the shortest path through a graph it has memorised entirely, and the shortest path has no obligation to be explicable. Two positions that look nearly identical can have completely different move counts, and the database will treat them as unrelated because to it they are.
The consequence is that copying tablebase moves teaches you nothing. If you want to learn an endgame, learn the human method, which is longer but has reasons in it, and use the tablebase only to confirm that your method holds.
Practising against one
The most valuable use for an improving player is drilling. Set up a rook and pawn against rook position, play it against an opponent that consults the tablebase, and you get a defender who never errs.
That is a harsher test than any human opponent, and it is the correct one. Endgames where the defence has one saving move are exactly the endgames people lose, and practising against an opponent who always finds it is the only way to know whether you actually hold the technique or have simply been getting away with it.
Common questions
- What is a chess endgame tablebase?
- A precomputed database holding the exact result of every legal position with a small number of pieces, currently up to seven. It does not search or estimate. It stores whether the position is a win, loss or draw with perfect play, and how many moves the result takes.
- Why do tablebase wins sometimes take 100 moves?
- Because perfect play does not follow human plans. The shortest forced win in some seven-piece positions runs to over 500 moves, far beyond the fifty-move rule, so positions that are theoretically won are drawn under the rules of the game.
Try it on your own position
The analysis board runs the same engine in your browser, free. The app adds what a web page cannot: reading a position straight from a photograph, saved boards, and analysis with no connection.
