Meilisearch или Typesense: что выгоднее и когда

MAATRIX

Когда встроенный поиск по БД (LIKE '%...%' или полнотекстовый индекс PostgreSQL) перестаёт справляться, выбор обычно сводится к двум движкам — Meilisearch и Typesense. Оба обещают "поиск как в Algolia, но у себя на сервере", оба легко ставятся одним бинарником или контейнером, у обоих щедрая бесплатная лицензия. Разница вылезает не в документации, а через пару месяцев эксплуатации — в потреблении памяти, поведении при росте индекса и мелочах API, которые определяют, сколько времени вы потратите на подгонку под свой кейс. Разберём по существу: что у кого внутри, сколько это стоит в ресурсах сервера и как выбрать без религиозных споров.

Что у них общего и в чём принципиальная разница

Оба — поисковые движки "из коробки" для полнотекстового и фасетного поиска, оба пишутся на Rust, оба ориентированы на разработчиков, которым не хочется поднимать Elasticsearch ради поиска по каталогу из 50 тысяч товаров. У обоих:

• REST API поверх HTTP, JSON на входе и выходе;
• опечаточная толерантность (typo tolerance) из коробки, без ручной настройки анализаторов;
• фасетный поиск и фильтрация по атрибутам;
• официальные SDK для основных языков (JS, Python, PHP, Go, Ruby);
• self-hosted бесплатно, с MIT/Apache-подобными лицензиями на ядро.

Разница начинается в архитектуре хранения. Meilisearch использует LMDB (memory-mapped B-tree) — индекс живёт на диске, а операционная система сама решает, что закешировать в RAM через mmap. Typesense держит индекс полностью в оперативной памяти (собственная структура на базе HNSW для векторного поиска плюс инвертированные индексы для текста), сбрасывая снапшоты на диск только для восстановления после рестарта.

Практическое следствие: Meilisearch на сервере с ограниченной RAM деградирует мягче — операционная система просто чаще ходит на диск, скорость падает, но сервис не падает по OOM. Typesense в тех же условиях либо не запустится с недостаточным --memory, либо будет убит OOM-killer'ом, если недооценить объём индекса. Зато пока памяти хватает, Typesense стабильно быстрее на чтении, потому что данные физически в RAM, а не за системным кешем.

Потребление ресурсов: что реально едят индексы

Ориентировочные цифры (не бенчмарк, а порядок величины по опыту эксплуатации — на вашем датасете могут отличаться в разы в зависимости от длины полей, числа фасетов и языка):

Если у вас каталог на 200–300 тысяч товаров с короткими текстовыми полями (название, бренд, категория) — оба движка ужмутся в 1–2 ГБ RAM без проблем, разница не критична. Если счёт идёт на миллионы документов с длинными текстовыми полями (описания, статьи, логи) — считайте RAM для Typesense заранее и с запасом, иначе получите падения при пиковой индексации. Подробный разбор расчёта памяти под Typesense есть в отдельной статье — сколько RAM нужно для Typesense.

Скорость индексации и обновления данных

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

Meilisearch индексирует пакетно (batch), и большая часть документации и практики построена вокруг того, что вы шлёте документы через /indexes/{index}/documents и ждёте завершения задачи (task) через отдельный эндпоинт статуса. Обновление одного документа технически возможно, но при высокочастотных точечных апдейтах (например, обновление счётчика "в наличии" у товара каждые несколько секунд) движок начинает пересчитывать часть внутренних структур чаще, чем хотелось бы, и это заметно на CPU.

Typesense изначально проектировался с прицелом на частичные обновления (PATCH-запросы к документу по одному полю) — это удобнее для сценария "цена и остаток меняются каждую минуту, а описание — раз в месяц". Массовая индексация через import тоже быстрая, но именно точечные апдейты у Typesense обычно ощущаются легче.

Если ваш кейс — каталог интернет-магазина, где остатки и цены обновляются постоянно, а полнотекстовые поля стабильны, это весомый довод в пользу Typesense. Если индексация происходит батчами (ночной синк из ERP, пересборка индекса статей блога раз в час) — разница не так важна, и решает всё остальное.

Опечатки, синонимы и релевантность из коробки

Оба движка типо-толерантны по умолчанию, и оба хвастаются, что не нужно настраивать анализаторы как в Elasticsearch. На практике:

