Vector DB 2026: Qdrant, Weaviate, Pinecone, Chroma — сравнение

Vector DB в 2026 — это уже не игрушка для демо и не «поисковик на стероидах», а нормальный инфраструктурный слой для RAG, семантического поиска, рекомендаций и агентов, которым нужен быстрый доступ к контексту. Ниже — практическое сравнение Qdrant, Weaviate, Pinecone, Chroma, Milvus и pgvector: где они реально сильны, где вы платите за удобство, и что брать, если у вас не абстрактный кейс, а живой прод.

Что такое векторная база и зачем она в 2026

Почему обычного SQL уже мало

Если совсем без романтики, Vector DB нужна там, где данные уже не укладываются в точные совпадения. Текст, изображения, тикеты поддержки, карточки товаров, лог-фрагменты, код, голосовые заметки, эмбеддинги из LLM — все это превращается в числа, и дальше вам нужно находить не «равно», а «похоже». Для этого и живет векторная база: хранит эмбеддинги, быстро ищет ближайшие соседние векторы, умеет работать с метаданными и не ломается, когда у вас не 10 тысяч объектов, а 10 миллионов и выше.

Что изменилось к 2026 году

Главный сдвиг за последние два года — поиск перестал быть просто «semantic search». В бою почти всегда нужен гибрид: плотные векторы плюс ключевые слова, фильтрация по атрибутам, rerank, иногда мультивекторы и несколько стадий извлечения. В 2026 году векторная БД уже не живет отдельно от RAG-пайплайна: она участвует в retrieval, иногда в маршрутизации запросов, иногда в рекомендациях и персонализации. Если база не умеет нормально работать с фильтрами, обновлениями, гибридным поиском и разными типами индексов, ее быстро начинают окружать костыли из Postgres, Elasticsearch и самописных очередей.

На что смотреть, кроме «поддерживает ли embeddings»

Самая частая ошибка — сравнивать продукты по одному параметру, обычно по скорости на красивом графике. В реальности вам важнее четыре вещи: латентность на вашем размере коллекции, recall при нужной точности, стоимость владения и операционная сложность. Например, 1 миллион векторов по 768 float32-измерениям — это уже примерно 3,1 ГБ «сырого» векторного массива без индексов и метаданных. Добавьте HNSW-граф, payload, репликацию и бэкапы — и внезапно «всего лишь векторная база» требует памяти, SSD и дисциплины.

Еще одна развилка — где будет жить система. Если вам нужен быстрый запуск и минимум администрирования, смотрите в сторону managed-сервисов. Если важны контроль над инфраструктурой, residency, изоляция или бюджет на длинной дистанции, self-host остается нормальным выбором. Векторная БД перестала быть экзотикой, но лучше от этого не стала автоматически: просто она теперь влияет на деньги, SLA и качество поиска почти так же, как классический SQL-слой.

Qdrant — open-source лидер из РФ-команды

Сильные стороны: фильтры, гибрид и контроль

Qdrant часто выбирают команды, которым нужно не только хранить эмбеддинги, но и задавать поиск по бизнес-логике без ощущения, что система сейчас развалится. У него сильная сторона — payload как JSON-метаданные, мощная фильтрация и гибридные запросы. В документации Qdrant отдельно подчеркивает, что фильтры применяются в процессе обхода HNSW, а не «после», что важно для качественного поиска на сложных сценариях. Для RAG это особенно приятно: можно отрезать лишнее по tenant, языку, дате, типу документа, правам доступа и не терять в recall больше, чем нужно.

Что умеет в 2026 году

Qdrant поддерживает dense, sparse и multivector-конфигурации, а также native hybrid search: плотные и разреженные представления можно комбинировать на стороне сервера. Внутри есть quantization, включая scalar, product и binary варианты, чтобы уменьшать память и ускорять поиск. На сайте Qdrant отдельно заявляет memory-efficient storage и снижение использования памяти до 64x в некоторых режимах, но, как обычно, за это приходится платить настройкой и аккуратным выбором параметров. Для продакшена это не баг, а плата за контроль.

