Как выбрать векторную базу: сравнение по честным критериям

MAATRIX

Как только проект доходит до RAG или поиска по эмбеддингам, встаёт вопрос: какую векторную базу ставить. В интернете на этот запрос отвечают рейтингами «топ-10 векторных баз 2026» с таблицами, где у всех решений галочки почти везде и непонятно, чем они реально отличаются для вашей задачи. Дальше — конкретные критерии выбора, которые действительно на что-то влияют, без выдуманных цифр производительности и без попытки назвать единственного победителя.

Два пути: расширить свою СУБД или взять специализированную

По сути у вас всего два направления, а не десяток равнозначных вариантов.

Первый — расширение уже существующей реляционной СУБД. Самый частый случай — pgvector поверх PostgreSQL: вы добавляете тип данных vector и индексы для поиска по нему в базу, которая и так у вас работает. Если у вас уже есть PostgreSQL с данными, миграциями, бэкапами и мониторингом — вы просто расширяете периметр того, что уже эксплуатируете. Мы разбирали это решение подробно в статье pgvector: векторный поиск поверх PostgreSQL — там же приведены реальные команды установки и создания индексов.

Второй путь — специализированная векторная СУБД (Qdrant, Milvus, Weaviate, и другие), спроектированная именно под векторный поиск: свои алгоритмы индексации, свои механизмы шардирования и репликации под большие объёмы, собственный протокол запросов. Это отдельная система хранения — со своим процессом установки, обновлениями, мониторингом, бэкапами, отдельная точка отказа в инфраструктуре.

Оба пути рабочие. Разница не в том, что один «лучше», а в том, при каких условиях компромиссы одного перевешивают компромиссы другого. Дальше — честные критерии, по которым это стоит решать, а не абстрактный рейтинг.

Критерий №1 — реальный объём и рост данных

Первый вопрос, который стоит задать себе до всего остального: сколько у вас реально векторов сейчас и сколько будет через год.

Если это несколько сотен тысяч или пара миллионов записей — типичный случай для RAG по базе документов компании, базе знаний, каталогу товаров среднего интернет-магазина — разница в производительности между pgvector с приличным индексом и специализированной базой на практике для большинства сценариев не критична. Задержка поиска в обоих случаях укладывается в приемлемые для пользовательского интерфейса рамки, если индекс настроен разумно.

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

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

Критерий №2 — инфраструктура, которая уже есть

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

Если у вас уже есть эксплуатируемый PostgreSQL — с настроенными бэкапами, репликацией, мониторингом, ролями доступа, процедурами восстановления — добавление pgvector означает, что весь этот периметр эксплуатации бесплатно распространяется и на векторные данные. Не нужно поднимать отдельный кластер, разбираться с его especific операционными нюансами, учить команду ещё одной системе, тратить отдельный бюджет на её поддержку.

Специализированная векторная СУБД — это по факту ещё один сервис в инфраструктуре: собственный процесс развёртывания, собственные требования к ресурсам, собственные обновления версий (иногда с breaking changes в формате индекса), собственная стратегия резервного копирования, отдельный мониторинг метрик именно этого сервиса. Если у вас небольшая команда и один инженер отвечает за инфраструктуру целиком — это реальная дополнительная нагрузка на человека, а не абстрактная строчка в архитектурной диаграмме.

Именно поэтому упрощение архитектуры за счёт переиспользования базы, которая уже есть и уже понятна команде, на практике часто перевешивает теоретический выигрыш в производительности специализированного решения — особенно пока вы не столкнулись с конкретным ограничением на своём масштабе (о котором ниже). Если у вас пока нет ни PostgreSQL, ни другой реляционной СУБД в проекте и вы поднимаете стек с нуля именно под RAG — общий процесс поднятия хранилища под векторный поиск описан в статье как поднять векторную базу для RAG на сервере.

Критерий №3 — индексация и гибридные запросы

Третий критерий требует не абстрактного «какая база быстрее», а конкретного вопроса: какие у вас будут запросы на практике.

Почти никогда в реальном RAG-сценарии запрос не сводится к чистому «найди 10 ближайших соседей по вектору». Обычно нужен гибридный запрос: найти ближайшие по смыслу документы, но только среди тех, что принадлежат конкретному клиенту, относятся к нужной категории, не старше определённой даты, или прошли модерацию. Это фильтрация по метаданным одновременно с векторным поиском.

Здесь решения расходятся по зрелости заметно сильнее, чем в чистом ANN-поиске:

