It's interesting that folks go down this hacky route when they can use something like Vespa, which is orders of magnitude better from a performance, relevance, scalability, and developer ergonomics perspective.
It makes much more operational sense to use pg_vector if your use case can be implemented tha way.
You're going to spend a bunch of time writing integrations that already exist for actual search engines, and you're going to be stuck and need to back out when search becomes a necessity rather than an afterthought.
If you have two systems, then you have two (unique) answers for HA,DR,Shard,Replica,Backup - the PG set and the Vespa.
That's more complicated, from an operational perspective.
PG FTS is quite good, and there are in-pg methods that can improve it.
And, from experience, when it's item to upscale to Solr/ES/etc it's not a very heavy lift.
From my vantage point, you’re both right in the appropriate context.
Sorry I’m on spotty mobile that can’t open anything besides HN lol (God bless this website).
Sometimes it is just easier to use the existing systems and squeeze them as much as possible. Especially when it’s a small team or solo without much $$
https://vespa.ai is a purpose built search engine.
If you start bolting search onto your database, your relevance will be terrible, you'll be rewriting a lot of table stakes tools/features from scratch, and your technical debt will skyrocket.