Meilisearch vs Typesense vs Postgres для поиска в приложении

Почему этот выбор становится сложным

У сотрудника поддержки, который ищет по номеру счёта, совсем другая задача, чем у клиента, который набирает «nik shoez» в поисковой строке. Сотруднику нужны точные записи, стабильные фильтры и результаты, которые подчиняются правилам доступа. Клиенту важны скорость, терпимость к опечаткам и ранжирование, которое остаётся понятным, даже когда запрос написан неаккуратно.

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

Простой старт тоже может обернуться дополнительной работой позже. Если начать с full text в Postgres, потому что данные уже там, базовый поиск можно запустить быстро. Потом продукт растёт. Люди просят синонимы, фасетные фильтры, обработку опечаток или кастомное ранжирование, и простая схема начинает обрастать дополнительными запросами, вспомогательными таблицами и джобами на переиндексацию.

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

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

Вот почему спор Meilisearch vs Typesense vs Postgres — это редко чистый тест скорости. Более важный вопрос — сколько логики поиска ваша команда готова взять на себя. Если данные простые, можно дольше оставаться на простом решении. Если поиск должен устраивать и сотрудников, и клиентов, неправильный ранний выбор часто заканчивается переписыванием, которого никто не хотел.

Что даёт каждый вариант

Когда люди сравнивают Meilisearch vs Typesense vs Postgres, они обычно выбирают между разными компромиссами, а не между тремя версиями одной и той же вещи.

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

Ограничения появляются, когда пользователям нужно больше, чем базовая релевантность. Терпимость к опечаткам, автодополнение, веса полей и мягкое совпадение в Postgres требуют больше работы. Хороший опыт создать можно, но обычно большую его часть вы делаете сами.

Meilisearch часто кажется очень быстрым в запуске. Можно быстро индексировать JSON-документы, подстраивать правила ранжирования без лишних сложностей и вывести клиентский поиск в продакшен раньше. Это хорошо подходит для каталогов, справочников и баз знаний, где люди вводят непоследовательные запросы. Цена простая: вы запускаете отдельный поисковый сервис и следите за ещё одним индексом.

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

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

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

Где растут затраты на индексирование

Работа с индексом обычно начинается с малого, а потом растёт, когда поиск перестаёт совпадать с формой базы данных. Postgres может обращаться к сырым таблицам напрямую, поэтому стартовая настройка часто проще. Meilisearch и Typesense обычно подталкивают к поисковому документу, то есть к одному плоскому объекту, который объединяет title, category, tags, status и другие поля, которые пользователи ищут вместе.

Именно на этой дополнительной схеме и начинается скрытая работа. Клиентской странице поиска могут понадобиться взвешенные заголовки, фасетные фильтры и синонимы вроде «TV» и «television». Внутреннему административному поиску всё это может быть не нужно. Если обе аудитории используют одни и те же исходные данные, может понадобиться два разных вида индекса вместо одного.

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

Перед тем как решиться, ответьте на несколько скучных вопросов. Могут ли сырые таблицы поддерживать поиск ещё шесть месяцев? Какие поля действительно заслуживают большего веса? Какие фильтры должны быть точными, а не приблизительными? Нужны ли синонимы прямо сейчас или вы просто предполагаете? Сколько записей затронет полная пересборка?

Время reindex меняет риск сильнее, чем многие ожидают. Перестроить 50 000 записей — небольшая задача. Перестроить 50 миллионов — это уже расписание, отслеживание прогресса, повторы и план отката на случай ошибки. Postgres частично избегает этого, потому что данные и так там лежат, но тогда на первое место выходят настройка запросов и индексов.

Именно здесь поисковые проекты становятся тяжелее. Первая версия кажется простой. Вторая добавляет правила ранжирования, фильтры, скрипты исправления и задания на переиндексацию. Команды, которые заранее продумывают такие сценарии, обычно избегают большого переписывания позже.

Как терпимость к опечаткам меняет результаты

