Векторная база для бизнеса: как сравнить pgvector, Qdrant, Pinecone и Chroma

Отправная точка выбора зависит от того, что у вас уже есть. Если компания работает с PostgreSQL, разумно сначала проверить pgvector. Если требуется отдельный сервис для векторного поиска, следует рассмотреть Qdrant. Если команда хочет управляемого сервиса без собственного сервера, Pinecone. Если нужно быстро начать локально, с возможностью позже перейти на сервер или облако, Chroma.

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

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

Сперва требования

Векторная база сохраняет числовые представления фрагментов текста (эмбединги) и быстро находит самые близкие к запросу. Эта функция есть у всех четырех кандидатов. Разница в том, что вокруг нее.

Размер корпуса. Сколько фрагментов будет в базе сейчас и через год. От этого зависят требования к памяти, индексам и масштабированию. Важен не только текущий объем, но и темп роста.

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

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

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

Резервирование и восстановление. Как делается резервная копия, как с нее восстановиться и сколько времени это займет. Проверять нужно само восстановление, а не только наличие копий.

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

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

pgvector

pgvector представляет собой расширение с открытым кодом, которое добавляет векторный поиск в PostgreSQL. Векторы хранятся рядом с другими данными, и для них работают привычные возможности PostgreSQL, в том числе транзакции и JOIN.

Главное преимущество. Если PostgreSQL уже есть в компании, не требуется отдельный сервис: те же доступы, те же процедуры резервирования, та же команда. Фильтр по отделу или дате документа является обычным условием WHERE в SQL.

Поиск. pgvector поддерживает точный и приближенный поиск ближайших соседей. Без приближенного индекса точный поиск дает эталонный top-k ближайших векторов по выбранной метрике и фильтрам. Это не гарантирует содержательную релевантность: она зависит также от эмбедингов и подготовки документов. Для ускорения есть два типа индексов:

• HNSW строит многоуровневый граф. Дает лучший баланс скорости и полноты поиска, но строится медленнее и использует больше памяти. Его можно сделать на пустой таблице.
• IVFFlat делит векторы на списки. Обычно строится быстрее и использует меньше памяти, но имеет другой компромисс скорости и полноты. Сравните индексы при одинаковой целевой полноте и ресурсах. Его создают после того, как в таблице уже есть данные и тщательно подбирают параметры для хорошей полноты.

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

Влияние на действующую базу. Построение индекса HNSW значительно быстрее, когда граф помещается в maintenance_work_mem, но документация предостерегает не ставить это значение так высоко, чтобы исчерпать память сервера. Если векторный поиск размещается на том же сервере, что и учетная система, проверьте, как построение индексов и поисковые запросы влияют на основную нагрузку. Иногда правильное решение: та же технология, но отдельный экземпляр PostgreSQL.

Резервирование. pgvector использует журнал предварительной записи (WAL) PostgreSQL, поэтому поддерживает репликацию и восстановление на момент времени. То есть работают существующие процедуры компании.

Ограничение размерности. Для типа vector можно индексировать векторы до 2 000 измерений. Для большей размерности документация предлагает другие типы, например halfvec с половиной точностью, до 4000 измерений. Проверьте размерность эмбедингов вашей модели к выбору.

Qdrant

Qdrant представляет собой специализированную систему векторного поиска с клиент-серверной архитектурой. Данные хранятся в коллекциях точек, любая из которых имеет вектор и необязательные метаданные (payload). Поддерживаются плотные и разреженные векторы и гибридный поиск, объединяющий семантический и лексический.

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

Варианты размещения. Документация перечисляет четыре: собственное развертывание версии с открытым кодом, управляемое облако Qdrant, гибридное облако с разделенной ответственностью на ваших кластерах и частное облако с полным владением. Это дает путь от собственного сервера к управляемому сервису без изменения технологии.

Ресурсы. По умолчанию векторы хранятся в оперативной памяти, но их можно перенести на диск вместе с HNSW-индексом. Для продуктивной среды документация рекомендует по меньшей мере две реплики.

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

Pinecone и Chroma

Эти два варианта часто противопоставляются как «облачный сервис» и «локальную библиотеку». Оба описания не полны.

Pinecone

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

Изоляция. Пространства имен (namespaces) разделяют данные разных арендаторов в одном индексе.