Из приятных вещей — Qdrant хорошо подходит для сценариев с богатыми метаданными: каталог товаров, поиск по базе знаний, рекомендации, мультимодальные коллекции, кейсы с несколькими векторами на один объект. Под капотом это Rust, что для инфраструктуры на критическом пути обычно плюс, а не повод для поэтических размышлений. В cloud-предложении у Qdrant есть Free Tier со single-node кластером, Standard с usage-based моделью и HA, Premium с SSO, Private VPC Links и повышенным SLA.

Когда брать, а когда нет

Qdrant стоит смотреть, если вам нужен баланс между open source, производительностью и адекватной эксплуатацией. Хороший выбор для RAG, поисковых движков, рекомендаций, фильтруемых каталогов и команд, которые не хотят отдавать retrieval целиком во внешнее облако. Но если вам нужен максимально готовый managed-поток с hosted embeddings, rerank и минимумом решений на своей стороне, Qdrant уже не выглядит как самый ленивый вариант. Он скорее про инженерный контроль, чем про «нажали кнопку и забыли».

По данным официальной страницы цен, Qdrant Cloud дает Free Tier навсегда, Standard с гибким масштабированием и Premium для enterprise-сценариев. Это нормальная лестница: сначала прототип, потом прод, потом изоляция и compliance. Для многих команд это и есть тот редкий случай, когда Vector DB не навязывает архитектуру, а подстраивается под нее.

Weaviate — фичи hybrid search и модули

Гибридный поиск как штатная функция

Weaviate нравится командам, которым нужен не просто поиск по векторам, а сразу «по-человечески»: semantic плюс keyword, плюс контроль весов, плюс объяснимость выдачи. В официальной документации гибридный поиск строится на комбинации vector search и BM25F, а fusion method можно настраивать. Это важно для RAG, где пользовательский запрос нередко содержит и смысл, и точные термины, и артефакты доменной лексики. Чистая семантика иногда слишком умна для собственного блага; Weaviate это понимает.

Модули, интеграции и мульти-тенантность

Ключевая идея Weaviate — модульная архитектура. Без модулей это чистая векторная база, а с модулями вы получаете vectorizers, rerankers, generative AI integrations и backup/offloading возможности. Это удобно, если хотите собрать retrieval pipeline без оркестрации из пяти внешних сервисов. На стороне данных Weaviate умеет multi-tenancy, причём tenant хранится на отдельном shard'е. Это не просто маркетинг: для B2B-продуктов и SaaS-моделей изоляция по tenant часто определяет, сможете ли вы вообще жить в одном кластере без боли.

Есть и практичные детали. В multi-tenancy автоматическое создание тенанта доступно с v1.25.0 для batch import и с v1.25.2 для single inserts. Имена тенантов ограничены 4-64 символами, только alphanumeric, underscore и hyphen. Это мелочи, но именно из них и состоит эксплуатация, а не из слайдов с искусственным интеллектом.

Цена удобства

У Weaviate сильная managed-линейка. На текущей странице цен есть Free Trial на 14 дней, Flex от $45 в месяц и Premium с контрактной моделью. Enterprise Cloud стартует от $2.64 за AIU, а для Premium на странице указан минимум от $400 в месяц. Плюс есть BYOC, если вам нужно оставить данные в собственном VPC. Хорошая новость: hybrid search, compression, replication и multi-tenancy входят в базовый набор почти во всех планах. Плохая: если у вас большой production, счет быстро перестает быть «стартовым».

Weaviate стоит брать, когда вам нужен богатый retrieval слой, встроенные модули и нормальный managed путь. Это сильный кандидат для RAG, корпоративного поиска и приложений, где hybrid search — не опция, а обязательная часть качества. Если же вам нужен максимально тонкий контроль над индексом и жесткая настройка фильтрации на уровне движка, Qdrant часто дает больше свободы. Weaviate, наоборот, продает удобство и композицию.

Pinecone — managed-облако без инфраструктуры

Для тех, кто не хочет быть дежурным по кластерам