Клиентскому поиску обычно нужна более снисходительная строка поиска. Люди пропускают буквы, меняют их местами или вводят только половину фразы. Если кто-то ищет «iphnoe case» и ничего не получает, он не винит себя. Он винит продукт.

Именно поэтому Meilisearch и Typesense часто кажутся лучше для клиентского поиска. Они могут прощать небольшие ошибки и всё равно возвращать полезные результаты почти без настройки. Для магазинов, справочных центров и библиотек контента это важнее, чем идеальная точность.

Внутренний поиск часто работает наоборот. Сотрудник поддержки может искать код заказа, ID клиента или точное название компании. В таком случае fuzzy-совпадение добавляет лишний шум. Нужная запись оказывается ниже пачки почти подходящих результатов, и это быстро раздражает.

Больше всего проблем создают короткие запросы. Поиски вроде «AB», «HR» или «JS» при слишком мягких правилах опечаток могут находить слишком много всего. Смешанные запросы тоже путают ранжирование. Например, запрос «Acme 447 red» может требовать, чтобы бренд и код товара были важнее текстового сходства.

Если есть фильтры, большинству команд стоит поднимать точные совпадения фильтров выше, чем fuzzy-текст. Когда человек выбирает бренд «Acme» и вводит «447», товар Acme с кодом 447 должен обойти другой товар с чуть лучшей текстовой оценкой. Поиск кажется умным, когда он уважает очевидное намерение.

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

Прежде чем что-то выбирать, прогоните реальные запросы: короткие вроде «hr» или «js», частые опечатки вроде «adress» или «iphnoe», смешанные запросы вроде «acme 447 red» и точные идентификаторы, такие как email, SKU и ID тикетов. Одна ошибка здесь повторяется снова и снова: команды используют одни и те же настройки опечаток и для клиентов, и для сотрудников. Это кажется аккуратным, но обычно делает одну из групп недовольной. Разные правила часто лучше.

Какая ops-работа ложится на команду

Поиск становится дорогим, когда добавляет в жизнь ещё одну систему, которую нужно постоянно присматривать. В этом и есть самое заметное различие: Postgres держит поиск внутри инструмента, который вы уже обслуживаете, а Meilisearch и Typesense добавляют ещё один сервис со своим хранилищем, обновлениями, алертами и сценариями отказа.

Первое, что это показывает, — резервные копии. С full text в Postgres данные поиска живут вместе с основной базой, так что обычно хватает одного плана бэкапа. С Meilisearch или Typesense нужно решить, является ли индекс одноразовым или частью восстановления. Если его можно пересобрать из Postgres, восстановление выглядит проще на бумаге, но время на пересборку всё равно может оставить пользователей с слабым или устаревшим поиском на часы.

Память и диск нужно регулярно проверять во всех трёх вариантах, но нагрузка ложится в разные места. Отдельные поисковые движки часто хотят больше RAM по мере роста индекса, а расход диска может резко расти во время импорта или перестроения. Postgres меньше скрывает эту нагрузку. Медленные запросы поиска, раздутые индексы и обслуживание могут затронуть основную базу и обычный трафик.

Обновления и переиндексация

Отдельный поисковый движок — это ещё один календарь обновлений. Нужен проверенный путь отката, а не просто повышение версии. Обычно это означает снимок состояния, проверку на staging с реальными запросами и план возврата трафика назад, если ранжирование изменится или индексирование сломается.

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

Auth и сетевой доступ проще держать в порядке для внутренних инструментов. Если сотрудники ищут административные данные, а приложение и так ходит в Postgres по закрытой сети, поиск там может уменьшить число движущихся частей. Отдельный движок добавляет API-ключи, правила firewall и ещё один сервис, который нужно безопасно открывать наружу.

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

Как выбирать шаг за шагом

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

Возьмите топовые запросы из логов. Если логов ещё нет, спросите поддержку, продажи и ops, что они ищут каждый день. Потом спросите нескольких клиентов, что они пытались найти и не нашли.

Хорошо работает простой процесс:

1. Запишите самые важные запросы, включая те, которые ничего не находят.
2. Отметьте запросы, которым нужна терпимость к опечаткам. Клиентскому поиску обычно нужна большая гибкость, чем внутреннему.
3. Посчитайте, как часто исходные данные меняются за час. Небольшой каталог, который обновляется два раза в день, — это просто. Цены, остатки, тикеты или документы, меняющиеся весь день, создают больше работы для индексации.
4. Назовите человека, который будет отвечать за резервные копии, алерты, обновления и сломанные синхронизации.
5. Выберите самое простое решение, которое подходит для сегодняшнего дня и следующего года.

Обычно это быстро сужает выбор. Если люди в основном ищут точные ID, email, теги или известные фразы, full text в Postgres может хватить и сохранить стек компактным. Если клиенты ошибаются в словах, укорачивают названия или ожидают, что поиск просто работает, отдельный движок облегчит жизнь.

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

Простой пример с двумя аудиториями

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

Команда поддержки ищет ID заказов, номера счетов и точные имена клиентов. Они уже примерно знают, что им нужно. Если сотрудник вводит «ORD-18422» или «Maria Chen», поиск должен быстро вернуть правильную запись, без долгих споров о ранжировании.

Клиенты делают другое. Они открывают help center и вводят фразы вроде «cant change billing email» или «refund didnt arrive». Они могут ошибаться в словах, пропускать детали или использовать термины, которых ваша команда никогда не применяла в названиях статей.

Эти аудитории тянут инструмент в разные стороны. Внутренний поиск вознаграждает точность. Поиск по help center вознаграждает терпимость к размытым формулировкам и опечаткам.

Полнотекстовый поиск в Postgres может хорошо работать для стороны поддержки, особенно если данные уже лежат в Postgres. Вы избегаете второго индекса, а точные фильтры по аккаунту, дате или статусу остаются простыми. Для номеров заказов и имён этого часто достаточно.

Для статей помощи клиентам Postgres часто начинает ощущаться слишком жёстким. Улучшить его можно, но работа быстро растёт, когда люди ждут более снисходительного поиска. Meilisearch и Typesense обычно лучше подходят здесь, потому что они с меньшим количеством своей логики обрабатывают опечатки, частичные совпадения и более дружелюбное ранжирование.

Это не значит, что один инструмент должен делать всё. Разделённая схема часто спокойнее. Оставьте поиск внутренних записей рядом с Postgres, где уже живут точные поля и бизнес-правила. Поиск по статьям перенесите в Meilisearch или Typesense, где терпимость к опечаткам помогает реальным пользователям быстрее находить ответы.

Так компромиссы тоже становятся честнее. Сотрудникам не нужен умный поиск, если он прячет нужный заказ за расплывчатыми догадками. Клиентам всё равно, что ваши статьи аккуратно лежат в SQL, если поиск ломается на «adress change». Если две поисковые задачи тянут систему в разные стороны, заставлять один стек закрывать обе может стоить больше времени, чем запуск двух небольших систем.

Ошибки, которые ведут к переписыванию

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

Одна из частых ошибок — запихнуть в поиск вообще все поля только потому, что можно. Название товара, SKU, категория, теги, заметки поддержки, внутренние комментарии и старые метаданные не должны иметь одинаковый вес. Когда в индекс попадает всё подряд, результаты быстро становятся шумными. Люди ищут ясный термин и получают наполовину связанные совпадения только потому, что он случайно встретился в каком-то скрытом поле.

Следующий повод для переписывания — ранжирование. Команды часто оставляют настройки по умолчанию и планируют настроить их позже. «Позже» обычно наступает после того, как продажи, поддержка или сотрудники начинают говорить, что результаты выглядят случайными. К этому моменту люди уже построили экраны, фильтры и привычки вокруг слабого ранжирования. Изменение превращается в небольшую миграцию вместо быстрого исправления.

