When would you use a Hashed Index vs. a standard B-Tree index?
Hashed indexes are specialized for equality queries and hash-based sharding, while B-Tree indexes are the general-purpose choice for supporting range queries, sorting, and equality lookups.
Choosing between a hashed index and a standard B-Tree index in MongoDB depends entirely on your query patterns and data distribution requirements. Standard B-Tree indexes are the default and most versatile type, optimized for a wide range of operations including equality matches, range queries, and sorting. Hashed indexes, on the other hand, are a specialized tool designed primarily for two scenarios: supporting hash-based sharding and performing equality lookups on fields that are typically large or have poor B-Tree selectivity.
- 1
Use B-Tree for range queries ($gt, $lt) and sorting - B-Tree indexes maintain order, hashed indexes do not
- 2
Use B-Tree for compound indexes with multiple query patterns - Hashed indexes support only one hashed field per compound index
- 3
Use B-Tree when you need unique constraints - Hashed indexes cannot be created with the unique option
- 4
Use B-Tree for fields containing arrays - Hashed indexes cannot be created on array fields
- 5
Use Hashed for hash-based sharding with monotonically increasing keys - Prevents write hotspots in sharded clusters
- 6
Use Hashed for equality-only queries on large string fields - Can be more memory-efficient than B-Tree
Scenario Questions
0-2 years experience
- 1We have a collection of user profiles and need to look up a user by their unique email address. Would you create a B‑Tree index or a hashed index, and why?
- 2If you add a hashed index on a field that is frequently used in range queries, what would happen to those queries?
2-5 years experience
- 1Our service stores order documents and runs queries that filter by orderStatus and also sort by orderDate. The team is debating between a B‑Tree compound index and a hashed index on orderStatus. How would you decide which to use?
- 2During a recent deployment, query performance on a high‑traffic collection dropped after we added a hashed index on the shard key. Walk me through how you would troubleshoot the issue.
5-8 years experience
- 1You are designing a multi‑tenant SaaS platform that shards data by tenantId. Explain how you would use hashed indexes versus B‑Tree indexes to balance query flexibility and even data distribution across shards.
- 2Our analytics pipeline runs large aggregation pipelines that need both equality matches and range scans on the same field. How would you structure indexes, and what compromises might you make?
8+ years experience
- 1A legacy system uses B‑Tree indexes for all fields, but we are moving to a sharded cluster with high write volume. Describe a migration strategy to introduce hashed indexes for shard keys while minimizing downtime and ensuring query correctness.
- 2At the organization level, how would you set guidelines for when teams should prefer hashed indexes over B‑Tree indexes, considering future schema evolution, operational monitoring, and cross‑team data sharing?
Follow-up Questions
- What impact does the index type have on write amplification?
- How would you monitor whether the chosen index is actually being used?
- Can you combine a hashed index with other index types in a compound index?