I had a draft sitting around somewhere, that I started doing just that and adding a paragraph or so for each. I got about 12 done before I moved on to something else.

For those two specific Qs you asked:

Search isn’t like a database because it isn’t ACID and shouldn’t be the point of record for data - even though lots of teams eschew this advice and use Elasticsearch or another engine as their record store…IMO content should be stored somewhere safer like a CMS, and added to the search engine for the search/discovery/recommendation use case.

Search can be plugged in to a product rather quickly, but the initial relevance is usually terrible - and it’s a beast that needs to be tamed and loved for awhile before it can make users happy.

The relations between data are different, and that relation can be defined in very different ways, with exceptions and so on. Could be weighted relations, and tweaking those relations could kill the search quality (ie. Google's ads pollution). There is not writen-on-rock way to do it right. BD's relations are much simpler and well defined.

On products, the article says it won't be easy, perform well, or give users a good impression every time. Again search quality issues.

》I would love a companion to these pieces that go into details.

They want you to give them a call, they do consultancy and the reason it's not complete.

I'm developing a next-generation search engine and the article is actually pretty light on topics, it's like search engine research got frozen around 2010. Google can't take user feedback for the recommendation without getting SEO-gamed way further, so we need a new kind of search to make it irrelevant.