A query does no I/O. `runSearch` takes the store that is already resident, picks the index built once per store-and-locale pair, lowercases the query and splits it on whitespace [9]. `scorePost` then returns zero the instant a term is missing from the post's haystack, which is title, description, body and tags concatenated and lowercased once per post [10][11]. Every term is required, so a second word narrows the result set instead of widening it [11].
Scoring is boolean per field. `includes` answers yes or no and each field contributes a fixed weight, so a post that mentions your term once ranks identically to one that mentions it fifty times [4]. The ceiling for a single term is 17, the sum of the four weights [2]. Work an example: two query words present in both the title and the body score (8+2) x 2 = 20, while a post carrying both words only in the body scores 4 [3]. That five-to-one gap is the entire relevance model, and the author is upfront that the weights are not tuned, only ordered so a title hit outranks a body hit [12].
The WeakMap key is the part worth copying. Because the memo is keyed on the store object itself, the index cannot outlive the data it describes, and nobody has to remember a `resetSearchIndex()` call or pick a TTL [14]. Note the scope. That invariant holds inside one instance; coherence across instances still rests on the content webhook reaching each of them and on the adapter refetching [7][14]. The same pass feeds `computeFacets()`, which counts tags over the identical array, so results and facet counts cannot disagree about what exists [13].
What replaced the hosted index is a cold-start fetch: about 8 MB on the first request to each new instance, after which searches and tag-cloud renders are effectively free [7][15]. That payload is four times the 2 MB ceiling Next.js puts on its data cache, so the framework declines it and logs the fact [8][1]. The author's answer is that a second cache layer was never wanted, since the in-memory store is the cache [8], and this is the rare size limit that saves you from configuring something you did not need. What actually drives the cost is scheduling: the fetch recurs with instance churn, not with publish frequency [6]. A site that ships a few times a week and keeps instances warm amortises it to nothing [15]. A platform that recycles containers every few minutes pays it repeatedly, and pays in tail latency rather than on an invoice [6].
The arithmetic only carries over to another site if a few conditions hold. The adapter must already be loading the whole corpus, or you are adding a fetch rather than deleting a service [6]. Size has room: at roughly 37 KB per post, 2,000 posts is about 73 MB, so the cold fetch breaks before RAM does [5]. And queries have to land as exact substrings of stored text, because the matcher only finds exact substrings, with none of the stemming, synonym handling, typo tolerance or relevance tuning a hosted engine would add at scale [16]. On a corpus where people type framework names, that holds [17]. On a catalogue where they misspell brand names it does not, and the author says a hosted engine earns every cent at millions of documents or with fuzzy ranking [16].