Эксплуатация. Главное отличие от собственного сервера в том, кто отвечает за инфраструктуру. Документация упоминает резервные копии индексов, выделенные узлы для стабильно высокой нагрузки и вариант Bring Your Own Cloud, то есть развертывание в собственной облачной учетной записи клиента. Для компании без инфраструктурной команды это существенное преимущество. Для закрытого контура нужно отдельно проверить, подходит ли вам любой из доступных вариантов размещения.

Chroma

Chroma является инфраструктурой данных для ИИ с открытым кодом по лицензии Apache 2.0. Документация описывает три способа работы: локально, в собственном развертывании или Chroma Cloud как управляемом бессерверном сервисе. Среди возможностей: плотный, разреженный и гибридный поиск, поиск по ключевым словам и регулярным выражениям без эмбедингов, фильтрация по метаданным и поиск по изображениям и другим модальностям.

Обзор описывает возможности продукта в целом: доступность каждого типа поиска следует сверить для конкретной версии и режима. Возможность Chroma Cloud не следует автоматически приписывать локальной установке. Поэтому описывать Chroma только как инструмент прототипа на ноутбуке некорректно. Ее сильная сторона в том, что начать можно очень быстро и локально, а затем перейти на сервер или в облако. Но, как и для любой базы, требования производительной эксплуатации (резервирование, права, мониторинг, погрузка) нужно проверить для того режима, который вы планируете использовать, а не для того, в котором делали прототип.

Сравнительная таблица

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

Механизм разделения данных сам по себе не заменяет авторизацию. Сервер должен определять разрешенный tenant, namespace или фильтр из проверенного лица пользователя, а не доверять значению клиентского запроса. Отдельно проверьте попытки чтения и смены чужих данных; это требование к вашей системе для любой из четырех баз.

Как честно тестировать

Сравнение векторных баз легко сделать несправедливым. Чтобы результат что-то означал, одинаковыми должно быть шесть вещей.

Эмбединги. Та же модель эмбедингов, те же векторы. Если одна база создает эмбединги сама, а для другой вы считаете их в отдельности, вы сравниваете модели, а не базы.

Запросы. Один и тот же набор реальных запросов пользователей, а не синтетические случайные векторы.

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

Качество поиска. Сначала измерьте ANN recall@k: какую часть эталонных top-k соседей по той же метрике и фильтрам вернул приближенный индекс. Точный поиск pgvector может дать такой эталон. Затем отдельно проверьте содержательную релевантность по ответам специалистов и качеством конечных ответов модели. Ближайший вектор не обязательно нужен бизнес-документ.

Нагрузка. Реалистичное количество одновременных запросов и одновременные обновления данных. База, быстрая на пустом сервере, может вести себя иначе при переиндексации.

Конфигурация. Сравненные ресурсы и настройки индексов. Параметры HNSW или IVFFlat оказывают существенное влияние и на скорость, и на полноту, поэтому записывайте их рядом с результатами.

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

Решение и план миграции

Выбор базы не окончательный на годы. Но миграция дешевле, если ее спланировать до старта.

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

Храните источник отдельно. Держите исходные тексты фрагментов, метаданные и версию модели эмбедингов в собственном хранилище, независимо от векторной базы. Тогда переезд возможен даже без разгрузки векторов: базу можно перестроить с нуля. Это же пригодится при изменении модели эмбедингов, когда векторы все равно придется пересчитать.

Восстановление. Восстановите базу из резервной копии на тестовой среде еще до запуска. Запишите сколько это заняло и что пришлось делать вручную.

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

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

Что сделать в ближайшее время:

1. Запишите требования: объем и рост, фильтры, изоляцию арендаторов, частоту обновлений, резервирование, закрытый контур, команду.
2. По таблице выберите одного-двух кандидатов, соответствующих имеющейся инфраструктуре.
3. Произведите тест на одинаковых эмбедингах, реальных запросах и рабочих фильтрах, с точным поиском как эталоном полноты.
4. Проверьте восстановление из резервной копии в выбранном режиме развертывания.
5. Установите отдельное хранение исходных текстов, метаданных и версии модели эмбедингов.
6. Запишите процедуру выгрузки и переезда, пока система еще невелика.

Часто задаваемые вопросы