Pinecone — это вариант для команд, которым нужна векторная база как сервис, а не как вторая работа. У них упор на полностью managed-инфраструктуру, встроенный inference, hosted embeddings и reranking. В документации Pinecone отдельно подчеркивает, что можно использовать integrated embedding: загружаете текст, а система сама превращает его в векторы. Для старта это очень удобно: меньше клея, меньше ошибок, меньше поводов собрать ретривер из случайных библиотек в пятницу вечером.

Гибрид, namespaces и ограничения, о которых лучше знать заранее

Hybrid search в Pinecone тоже есть, и реализуется двумя способами: через отдельные dense и sparse indexes или через single hybrid index. Первый способ рекомендуют чаще, потому что он гибче: можно отдельно масштабировать semantic и lexical часть, а потом rerank'ить результаты. Namespaces используются для мультиарендности и изоляции данных между клиентами или сегментами. Это удобная штука, если у вас один индекс, но много логически отдельных наборов данных.

Есть и важные технические рамки. Pinecone в документации указывает, что query result size ограничен 4 MB, а `top_k` может доходить до 10 000. Для больших выдач это уже не игрушка. Еще один практический нюанс — eventual consistency: изменения могут быть видны не мгновенно. Для RAG это не смертельно, но если вы ждете строгую синхронность после апдейта, лучше учитывать лаг.

Когда managed действительно оправдан

На прайсинге Pinecone сейчас есть Starter с бесплатным входом и Standard от $50 в месяц минимального usage. Для многих стартапов это дешевле, чем нанимать отдельного человека «чтобы он просто следил за векторной базой». Но у managed-удобства есть оборотная сторона: вы платите не только деньгами, но и зависимостью от платформы. Если вам нужен zero-ops путь, единая точка для embeddings, retrieval и rerank, Pinecone остается очень сильным вариантом. Если нужен глубокий контроль над движком и инфраструктурой, это уже не его жанр.

Pinecone хорош, когда time-to-market важнее, чем архитектурный романтизм. Для RAG, ассистентов, поиска по знаниям и production-экспериментов он удобен именно тем, что не заставляет вас думать о дисках, репликах и даунтаймах каждый раз, когда бизнесу захотелось «еще одну фичу на вчера».

Chroma — для прототипов и небольших проектов

Сильный старт и очень короткий путь до результата

Chroma в 2026 году — это open-source поиск для AI, который особенно хорош там, где важна скорость запуска. Официальная документация говорит прямо: есть local, single-node и distributed deployment modes, а single-node обычно подходит для небольших и средних нагрузок, ориентировочно менее 10 миллионов записей в нескольких коллекциях. Это уже не совсем «игрушка», но и не промышленный танк. В этом и прелесть: можно начать на ноутбуке, а потом без смены API переехать в cloud.

Что умеет из коробки

Chroma поддерживает dense, sparse и hybrid search, фильтрацию по metadata, full-text и regex search, а также мультимодальное хранение. Для команд, которые делают code search, agentic search или экспериментируют с retrieval pipelines, это очень удобный набор. В Cloud-версии под капотом тот же Apache 2.0-licensed engine, просто управляемый как serverless-сервис. Это хороший компромисс для небольших продуктов: не надо сразу строить распределенную систему, чтобы проверить, вообще работает ли ваша идея.

Экономика и границы применения

Цены у Chroma Cloud прозрачные и довольно приземленные: writes стоят $2.50 за logical GiB, reads — $0.0075 за TiB queried и $0.09 за GiB returned. Еще есть forking коллекций за $0.03 за fork request, а копирование работает по принципу copy-on-write. Для прототипов и ветвления коллекций это очень удобно, особенно если вы индексируете кодовые базы, документы или наборы экспериментальных данных. Но есть и ограничения: у fork tree по умолчанию лимит 256 edges, так что бесконечно ветвиться не получится.

Chroma стоит брать для POC, тестовых сервисов, небольших продов, семантического поиска в отдельных доменах и тех сценариев, где хочется быстро проверить retrieval-идею без тяжелого администрирования. Если же у вас строгая изоляция, высокие нагрузки или потребность в сложной мультиарендности, лучше смотреть в сторону более зрелых production-стеков. Chroma — это не слабый продукт. Это просто продукт с правильной геометрией для маленького старта.