Фильтры создают ещё больше боли, потому что они затрагивают и данные, и дизайн продукта. Если пользователям нужно сужать выбор по статусу, региону, цене, tenant или правам доступа, это нужно моделировать с первого дня. Многие команды сначала делают красивый текстовый поиск, а потом обнаруживают, что не могут добавить быстрые фасеты или строгие фильтры по правам без перестройки всего индекса.

Массовые обновления ломают поиск чаще, чем люди ожидают. Импорт каталога, ночная синхронизация или крупное перестроение могут выглядеть нормально в разработке и всё равно замедлить прод. Postgres может замедлить другие запросы. Отдельный поисковый движок может отставать, ставить обновления в очередь или часами показывать устаревшие результаты. Если вы никогда не тестировали тяжёлое обновление на реалистичных данных, вы просто гадаете.

Последняя ошибка происходит ещё до написания кода: выбор инструмента до того, как вы посчитали недельное ops-время. Поиск — это не только настройка. Кто-то отвечает за изменения схемы, правки ранжирования, неудачные синхронизации, джобы перестроения, резервные копии, мониторинг и странные жалобы пользователей вроде «я знаю, что этот товар существует, почему я не могу его найти?». Команде с одним занятым инженером стоит внимательно взвесить эту цену.

Несколько предупреждающих признаков видны заранее:

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

Если два часа планирования могут сэкономить шесть месяцев уборки, потратьте эти два часа.

Короткий чеклист перед решением

Команды часто спешат с этим выбором, потому что все три варианта могут выглядеть нормально в демо. Проблемы начинаются позже, когда данные растут, качество поиска падает или один deploy ломает индекс.

Хорошая проверка должна быть специально скучной. Может ли ваша команда ответить на несколько практических вопросов без догадок? Если нет, продолжайте тестировать.

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

Измерьте полную пересборку на реальных данных, а не на выборке из 500 строк. Вам нужен примерный ответ, сколько это занимает, какую нагрузку создаёт и заметят ли это пользователи.

Проверьте поиск на грязном вводе. Попробуйте опечатки, формы множественного числа, короткие названия и точные ID, такие как номера заказов или коды счетов. Клиентскому и внутреннему поиску обычно нужно разное поведение.

Убедитесь, что один человек сможет восстановить поиск после неудачного deploy. Это означает понятные runbook, резервные копии при необходимости и простой способ перестроить индекс или откатиться, не собирая половину команды на звонок.

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

Небольшой пример делает это очевидным. Если клиенты ищут «blu tooth hedphones», а сотрудники — «ORD-10482», вам нужны и fuzzy-совпадения, и точный поиск. Многие команды тестируют только первый случай и забывают про второй — или наоборот.

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

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

Возьмите небольшой, но грязный набор реальных данных и сначала протестируйте на нём все три варианта. Чистый демо-набор скрывает проблемы, которые обычно и решают этот выбор: странные написания, неполные имена, устаревшие записи и поля, которые выглядят простыми, пока люди не начинают их искать.

Если спор Meilisearch vs Typesense vs Postgres всё ещё кажется абстрактным, сделайте его конкретным на одних и тех же записях и одном и том же наборе запросов. Используйте поиски, которые ваша команда уже видит в тикетах поддержки, админских инструментах и логах продукта. Десять честных запросов скажут больше, чем пятьдесят придуманных.

Ваш тестовый прогон должен ответить на четыре вопроса:

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

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

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

Внутренний поиск и клиентский поиск почти никогда не заслуживают одного и того же ответа. Команда поддержки может принять простое ранжирование, если данные остаются свежими и несложными. Продукту для клиентов обычно нужны более качественная обработка опечаток и более предсказуемая релевантность, даже если это добавляет ещё один сервис.

Если этот выбор повлияет на архитектуру продукта, бюджет инфраструктуры или процессы команды, короткий разбор до финального решения может сэкономить недели переделок. Oleg Sotnikov at oleg.is помогает стартапам и небольшим командам разбираться в компромиссах поиска, потоке данных и стоимости ops, когда поиск начинает затрагивать остальную систему.