Сравнение pgvector, Qdrant, Weaviate, Milvus и Pinecone в 2026 году: бенчмарки QPS, цены, фильтрация, квантизация и понятная схема выбора векторной БД для RAG-проектов.
Обновлено: 2 июня 2026
Векторная база данных, это специализированное хранилище, оптимизированное для индексации и поиска эмбеддингов по приближённому ближайшему соседу (ANN). В 2026 году пять решений доминируют на рынке: pgvector (расширение PostgreSQL), Qdrant, Weaviate, Milvus и Pinecone. Если коротко: для прототипов и стеков с PostgreSQL берите pgvector; для self-hosted продакшна с миллиардами векторов подойдут Milvus или Qdrant; для управляемого SaaS без забот об инфраструктуре, Pinecone.
Векторная база данных хранит эмбеддинги, то есть числовые представления текста, изображений или аудио, и умеет быстро находить ближайшие по косинусной близости, скалярному произведению или евклидову расстоянию. В отличие от классических СУБД, где работают B-tree индексы, здесь используются специализированные структуры: HNSW (Hierarchical Navigable Small World), IVF, DiskANN, PQ. Их задача проста на словах и сложна на практике: найти приближённого ближайшего соседа за миллисекунды на коллекции в десятки миллионов векторов.
В 2026 году векторный поиск перестал быть нишей RAG-приложений. Его используют для семантической дедупликации логов, рекомендательных систем, мультимодального поиска по продуктам и даже для маршрутизации запросов между LLM-агентами. Если вы ещё не знакомы с базовой архитектурой, начните с нашего руководства по RAG-пайплайнам от А до Я, там подробно разобрано, как эмбеддинги попадают в индекс.
Честно говоря, я долго недооценивал важность фильтрации по метаданным. На одном из проектов мы получили p95 в 400 мс именно потому, что фильтр применялся пост-обработкой после top-k. Ключевые отличия векторной БД от классической: поддержка ANN-индексов с настраиваемыми компромиссами «скорость/точность» (recall@k), нативные операторы расстояния и, что важнее всего в 2026 году, фильтрация по метаданным внутри поиска, а не пост-фильтрация после top-k.
Ниже краткое сравнение по ключевым параметрам, которые волнуют команды при выборе векторной БД для production-проекта.
| Параметр | pgvector | Qdrant | Weaviate | Milvus | Pinecone |
|---|---|---|---|---|---|
| Лицензия | PostgreSQL | Apache 2.0 | BSD-3 | Apache 2.0 | Проприетарная SaaS |
| Язык движка | C | Rust | Go | C++/Go | Закрыто |
| Индексы | HNSW, IVFFlat | HNSW + квантизация | HNSW, Flat | HNSW, IVF, DiskANN, GPU | Собственный (serverless) |
| Гибридный поиск | Требует tsvector | BM25 встроен (1.10+) | Нативный BM25 + dense | Встроен (2.4+) | Sparse-dense (2024+) |
| Фильтрация | SQL WHERE | Богатая, payload-индексы | GraphQL where | Boolean expressions | Metadata filter |
| Деплой | В любой Postgres | Self-host / Cloud | Self-host / Cloud | Self-host / Zilliz Cloud | Только SaaS |
| Цена (1М векторов 1536d) | ≈$15/мес VPS | ≈$25/мес Cloud | ≈$25/мес Cloud | ≈$60/мес Zilliz | от $50/мес serverless |
| Лучший use case | Уже есть Postgres | Сложные фильтры | Multi-modal RAG | Миллиарды векторов | Zero-ops стартапы |
pgvector, это расширение PostgreSQL, которое добавляет тип vector и операторы расстояния <-> (L2), <#> (inner product), <=> (cosine). В версии 0.7 появилась бинарная квантизация и halfvec (float16), а в 0.8 завезли iterative index scan, который наконец решил классическую проблему: recall падает, если фильтр отсекает большую часть кандидатов.
Главное преимущество pgvector в том, что он работает там, где у вас уже есть Postgres. Не нужно поднимать отдельный сервис, синхронизировать данные, разбираться с двумя бэкапами. Транзакционная семантика, foreign keys, привычный SQL: всё на месте.
Минимальный пример создания и поиска:
-- Установка и создание таблицы
CREATE EXTENSION IF NOT EXISTS vector;
CREATE TABLE documents (
id BIGSERIAL PRIMARY KEY,
content TEXT NOT NULL,
embedding vector(1536) NOT NULL,
metadata JSONB
);
-- HNSW-индекс для косинусного поиска
CREATE INDEX ON documents USING hnsw (embedding vector_cosine_ops)
WITH (m = 16, ef_construction = 64);
-- Поиск top-5 ближайших с фильтром по метаданным
SELECT id, content, 1 - (embedding <=> $1) AS similarity
FROM documents
WHERE metadata->>'lang' = 'ru'
ORDER BY embedding <=> $1
LIMIT 5;Из ограничений: ANN-индекс строится дольше, чем в Qdrant или Milvus, а distributed-режим возможен только через Citus или партиционирование вручную. Если ваш план это 100+ млн векторов, лучше смотреть в сторону специализированных решений.
Qdrant написан на Rust и оптимизирован под сценарии, где векторный поиск сопровождается сложными фильтрами по payload. С версии 1.10 в нём появилась нативная поддержка BM25 для гибридного поиска, а версия 1.12 принесла GPU-индексацию через CAGRA и значительное ускорение HNSW.
Уникальная фишка Qdrant: payload-индексы. Вы можете объявить поле category или tenant_id как индексируемое, и движок будет использовать его внутри HNSW-обхода для фильтрации, а не после top-k. Это критически важно для multi-tenant RAG. Я сам столкнулся с этим, когда мигрировал проект с 40+ тенантами с pgvector: latency упала в три раза без каких-либо изменений в схеме.
from qdrant_client import QdrantClient
from qdrant_client.models import (
Distance, VectorParams, PointStruct, Filter, FieldCondition, MatchValue
)
client = QdrantClient(url="http://localhost:6333")
client.create_collection(
collection_name="docs",
vectors_config=VectorParams(size=1536, distance=Distance.COSINE),
)
# Индексируем payload-поле для быстрой фильтрации
client.create_payload_index(
collection_name="docs",
field_name="tenant_id",
field_schema="keyword",
)
client.upsert(
collection_name="docs",
points=[
PointStruct(id=1, vector=[0.1] * 1536,
payload={"tenant_id": "acme", "lang": "ru"}),
],
)
# Поиск с фильтром "внутри" HNSW-обхода
hits = client.query_points(
collection_name="docs",
query=[0.1] * 1536,
query_filter=Filter(must=[FieldCondition(key="tenant_id",
match=MatchValue(value="acme"))]),
limit=5,
).pointsQdrant также первым из open-source реализовал гибридный поиск с RRF (Reciprocal Rank Fusion) и квантизацию (scalar, product, binary) на уровне коллекции, что позволяет уместить миллиард векторов 1536d на одном узле с 64 ГБ RAM.
Weaviate выбирают команды, которым нужен встроенный гибридный поиск без отдельного BM25-движка. Запрос вида «найти векторно похожие документы И с совпадением по ключевым словам» отрабатывает одним вызовом, а итоговый ранг считается через RRF или нормализованную сумму.
Вторая особенность: модули векторизации. Weaviate может сам обращаться к OpenAI, Cohere, Anthropic или локальной модели через text2vec-transformers. Вы кладёте текст, а эмбеддинг строится автоматически. Это удобно для прототипов, но в проде многие отключают модули и индексируют уже посчитанные векторы (так проще управлять версионированием моделей).
В 2026 году Weaviate активно продвигает «agentic» сценарии: встроенные генеративные модули, которые принимают результаты поиска и сразу подают их в LLM с заданным промптом. Похожий паттерн мы разбирали в материале про мульти-агентные AI-системы.
Если ваш масштаб это сотни миллионов или миллиарды векторов, выбор сужается до Milvus. Перед нами distributed-архитектура с разделением слоёв query, data, index и coordinator. Согласно release notes Milvus 2.5, движок поддерживает HNSW, IVF, SCANN, DiskANN и GPU-индексы через NVIDIA CAGRA. Больше алгоритмов, чем у любого конкурента.
Milvus 2.5 добавил полноценный гибридный поиск (sparse + dense), функциональные индексы и улучшения по cold-start latency. Zilliz Cloud (управляемая версия Milvus) предлагает serverless-тариф, конкурирующий с Pinecone.
Минусы: высокая операционная сложность. Production-кластер Milvus в Kubernetes включает MinIO/S3 для хранения, etcd для координации, Pulsar или Kafka для message queue. Это серьёзная инфраструктура, и для команды без выделенного SRE это, мягко говоря, перебор.
from pymilvus import MilvusClient, DataType
client = MilvusClient(uri="http://localhost:19530")
schema = client.create_schema(auto_id=True, enable_dynamic_field=True)
schema.add_field("id", DataType.INT64, is_primary=True)
schema.add_field("vector", DataType.FLOAT_VECTOR, dim=1536)
schema.add_field("tenant", DataType.VARCHAR, max_length=64)
index_params = client.prepare_index_params()
index_params.add_index(field_name="vector", index_type="HNSW",
metric_type="COSINE", params={"M": 16, "efConstruction": 64})
client.create_collection(collection_name="docs", schema=schema,
index_params=index_params)
client.search(
collection_name="docs",
data=[[0.1] * 1536],
filter='tenant == "acme"',
limit=5,
output_fields=["tenant"],
)Pinecone это единственный игрок в этом списке без open-source версии. Зато самый «zero-ops» вариант: вы создаёте индекс через API и больше не думаете о шардировании, бэкапах, обновлениях. Архитектура serverless с 2024 года заменила старую pod-based: теперь оплата идёт за чтения, записи и хранение, а не за постоянно крутящиеся ноды.
Pinecone подходит командам, которые ценят скорость выхода на прод выше контроля над стеком. Из минусов: vendor lock-in (нельзя экспортировать индекс в стандартном формате), нестабильные цены на больших объёмах и невозможность кастомизировать алгоритм индексирования.
Если вы строите MCP-агента или LLM-сервис и не хотите тратить недели на инфраструктуру, посмотрите также наше руководство по MCP-серверам на Python. Оно показывает, как обернуть любую векторную БД в MCP-инструмент за час.
Независимые тесты ann-benchmarks и более свежие данные VectorDBBench 2026 на датасете 10М векторов 1536d показывают следующую картину для recall@10 = 0.95:
Важная оговорка: цифры выше это «голые» QPS без фильтрации. Как только включается высокоселективный payload-фильтр (например, tenant_id из 10 000 значений), порядок меняется. Qdrant и Milvus с индексированными полями ускоряются в 2–3 раза относительно конкурентов, у которых фильтр работает пост-обработкой.
Простая эвристика принятия решения в 2026 году:
Ещё один фактор это ваш стек для tool use. Если LLM-агент вызывает векторный поиск как инструмент, удобно объединять подходы из нашего материала о function calling и tool use с любым из перечисленных бэкендов.
Квантизация это главный рычаг снижения стоимости в 2026 году. Три уровня:
halfvec даёт похожий эффект).Практическое правило, которое я вывел на собственных проектах: всегда включайте rescoring (rerank) на полноразмерных векторах для top-100 кандидатов, отобранных квантизованным индексом. Это даёт почти исходный recall при минимальной памяти.
Для прототипов и проектов до 5–10 млн чанков pgvector почти всегда выгоднее: дешевле, проще в эксплуатации, нет vendor lock-in. Pinecone оправдан, если у команды нет ресурсов на администрирование PostgreSQL или требуется быстрый горизонтальный масштаб без переписывания.
Нет. Векторная БД хранит уже посчитанные эмбеддинги. Сами векторы вы получаете из модели (OpenAI, Cohere, Voyage, BGE или локальной). Некоторые БД (Weaviate, Milvus) умеют сами вызывать эмбеддер по конфигу, но это слой поверх той же модели.
На self-hosted pgvector около $15–25 в месяц на VPS с 4–8 ГБ RAM. На Qdrant Cloud или Weaviate Cloud получится $25–40. На Pinecone serverless от $50 при умеренной нагрузке. С бинарной квантизацией все цифры можно уменьшить в 4–8 раз.
Гибридный поиск объединяет dense-поиск (по эмбеддингам) с sparse-поиском (BM25 или SPLADE). Это помогает находить документы, где есть точные термины (имена, артикулы, аббревиатуры), которые dense-модель может «размыть». Финальный ранг считается через Reciprocal Rank Fusion или нормализованную сумму.
Для production-RAG почти всегда да. Cross-encoder reranker (Cohere Rerank 3, BGE-reranker-v2, Voyage rerank-2) применяется к top-50 кандидатам из векторного индекса и поднимает NDCG на 15–25%. Это компенсирует погрешности квантизации и приближённого поиска.
Большинство production-систем работают на 768–1536 размерности. Современные модели (text-embedding-3-large, voyage-3-large) поддерживают Matryoshka Representation Learning, что позволяет усечь вектор до 512 или 256 с потерей качества < 3%. Это снижает память и ускоряет поиск без переэмбеддинга.
Практическое руководство по prompt caching в OpenAI, Anthropic и Gemini на 2026 год: цены, TTL, cache_control breakpoints, совместимость с tool use и мониторинг hit rate с примерами на Python.
Сравнение Langfuse, LangSmith и Arize Phoenix в 2026: self-host, OpenTelemetry, prompt management, LLM-as-Judge и реальные цены на 3M трейсов в месяц.
Как получить гарантированно валидный JSON от LLM в 2026: Structured Outputs OpenAI, tool use в Claude, responseSchema в Gemini, Pydantic через Instructor и эвалы перед продакшном.