• pgvector поверх PostgreSQL — фильтрация по метаданным здесь бесплатна и естественна: это обычный WHERE по обычным колонкам вашей таблицы, соединённый в одном SQL-запросе с оператором расстояния по вектору. Планировщик PostgreSQL умеет комбинировать обычный индекс на колонке метаданных с векторным индексом, хотя для больших таблиц порядок фильтрации имеет значение и его стоит проверять через EXPLAIN ANALYZE.
• специализированные векторные СУБД — большинство современных решений тоже поддерживают фильтры по payload/метаданным, но реализовано это у разных систем по-разному: где-то фильтр применяется до векторного поиска (что может резко сузить кандидатов и снизить полноту при высокоселективных фильтрах), где-то после. Это нужно проверять в документации конкретной версии и тестировать на своих фильтрах — не все системы одинаково хорошо держат сложные комбинированные условия при высокой selectivity.

Также стоит сверить, какие алгоритмы индексации вообще доступны и подходят под ваш профиль нагрузки: HNSW обычно даёт лучший баланс скорости и точности поиска для запросов в реальном времени, IVF-подобные индексы (например IVFFlat) дешевле по памяти при построении, но требуют более аккуратной настройки количества кластеров под объём данных. Не все версии инструментов поддерживают все алгоритмы — это стоит сверить с актуальной документацией на момент выбора, а не полагаться на то, что читали полгода назад.

Критерий №4 — зрелость экосистемы клиентов

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

Если вы пишете на Python и используете LangChain, LlamaIndex или похожий фреймворк для сборки RAG-пайплайна — почти все распространённые векторные базы, включая pgvector, имеют готовые интеграции. Но глубина этой интеграции разная: где-то это полноценный, активно поддерживаемый коннектор с примерами и тестами, где-то — минимальная обёртка, которую вслепую подключили однажды и с тех пор не трогали.

Стоит проверить конкретно для вашего языка и фреймворка:

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

pgvector здесь выигрывает не за счёт особой магии, а за счёт того, что клиентские библиотеки к PostgreSQL — одни из самых зрелых в индустрии в принципе, и работа с векторным типом данных ложится поверх уже привычного вам ORM или драйвера без изучения нового протокола. Если у вас в проекте уже считаются эмбеддинги — есть смысл сверить выбор модели эмбеддингов с тем, что реально нужно вашей задаче, это разбирали в статье embeddings-модели: какую выбрать для RAG.

Как тестировать кандидатов вместо того чтобы верить чужим бенчмаркам

Здесь стоит сказать прямо: любые опубликованные цифры «база А в N раз быстрее базы Б» почти всегда получены на чужих данных, чужом железе, чужой конфигурации индекса и чужом профиле запросов. Переносить их на свой случай — ошибка, даже если цифры честные у автора теста. Ваша производительность зависит от размерности векторов, распределения данных, паттерна фильтров, объёма оперативной памяти под индекс и десятка других деталей, которые в чужом бенчмарке просто другие.

Правильная методика — не искать «самый быстрый» бенчмарк в интернете, а собрать свой:

1. Возьмите репрезентативную выборку ваших реальных векторов — не тестовый датасет из документации, а эмбеддинги, посчитанные на ваших реальных данных той же моделью, которую вы будете использовать в проде. Размер выборки — либо весь текущий объём, либо честная экстраполяция на ожидаемый через полгода-год.
2. Соберите реальные запросы, а не синтетические. Если у вас уже есть прод или пилот — возьмите лог реальных пользовательских запросов. Если проекта ещё нет — накидайте запросы, максимально похожие на то, что реально будут спрашивать, включая фильтры по метаданным, которые вы ожидаете использовать.
3. Разверните кандидатов на сопоставимом железе — том самом, на котором собираетесь работать в проде, а не на своём ноутбуке для одного варианта и на арендованном сервере для другого.
4. Прогоните одинаковый набор запросов на каждом кандидате и замерьте то, что реально важно для вашего продукта: задержку на нужном перцентиле (обычно p95 или p99, а не среднюю — среднее скрывает хвостовые задержки, которые бьют по UX), полноту и точность результатов при вашем реальном пороге похожести, поведение под конкурентной нагрузкой, потребление памяти при вашем объёме данных.
5. Зафиксируйте результаты в таблице и сравнивайте не абстрактные баллы, а конкретные числа для вашего сценария — они могут кардинально отличаться от любого опубликованного бенчмарка, и это нормально.

Такой тест занимает день-два, но экономит месяцы на исправление архитектурной ошибки постфактум.

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