History — 2026 week 32 (Aug 3 – Aug 9, 2026)
Newest first.
2026-08-06 — Over-sharding as a resource failure (0 new, 2 updated)
A shard’s cost is close to fixed regardless of what it holds: each is a complete Lucene index with its own segments, file handles, and refresh and merge cycle, so a cluster carrying thousands of near-empty shards spends most of its work producing nothing. Sharding now covers that failure mode — how index-per-tenant arrives at it, why per-shard heap residency and master-side cluster state break before query latency does, and the sizing floor that follows: roughly twenty shards per gigabyte of heap, with one shard as the starting default. It also separates the case from Compute-Storage Disaggregation, which dissolves the recovery argument for moderate shards but leaves per-shard overhead untouched.
Updated — Sharding · Multi-Tenancy in Search (links the new section)
2026-08-06 — Multi-tenancy in search (1 new, 4 updated)
Serving many customers from one search system reduces to one question: at what
level does one tenant’s data become physically separate? Multi-Tenancy in Search
sets out the four-rung isolation ladder — a tenant filter field, a named
partition, an index per tenant, a whole cluster — and pins each engine’s
mechanism to a rung: Elasticsearch _routing, Solr composite ids,
Vespa streaming mode, Algolia secured API keys, a namespace per tenant in
Pinecone and Qdrant. Between the
rungs sit the failures: tenant sizes follow a power law that ages any routing key
badly, and BM25 computes IDF corpus-wide, so one tenant’s bulk import
reorders another’s results. Built from vendor documentation; Sharding and
Extreme Search Systems now hand off to it.
Topics — Multi-Tenancy in Search Updated — Sharding · Extreme Search Systems · Unified Search Index · Compute-Storage Disaggregation (backlinks)
2026-08-05 — Search at extreme scale (7 new, 7 updated)
Scale never strains a system uniformly; it finds the one coupling nobody budgeted for. Extreme Search Systems catalogs twelve axes along which search gets harder, each anchored to a worked example, and the pattern across them is that what breaks is rarely what was scaled — Uber Eats grew its delivery radius and index layout became the bottleneck; Zalando grew traffic and its own facet queries took the cluster down. Nathan VanBenschoten’s account of raising a turbopuffer Search DB namespace from 4 TB to 256 TB supplies the storage axis: under Compute-Storage Disaggregation a lost node costs a 2–4 GB/s cache refill, not a rebalance, so performance tracks working set rather than corpus size and Sharding’s case for small shards weakens.
Articles — How to Build a 256 TB Search Index Concepts — Sharding · Compute-Storage Disaggregation (object storage authoritative, local disk cache) Topics — Extreme Search Systems People — Nathan VanBenschoten Companies — turbopuffer Tools — turbopuffer Search DB Updated — Search Architecture · Search Platforms · Uber Eats - Scaling Search for Food Delivery · Zalando - Self-DoS via Facet Aggregation · Reddit - Vector Database Selection · Canva - Search Pipeline Modernization · Vinted - Migrating Search from Elasticsearch to Vespa
2026-08-05 — Ranking at scale at Booking.com (14 new, 8 updated)
In a commercial ranking system the choice of algorithm is the least of the problems: Beyond Algorithms puts the value in modelling, experimentation and serving instead. Two-Sided Marketplace Ranking carries the structural half — conversion is the natural label and it is sparse and delayed, cold start is permanent rather than initial because new supply never stops arriving, and Impression Bias withholds exactly the exposure that would generate a new listing’s history. Isolated Feedback Loops names the experimentation trap: a self-learning ranker leaks between arms, so ranking experiments are not independent. From the open-access RecSys 2020 paper; the Medium review of it is a paywalled stub.
Articles — Beyond Algorithms - Ranking at Scale at Booking.com · Paper Review - Ranking at Scale at Booking.com (paywalled stub) Concepts — Ranking Signal Selection (four-axis label tradeoff) · Isolated Feedback Loops (RCT leakage in self-learning rankers) · Impression Bias · Out-of-Time Validation · Hashing Trick Topics — Two-Sided Marketplace Ranking People — Themis Mavridis · Soraya Hausl · Andrew Mende · Roberto Pagano · Jose Parreño Companies — Booking.com Updated — Interleaving (online-evaluation depth) · Position Bias (vs impression bias) · Implicit Judgments · A-B Testing for Search (ranking experiments are not independent) · E-commerce Search · Airbnb · Skyscanner · Netflix
2026-08-05 — Model evaluation and benchmark landscape (10 new, 6 updated)
Two different activities share the word evaluation: public benchmarks measure general capability on someone else’s data, your own judgments measure your search. Retrieval Benchmarks and Leaderboards maps the first — MS MARCO as the training corpus underneath almost everything and therefore a contamination risk, BEIR as the saturating proof of generality, MTEB whose v1 and v2 scores are not comparable, and RTEB, whose private held-back half exposes a model that was trained on the test. Model Selection and Fine-Tuning Evaluation covers running a bake-off without fooling yourself, and Embedding Models Compared the axes that actually bind — dimensionality, prefix awareness, serving footprint — over an August 2026 roster that will date.
Concepts — Contrastive Learning · Statistical Significance in Search Evaluation Topics — Embedding Models Compared · Model Selection and Fine-Tuning Evaluation · Retrieval Benchmarks and Leaderboards Datasets — MTEB · RTEB (open/private split against overfitting) · BRIGHT (reasoning-intensive retrieval) · MIRACL (multilingual) · LoTTE (long-tail stratified) Updated — Embedding Fine-tuning · Embeddings · Search Quality Assurance · Relevance Evaluation Tools Compared · BEIR · MS MARCO
2026-08-05 — Scalable relevance engineering at searchHub (2 new, 6 updated)
Most query-document pairs are obviously relevant or obviously irrelevant, and a small model settles them as well as a large one — which makes running an LLM as Judge over everything mostly waste. Staged Judging is the cascade that exploits the skew: prune with behavioural signals first, score the survivors with quantized bi-encoders on CPU, escalate only disagreement to the full LLM, then distill its verdicts into a servable model. Two cheap judges can also be confidently wrong together, so the auto-accepted pairs need auditing as much as the escalated ones. Generalised from Andreas Wagner’s account of the architecture at searchHub scale; LinkedIn served condensed content to the fetcher, so its figures stay author-reported in Towards Scalable Relevance Engineering.
Articles — Towards Scalable Relevance Engineering Concepts — Staged Judging (cascade architecture for relevance judging) Updated — Andreas Wagner · searchHub · LLM as Judge (economics section) · Implicit Judgments (pruning use) · Knowledge Distillation (distilling a judge) · Hard Negative Mining
2026-08-04 — Vector Podcast and Dima Kan bio (1 new, 3 updated)
Vector Podcast has been interviewing the people building vector search since 2021, and its 38 episodes are now a standing note with the guest and date list taken from the show’s RSS feed rather than from any summary of it. Dima Kan hosts and founded it; his bio picks that up along with his 2021 vector database survey, whose 120K+ reads stay attributed to him rather than stated as fact. Search Communities gained a Podcasts section, and Wormhole Vectors the November 2025 Grainger episode. Prompted by a pull request Kan opened on the awesome-search repo asking for founder and host credit.
Videos — Vector Podcast (interview series on vector search, since 2021) Updated — Dima Kan · Search Communities (new Podcasts section) · Wormhole Vectors (Nov 2025 Grainger episode)