PostgreSQL, Elasticsearch или Meilisearch: что выбрать

Поиск по каталогу на 100 000 товаров можно запустить внутри PostgreSQL, но тот же подход начнёт мешать, когда понадобятся опечатки, подсказки, фасеты и независимое масштабирование. Elasticsearch решает больше задач, но добавляет отдельный кластер и операционные расходы. Meilisearch проще поднять, однако его возможности уже. Ниже — практический выбор для проекта, ориентированный на PostgreSQL 16, Elasticsearch 8.x и Meilisearch 1.x.

Сначала определите, что именно должен делать поиск

Слово «поиск» скрывает несколько разных сценариев. Запрос по точному артикулу и полнотекстовый поиск по описанию — не одна и та же задача. До выбора движка зафиксируйте требования:

• нужны ли подсказки во время ввода;
• допустимы ли опечатки и насколько агрессивно их нужно исправлять;
• должны ли работать фильтры, сортировка и фасеты по цене, бренду и категории;
• нужно ли искать на нескольких языках с разными правилами словоформ;
• какая задержка допустима для поиска и сколько запросов приходится на секунду;
• кто будет обновлять индекс после изменения товара и как быстро это должно происходить.

Если ответов пока нет, не начинайте с установки кластера. Снимите реальные поисковые запросы, включая пустые результаты, опечатки и длинные фразы. Именно этот набор покажет, нужна ли вам отдельная поисковая система.

Три подхода и их цена

PostgreSQL: поиск рядом с данными

PostgreSQL 16 подходит, когда данные уже лежат в базе, каталог умеренного размера, а поиск можно описать полнотекстовым запросом, фильтрами и сортировкой. Встроенный полнотекстовый поиск умеет разбирать документы на лексемы, учитывать словари и ранжировать результаты. Для ускорения используются индексы, в том числе GIN.

Главный плюс — нет второго хранилища и отдельного процесса индексации. Транзакция обновила товар — база сразу видит новое значение. Это уменьшает количество состояний, которые нужно отлаживать.

Цена решения — нагрузка на основную базу. Сложные запросы, сортировка по релевантности и подсказки могут конкурировать с заказами, личными кабинетами и административными операциями. PostgreSQL также не превращается автоматически в удобный поисковик с терпимостью к опечаткам: такую логику придётся проектировать и проверять отдельно.

Elasticsearch: отдельный поисковый кластер

Elasticsearch 8.x выбирают, когда поиск — самостоятельная подсистема. Он рассчитан на инвертированный индекс, анализаторы, сложные фильтры, фасеты, подсказки и распределение данных по узлам. Отдельный кластер можно масштабировать независимо от PostgreSQL и подбирать настройки под поисковую нагрузку.

Это сильный вариант для большого каталога, нескольких языков, сложной релевантности и поиска по разным типам документов. Но вместе с возможностями появляются индексы, маппинги, шарды, реплики, мониторинг, резервное копирование и процесс доставки изменений из основной базы.

Сложность возникает не только при запуске. Нужно решить, что делать с удалённым товаром, повторной доставкой события, временной недоступностью кластера и изменением схемы документа. Если команда не готова владеть этой системой, её возможности могут обернуться более дорогими сбоями.

Meilisearch: быстрый путь к пользовательскому поиску

Meilisearch 1.x ориентирован на быстрый запуск поиска по документам. Он предоставляет поиск с учётом опечаток, префиксный поиск, фильтрацию, сортировку и фасеты через относительно простой интерфейс. Для каталога, документации или внутреннего сервиса это часто даёт хороший результат без длительной настройки аналитиков Elasticsearch.

Плата за простоту — более узкий контроль над поисковым поведением и архитектурой. Перед внедрением проверьте нужные языки, правила ранжирования, размер индекса, импорт данных и сценарий восстановления. Если бизнес ожидает сложную аналитику по поисковым событиям или десятки разных типов документов, Meilisearch может оказаться промежуточным решением.

Выбирайте не самый мощный движок, а минимальную систему, которая выдерживает ваши запросы, требования к релевантности и способ обновления данных.

Сноска. Инвертированный индекс — структура, которая хранит соответствие между словами и документами, где они встречаются. Благодаря ему поисковику не нужно перечитывать весь каталог при каждом запросе.

Сравнение по критериям, которые влияют на проект