Milvus / Zilliz — высокомасштабные сценарии

Когда размер действительно имеет значение

Milvus — это open-source векторная база, которую чаще всего вспоминают в разговорах о больших объемах, мультимодальности и архитектурах, где «пара миллионов» — это только начальный этап. В официальных материалах Milvus позиционируется как high-performance и highly scalable vector database, доступная как open-source и как cloud service. Документация отдельно говорит о масштабировании до десятков миллиардов векторов с минимальной потерей производительности. Если ваш кейс — действительно большой корпус, Milvus имеет смысл смотреть раньше, чем потом чинить архитектурную недостачу.

Индексы и storage-реальность

У Milvus сильная сторона — широкий набор индексов и режимов. В документации есть HNSW, IVF и DiskANN для on-disk сценариев. DiskANN особенно интересен, когда данные уже не помещаются комфортно в RAM: в официальных материалах он описывается как способ работать с datasets в диапазоне от миллиардов до триллионов векторов, опираясь на SSD и аккуратный компромисс между recall и latency. Это уже территория не «быстрой демки», а серьезной платформенной инженерии. Для on-disk режима Milvus прямо рекомендует NVMe SSD, а в параметрах DiskANN есть `search_list`, `beam_width_ratio` и другие knobs, которые обычно любят SRE и ненавидят те, кто хотел «просто поиск по смыслу».

Zilliz Cloud как managed-слой

Если не хочется собирать кластер руками, Zilliz Cloud закрывает managed-путь. На странице free trials указано, что бесплатный кластер дает 5 GB, до 2.5 млн vCUs в месяц и до 5 collections. Для serverless pricing используется pay-per-operation: по документации стоимость в Cloud строится через vCU, а примерная ставка указана как $4 за миллион vCUs. Есть и dedicated clusters с pay-as-you-go compute, а также global cluster для multi-region сценариев. Это хорошая опция, если вам нужна промышленная платформа, но вы не хотите строить ее из Kubernetes, object storage и молитв.

Milvus и Zilliz — это выбор для действительно больших retrieval-задач, мультимодального поиска, рекомендаций и enterprise-RAG, где объем, масштабирование и SSD-архитектура важнее простоты старта. Если данных мало, он будет выглядеть как спортивный грузовик для поездки в булочную. Если данных много, внезапно окажется, что это был как раз ваш размер обуви.

pgvector — расширение PostgreSQL

Когда векторный поиск должен жить рядом с SQL

pgvector — это тот случай, когда Vector DB не нужна как отдельный продукт. Вам просто хочется хранить эмбеддинги там же, где уже живут пользователи, заказы, теги и транзакции. Расширение для PostgreSQL поддерживает точный поиск по умолчанию, а также approximate ANN через HNSW и IVFFlat. Это большой плюс для команд, у которых уже есть Postgres, знакомый backup-процесс, репликация и SQL-логика. Векторный поиск в этом случае становится не отдельной системой, а еще одним типом запроса.

Плюсы и ограничения без иллюзий

У pgvector есть очень полезные ограничения по размеру: `vector` до 2 000 измерений, `halfvec` до 4 000, `bit` до 64 000 и `sparsevec` до 1 000 non-zero элементов. Поддерживаются L2, inner product, cosine, L1, Hamming и Jaccard. По умолчанию поиск точный и дает perfect recall, а approximate-index уже добавляет компромисс между скоростью и полнотой. Для небольших и средних наборов данных это прекрасно. Для очень больших объемов и тяжелых hybrid-RAG это уже может стать узким местом, особенно если рядом живут сложные JOIN'ы, вакуум, аналитика и еще пара системных задач.

Еще один важный ориентир: каждый вектор хранится как `4 * dimensions + 8` байт. Это значит, что 1 миллион векторов размером 1536 float32 — это примерно 6,15 ГБ только на сырой массив. На практике добавьте индексы, метаданные, WAL, реплики и получите обычную жизнь, в которой «всего лишь расширение к Postgres» съедает заметно больше ресурсов, чем хотелось бы.

