Комментарии 5
Честно говоря никогда не понимал нецелевое использование инструментов. Это как писать frontend код на assembler.
Есть же специализированные системы для полнотекстового поиска - Elastic Search например.
Есть специализированные системы, но если часть данных уже хранится в PostgreSQL, то потребуется дополнительно делать интеграцию с Elasticsearch. К тому же Elasticsearch сам по себе потребует много доп. вычислительных ресурсов. Ну и транзакционную целостность проще обеспечить, храня всё в PostgreSQL, если она требуется.
Все верно потребуется интеграция для помещения данных в Elastic для формирования поискового индекса, при этом доменные данные по прежнему лучше хранить в транзакционной СУБД. Затраты конечно будут, но самое главное не будет сложного, кастомного решения по поиску данных, а это перевесит все указанные вами недостатки.
Manticore/ElasticSearch/Meilisearch - ткнуть пальцем любое специализированное решение и это будет работать лучше и быстрее из коробки чем эти костыли для PostgreSQL.
Нет, я конечно всё понимаю, сидишь такой и от нечего делать появляется желание переписать весь проект на Go, и базу свою сделать, не осуждаю.
А зачем вы храните структурированные данные в реляционной СУБД в JSONB?
Как мы организовали полнотекстовый поиск: обзор вариантов