Все зависит от планируемых размеров (пределы) базы данных, т.е. количества данных, которые необходимо индексировать. Если нужно считанные десятки тысяч сайтов отслеживать, хватит абсолютно любой sql базы данных, миллионы страниц и fulltext индексы хоть postgres хоть mysql хоть самописные на файлах (пока индексы влезают в оперативную память).
Проблемы начинаются когда индексы не влезают в оперативную память, когда база данных расползается по кластеру или когда скоростей интернет провайдера уже не хватает для прохода обновления базы поисковой системы и данные в поиске становятся неактуальными. Начиная с какого то (большого) объема данных, простого поиска по ключевым словам уже будет недостаточно. А чего стоят алгоритмы ранжирования (сортировки результата), ведь на любой запрос у тебя будет больше чем десяток страниц результатов. Потом борьба с сеошниками, фейковыми зонами интернета (когда сайты генерируют терабайты мусорных данных, и узнаешь ты про них когда место на диске кончится или процент их содержания в индексе превысит половину), интеллектуальная интерпретация данных (с этого в принципе нужно начинать, когда страница должна восприниматься не как просто текстовый документ, а набор информационных зон, их важность (реклама, навигация или статья), разделение (несколько статей на странице), проблема динамического интернета (благодаря 15-летним инструкциям люди до сих пор делают сайты в виде ленты с постраничной навигацией с конца, когда 10-ая страница уже завтра будет показывать не те статьи что были вчера) и вообще javascript в частности и тьма тьмущая других проблем.
Конечно, можно шикануть и использовать последние веяния ИИ, когда по информационным блокам на странице, генерируются вектора, определяющие сам смысл содержания, такие, что можно искать по ним, вычисляя расстояние между ними и запросом пользователя, только когда осознаешь стоимость бота, который будет стороить такой индекс по страницам и проблемы монетизации результата, сразу передумаешь.
Простой