Где pgvector выигрывает

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

Бенчмарки: latency, recall, cost

Почему честный benchmark — это не один график

Сравнивать векторные базы по одной цифре бессмысленно. Латентность зависит от размера коллекции, dimension, фильтров, компрессии, типа индекса, наличия реплик, диска и того, что именно вы возвращаете в ответе. Recall, в свою очередь, зависит от параметров вроде `ef_search`, `m`, `lists`, числа probes, quantization и даже от того, насколько агрессивно вы фильтруете данные. Поэтому вместо магических «мы быстрее всех» полезнее смотреть на профиль нагрузки.

Практический срез по продуктам

Продукт	Latency-профиль	Recall-профиль	Cost-профиль
Qdrant	Сильный на фильтрах и смешанных запросах; фильтрация идет в процессе traversal.	Хорошо управляется через HNSW, sparse, multivector и quantization.	Free Tier, потом usage-based; выгоден там, где вы не платите за лишние сервисы.
Weaviate	Хороший баланс для hybrid search и managed cloud.	Гибкий благодаря fusion strategies, compression и multi-tenancy.	Flex от $45/мес, Premium от $400/мес, есть per-dimension и storage charges.
Pinecone	Managed-first, удобно для production без ops-команды.	Сильный hybrid через dense+sparse и rerank, но с консистентностью надо жить осознанно.	Starter free, Standard от $50/мес min usage, дальше pay-as-you-go.
Chroma	Лучше всего ощущается на небольших и средних коллекциях.	Dense, sparse и hybrid доступны, но задача не про «максимум всего сразу».	$2.50/GiB write, $0.0075/TiB queried, $0.09/GiB returned.
Milvus / Zilliz	Сильный масштаб, особенно при работе с большим объемом и SSD.	DiskANN дает путь к высоким recall на очень больших коллекциях.	OSS бесплатно, Zilliz Cloud: free cluster 5GB/2.5M vCUs, serverless $4 per million vCUs.
pgvector	Хорош на SQL-совместимых сценариях, но не любит, когда из него делают отдельную платформу.	Exact search дает perfect recall; ANN ускоряет, но добавляет компромиссы.	Лицензия бесплатна, платите за Postgres-инфраструктуру и ее операционные привычки.

Что реально стоит денег

Если упростить до одного абзаца, то дорогими оказываются не «векторы», а память, SSD, репликация, трафик и поддержка. Qdrant и Weaviate выигрывают там, где нужен хороший контроль над retrieval-пайплайном. Pinecone выигрывает по времени старта и снижению ops-боли. Chroma дешев и быстрый в начале, но быстро выходит на границы масштаба. Milvus и Zilliz живут там, где масштаб действительно оправдывает сложность. pgvector выигрывает, когда вы уже платите за Postgres и не хотите плодить лишний стек.

Отдельно полезно помнить про размер данных. 1 миллион векторов по 768 измерениям в float32 — это примерно 3,1 ГБ «чистой» математики. 10 миллионов таких векторов — уже около 30,7 ГБ, и это без payload и без индекса. Поэтому вопрос не в том, «сколько стоит Vector DB», а в том, сколько будет стоить ваш конкретный retrieval-путь при нужных latency и SLA.

Как выбрать под RAG / поиск / рекомендации

RAG: где важны фильтры и качество выдачи

Для RAG я бы смотрел так. Если нужны сложные фильтры, гибрид и тонкий контроль retrieval-пайплайна, чаще всего выигрывает Qdrant. Если хочется встроенные модули, managed-удобство и понятную hybrid-архитектуру, Weaviate очень силен. Если нужен полностью managed путь с hosted embeddings, rerank и минимальным количеством своих сервисов, Pinecone закрывает задачу без цирка с деплоем. Для RAG особенно важна не только семантика, но и точные термины, а значит hybrid search почти всегда лучше голого nearest neighbors.

Поиск: когда нужен keyword + semantic