• Meilisearch выстраивает ранжирование через настраиваемые правила (rankingRules) — можно явно задать порядок критериев: точность совпадения, близость слов, количество опечаток, кастомные атрибуты (например, "сначала товары в наличии"). Это прозрачно и легко объяснить не-технической команде.
• Typesense использует похожую модель весов через sort_by и текстовую релевантность (text_match), но тонкая настройка ранжирования местами требует больше проб и чтения исходников, чем документации.

Синонимы, стоп-слова, кастомные словари — есть у обоих, конфигурируются через API, разницы в возможностях почти нет, разница только в удобстве конфигов (у Meilisearch чуть более человекочитаемый JSON-конфиг настроек индекса).

Векторный и гибридный поиск

Если в планах — не только полнотекстовый поиск, но и семантический (поиск по эмбеддингам, RAG-сценарии), учтите:

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

Если гибридный поиск — не про вас (обычный каталог, обычный сайт), эта секция не должна влиять на выбор. Если вы строите поиск по базе знаний с LLM поверх — присмотритесь внимательнее к Typesense именно из-за зрелости этой части.

Развёртывание и эксплуатация на своём сервере

Оба ставятся одинаково просто — либо системным пакетом/бинарником, либо в Docker (готовые файлы docker-compose.yml под оба движка есть в блоге, если предпочитаете контейнеры). У нас есть пошаговые инструкции для установки с нуля на Ubuntu 24.04: Meilisearch на Ubuntu 24.04 и Typesense на Ubuntu 24.04.

Из практических отличий в эксплуатации:

• Meilisearch запускается одной командой без обязательных флагов, RAM-лимит явно указывать не нужно — движок использует столько, сколько ОС ему выделит через файловый кеш. Это удобно на старте, но усложняет прогноз потребления при росте.
• Typesense требует явно понимать объём данных, потому что весь рабочий набор должен помещаться в RAM — с одной стороны это дисциплинирует (вы заранее знаете лимиты), с другой — сложнее "просто запустить и забыть" на маленьком VPS с 1–2 ГБ RAM.
• Резервное копирование: у Meilisearch есть встроенные снапшоты (--dump) и экспорт индекса, у Typesense — снапшоты через API. Логика похожая, детали команд отличаются, но в обоих случаях снапшот — это просто файл, который стоит регулярно копировать за пределы сервера.
• Мониторинг: у обоих есть эндпоинты /health и метрики (Meilisearch — экспериментальные Prometheus-метрики, Typesense — через /metrics.json), оба легко подключаются к готовому стеку Prometheus + Grafana, если он уже поднят на сервере.

Что касается ресурсов сервера под сам движок: для каталога до 500 тысяч документов с умеренной нагрузкой достаточно 2 vCPU и 4 ГБ RAM — этого хватает и Meilisearch, и Typesense с запасом. Для больших индексов (миллионы документов, векторный поиск) закладывайте от 8 ГБ RAM и NVMe-диск — на HDD или медленном SSD индексация растягивается кратно, особенно у Meilisearch из-за постоянных операций с LMDB на диске.

Когда выбирать что: практические сценарии

Берите Meilisearch, если:

• каталог небольшой или средний (до нескольких сотен тысяч документов), сервер с ограниченной RAM (1–4 ГБ), и вы не хотите думать про memory limits;
• индексация батчами (ночной синк, редкие обновления), а не постоянные точечные апдейты;
• важна простота конфигурации ранжирования для нетехнической команды;
• бюджет сервера ограничен, и мягкая деградация при нехватке RAM важнее пиковой скорости.

Берите Typesense, если:

• нужны частые точечные обновления полей (цена, остаток, статус) без пересчёта всего документа;
• строите гибридный/семантический поиск с эмбеддингами уже сейчас, а не "может быть потом";
• у вас есть возможность честно посчитать RAM под весь индекс и заложить сервер с запасом;
• важна стабильно предсказуемая скорость чтения без зависимости от файлового кеша ОС.

Ни то, ни другое, если:

• у вас уже есть Elasticsearch/OpenSearch в стеке для других задач (логи, аналитика) — тогда логичнее развернуть поиск там же, чтобы не плодить движки. Сравнение с ClickHouse для аналитических сценариев — в статье ClickHouse или PostgreSQL для аналитики;
• поиск нужен по 2–3 полям в таблице на 10 тысяч строк — здесь хватит индекса PostgreSQL (GIN + pg_trgm), отдельный сервис — избыточная сложность.

Частые вопросы