When is a hash index better than a B-tree index?
A hash index is faster for exact-match lookups (WHERE id = 5) because it computes a hash and jumps directly to the bucket — no tree traversal. But it can't serve range queries (WHERE age > 30) or sorted output at all, since hashing destroys ordering. B-trees are slightly slower for exact matches but handle both exact matches and ranges, which is why they're the default in most relational databases.
Answered in
Database Indexing Explained: Which Index Type Actually Fits Your QueryB-tree, hash, composite, and covering indexes each solve a different query shape. Pick the wrong one and you pay index overhead without the speedup.
Read the full analysisOther questions this article answers
More system design questions
- Why does a database need an index at all — why can't it just scan the table?
- What is a composite index and why does column order matter?
- What's a covering index and why is it faster than a normal index?
- What's the real cost of adding an index, beyond disk space?
- What does ACID actually stand for, and why do all four properties matter together?
- What's the practical difference between pessimistic and optimistic concurrency control?
- What is a race condition in a database transaction, and how does isolation prevent it?
- Why would a database ever allow a weaker isolation level than Serializable?
Every answer on Crashtech is written by the editor of the article it comes from — never auto-summarised. Browse all answers or the System Design beat.