Для product search, knowledge base search и поиска по документации важнее всего качество ранжирования и способность не промахиваться на доменной лексике. Weaviate и Qdrant здесь наиболее универсальны. Weaviate удобнее, если вам важны встроенные интеграции и быстрая сборка сервиса. Qdrant лучше, если нужен control-first подход, payload-фильтры и более инженерная гибкость. Pinecone тоже подходит, особенно если команда маленькая и хочет сосредоточиться на продукте, а не на инфраструктуре.

Рекомендации и персонализация

Для рекомендаций и similarity-based matching полезны multivector, фильтры и возможность быстро обновлять индексы. Qdrant и Milvus в этой зоне особенно сильны: первый — за удобный контроль и фильтрацию, второй — за масштаб и on-disk сценарии. Если рекомендации живут рядом с транзакционной моделью и требуют join'ов, pgvector нередко оказывается самым простым способом держать все в одном Postgres. Для ранних стадий Chroma тоже подходит, но обычно как рабочая лаборатория, а не финальная платформа.

Короткая карта выбора

1. Нужен managed и минимум ops: Pinecone или Weaviate Cloud.
2. Нужны сильные фильтры, hybrid и контроль: Qdrant.
3. Нужен быстрый старт и маленький проект: Chroma.
4. Нужен масштаб до очень больших коллекций: Milvus / Zilliz.
5. Нужно жить внутри PostgreSQL: pgvector.

Если совсем прагматично: векторная БД выбирается не по любви к бренду, а по сочетанию scale, filters, hybrid search, compliance и ops cost. В этом месте лучше быть скучным, чем героическим.

Self-host vs managed: критерии решения

Когда self-host оправдан

Self-host имеет смысл, если для вас критичны данные внутри собственного периметра, нестандартная инфраструктура, строгая сертификация или просто желание не платить за управляемый сервис в долгую. Это нормальный выбор для regulated environments, on-prem, edge, частных облаков и продуктов, где именно вы отвечаете за стоимость и SLA. Qdrant, Weaviate, Milvus и даже Chroma позволяют идти этим путем. pgvector вообще живет в том мире, где Postgres уже все решил за вас.

Когда managed экономит больше, чем кажется

Managed-сервис почти всегда выигрывает на старте. Вы экономите не только время DevOps, но и время команды, которая иначе будет разбираться с бэкапами, шардированием, апгрейдами, мониторингом и инцидентами. Pinecone, Qdrant Cloud, Weaviate Cloud, Chroma Cloud и Zilliz Cloud закрывают эту боль по-разному, но смысл один: если retrieval — не ваша core-экспертиза, не надо делать вид, что вы хотите провести ближайший квартал в компании Grafana. Для большинства product-команд это и есть рациональный путь.

Практическая шкала выбора

Критерий	Self-host	Managed
Time-to-first-query	Дольше: сначала инфраструктура, потом сервис.	Быстрее: обычно от минут до часов.
Операционная нагрузка	На вашей команде.	На вендоре.
Предсказуемость затрат	Высока, если умеете считать инфраструктуру.	Высока по счету, но зависит от usage.
Compliance и residency	Лучше для строгих контуров.	Зависит от плана, региона и политики провайдера.
Масштабирование	Гибкое, но руками.	Проще, но дороже за удобство.

Если у вас 5-10 миллионов векторов, один продукт и команда без dedicated infra-специалиста, managed часто окупается уже на первом месяце. Если же у вас сложная архитектура, много tenant'ов, строгая изоляция и крупный traffic spike, self-host или hybrid cloud начинают выглядеть куда серьезнее. Для небольших нагрузок стартуйте с простоты. Для больших — с контроля. Векторная база ошибку на старте не простит, но и лишний героизм обычно тоже не награждает.

Глубже на тему — исследования it-institute.ru

На партнёрском портале it-institute.ru опубликована подборка релевантных исследований с медианами, выборками и методологией:

• Тренды Data/ML платформ
• Cloud Native и Kubernetes 2026

Партнёрские проекты

• Stackfort — on-prem CDP-платформа

FAQ о Vector DB

Следите за обновлениями itech-news.ru — мы держим эту страницу актуальной.