Цены облачных тарифов здесь не указаны: они меняются по региону, объёму диска, памяти, резервным копиям и числу запросов. Сравнивайте не только стоимость виртуальной машины, но и время инженера на обновления, восстановление и разбор проблем с индексом.

Когда выбирать каждый вариант

Оставляйте поиск в PostgreSQL, если

• у вас один основной источник данных и нет требования к независимому масштабированию;
• поиск — часть CRUD-приложения, а не главный пользовательский продукт;
• важна транзакционная согласованность и нельзя мириться с задержкой индексации;
• фильтры и сортировка важнее исправления опечаток и сложных подсказок.

Это разумный старт для B2B-сервиса, административной панели, небольшого магазина и внутреннего каталога. Сначала измерьте нагрузку, а не переносите поиск наружу «на вырост».

Берите Elasticsearch, если

• поиск — критичный пользовательский сценарий с отдельными требованиями к задержке;
• нужны разные анализаторы, сложное ранжирование, фасеты и поиск по нескольким типам документов;
• команда уже умеет обслуживать кластер и понимает жизненный цикл индексов;
• данные можно безопасно и повторяемо восстановить из PostgreSQL или другого источника.

Не делайте Elasticsearch единственным местом хранения бизнес-данных без отдельного обоснования. Для большинства приложений это поисковый индекс, который можно пересобрать, а не первичная база.

Выбирайте Meilisearch, если

• нужно быстро запустить удобный поиск по каталогу или документации;
• опечатки, префиксы, фильтры и фасеты важны, но сложная аналитика не нужна;
• команда хочет ограничить операционную сложность отдельного поискового слоя;
• вы заранее проверили поддерживаемые языки, размер данных и сценарий восстановления.

Meilisearch особенно уместен как самостоятельный поисковый сервис с понятной моделью документов. Если требования уже включают сложное распределение, продвинутую аналитику и нестандартное ранжирование, сравните его с Elasticsearch на реальном наборе запросов.

Что обычно ломается

Первая проблема — рассинхронизация. Товар удалили в PostgreSQL, но событие не дошло до Elasticsearch или Meilisearch, и пользователь продолжает видеть недоступный товар. Нужны повторная доставка, периодическая сверка и понятный способ полной пересборки индекса.

Вторая — неподходящая нормализация текста. Разный регистр, дефисы, артикулы, русские словоформы и латиница в брендах дают разные результаты. Нельзя считать индексирование завершённым, пока вы не прогнали реальные запросы покупателей.

Третья — неверное измерение. Средняя задержка скрывает редкие медленные запросы, а количество запросов не показывает стоимость обновления индекса. Смотрите перцентили задержки, долю пустых результатов, клики по выдаче, ошибки синхронизации и нагрузку на основную базу.

Четвёртая — попытка настроить релевантность без эталона. Соберите несколько десятков важных запросов и заранее отметьте, какие товары должны быть первыми. Иначе команда будет спорить о качестве по отдельным примерам.

Как провести проверку до миграции

1. Соберите обезличенную копию каталога и журнал поисковых запросов минимум за один рабочий период.
2. Одинаково загрузите данные в PostgreSQL, Elasticsearch и Meilisearch, не меняя набор полей между тестами.
3. Проверьте точные артикулы, длинные фразы, опечатки, пустые запросы, фильтры и запросы без результата.
4. Измерьте p95 и p99 задержки, потребление памяти, время обновления документа и поведение при недоступности индекса.
5. Посчитайте стоимость не только инфраструктуры, но и сопровождения: алерты, резервные копии, обновления и восстановление.

Сравнивайте одинаковый сценарий: один и тот же объём данных, одинаковое железо, одинаковая параллельность и прогретый либо холодный кеш. Без этого цифры между движками не помогут принять решение.

Что делать дальше

Начните с набора из 30–50 реальных запросов и опишите для каждого ожидаемый результат. Если большинство требований сводится к фильтрам и простому полнотекстовому поиску, протестируйте PostgreSQL 16 первым. Если нужны опечатки и быстрый пользовательский интерфейс, добавьте Meilisearch 1.x. Elasticsearch 8.x оправдывает себя, когда его расширенные возможности уже подтверждены запросами и команда готова обслуживать отдельный кластер.

После выбора настройте мониторинг пустых результатов, задержки p95 и очереди индексации. Именно эти показатели раньше всего покажут, что поисковый слой перестал соответствовать каталогу.