Векторные базы 2026: Qdrant, Milvus, pgvector, Chroma на реальной нагрузке

ЗАЧЕМ ВООБЩЕ ОТДЕЛЬНАЯ ВЕКТОРНАЯ БАЗА В 2026

За два года RAG перестал быть хайпом и стал скучной инфраструктурой. Эмбеддинги генерятся пачками, документы обновляются инкрементально, а на проде важна не красота демо, а p99-latency под реальным QPS и стоимость памяти на миллион векторов. Именно на этих метриках четыре популярных движка — векторная база нового поколения — расходятся сильнее всего.

Ключевое отличие 2026 года: почти все перешли на HNSW как базовый индекс, а конкуренция сместилась в область фильтрации по метаданным, квантизации и гибридного (dense + sparse) поиска. Свежие релизы движков отслеживаются в каталоге REDDYX, и темп там не падает.

УЧАСТНИКИ И ИХ АРХИТЕКТУРНАЯ ПОЗИЦИЯ

Qdrant

Написан на Rust, single-binary, но умеет в кластер. Сильная сторона — фильтрация: payload-индексы позволяют делать pre-filtering без разрушения графа HNSW. Есть скалярная и бинарная квантизация, что режет память в разы. По ощущениям практиков — самый предсказуемый по хвостам latency под смешанной нагрузкой.

Milvus

Распределённая система из коробки: разделены compute и storage, отдельные ноды под query, data, index. Масштабируется на миллиард векторов, но за это платите операционной сложностью — etcd, объектное хранилище, message queue. Для одиночного сервиса это оверкилл. Есть облегчённый режим Milvus Lite для локалки.

pgvector

Не отдельная база, а расширение Postgres. Именно поэтому побеждает в проектах, где Postgres уже стоит: транзакции, JOIN с бизнес-данными, бэкапы, права — всё бесплатно. С появлением HNSW-индекса и итеративного сканирования для фильтров pgvector закрыл большинство сценариев RAG до нескольких миллионов строк.

Chroma

Оптимизирован под developer experience: три строки Python и у вас работающий поиск. Отлично для прототипа, ноутбука, локального RAG. Под серьёзным конкурентным QPS и большими объёмами исторически проседает — это инструмент этапа разработки, а не хайлоада.

МЕТОДИКА: КАК ЧЕСТНО МЕРИТЬ

Любой бенчмарк векторных баз врёт, если не зафиксировать три вещи: recall, конфиг индекса и характер нагрузки. Сравнивать latency при recall@10 = 0.95 против recall@10 = 0.80 — это сравнивать разные задачи. Стандарт де-факто в сообществе — методология ann-benchmarks: строим кривую recall/QPS, а не одну цифру.

• Recall — фиксируем целевой (обычно 0.95 или 0.99) и подгоняем параметры под него.
• Параметры HNSW — M, ef_construction на записи и ef_search на чтении определяют всё.
• Нагрузка — чистый ANN, ANN + фильтр, конкурентная запись во время чтения дают радикально разные результаты.
• Размерность — 768 (bge, e5) и 1536 (OpenAI) ведут себя по-разному по памяти и скорости.

СВОДНАЯ ТАБЛИЦА СРАВНЕНИЯ

Цифры ниже — обобщённые ориентиры по замерам сообщества и типовым прод-конфигам на датасете порядка 1–5 млн векторов, 768-мерных, recall@10 ≈ 0.95, одна нода среднего размера. Это порядки, а не абсолютная истина — на вашем железе и данных всё сдвинется.

ЧТО ПРОИСХОДИТ ПОД НАГРУЗКОЙ: ТОНКИЕ МЕСТА

Фильтрация ломает ANN

Главная ловушка прода. Наивный подход — сначала найти ближайших соседей, потом отфильтровать по tenant_id или category. Если фильтр отсекает 99% данных, вы получите почти пустой результат или recall уедет в пол. Qdrant решает это payload-индексами и оценкой кардинальности фильтра, pgvector в свежих версиях — итеративным сканированием индекса. Это то место, где Chroma и наивные интеграции чаще всего разваливаются.

Память и квантизация

Миллион 1536-мерных float32-векторов — это около 6 ГБ только на сырые данные, плюс граф HNSW. Скалярная квантизация (int8) режет это примерно в 4 раза с минимальной потерей recall, бинарная — в разы агрессивнее, но требует rescoring. Если бюджет на RAM ограничен, квантизация в Qdrant/Milvus — не опция, а обязательный этап.

Запись во время чтения

HNSW дорог на вставку. При постоянном потоке апдейтов (свежие документы каждую минуту) конкурентная запись бьёт по latency чтения. Milvus разводит это по разным нодам, Qdrant использует сегменты, pgvector наследует MVCC Postgres со всеми плюсами и минусами вакуума.

КОД: ОДНА И ТА ЖЕ ЗАДАЧА НА ДВУХ ДВИЖКАХ

Ниже — поиск с фильтром по метаданным, как это реально выглядит в RAG-пайплайне. Сначала Qdrant.

from qdrant_client import QdrantClient
from qdrant_client.models import Filter, FieldCondition, MatchValue

client = QdrantClient(url="http://localhost:6333")

# поиск ближайших с ЖЁСТКИМ фильтром по tenant и языку
hits = client.query_points(
    collection_name="docs",
    query=query_vector,          # list[float], 768 dim
    query_filter=Filter(
        must=[
            FieldCondition(key="tenant_id", match=MatchValue(value=42)),
            FieldCondition(key="lang", match=MatchValue(value="ru")),
        ]
    ),
    limit=10,
    search_params={"hnsw_ef": 128},   # управляем recall/latency
    with_payload=True,
).points

for h in hits:
    print(h.score, h.payload["title"])

Та же логика на pgvector — обычный SQL, фильтр это просто WHERE, а близость считает оператор <=> (косинус):

-- индекс создаётся один раз
CREATE INDEX ON docs USING hnsw (embedding vector_cosine_ops)
  WITH (m = 16, ef_construction = 64);

-- для нормального recall при фильтрации
SET hnsw.ef_search = 128;
SET hnsw.iterative_scan = 'relaxed_order';

SELECT title, embedding <=> :query_vector AS distance
FROM docs
WHERE tenant_id = 42 AND lang = 'ru'
ORDER BY embedding <=> :query_vector
LIMIT 10;

Разница в философии видна сразу: Qdrant — специализированный API с явным контролем графа, pgvector — привычный SQL, где вектор просто ещё один тип колонки рядом с бизнес-данными.

КАК ВЫБРАТЬ ПОД СВОЙ СЦЕНАРИЙ

1. Уже есть Postgres, объём до нескольких млн векторов — pgvector. Не плодите инфраструктуру ради задачи, которую решает расширение. JOIN с метаданными и транзакции того стоят.
2. Десятки миллионов векторов, жёсткая multi-tenant фильтрация, нужна низкая p99 — Qdrant. Оптимальный баланс скорости, фильтрации и простоты эксплуатации.
3. Сотни миллионов — миллиард, отдельная команда платформы — Milvus. Только если реально упёрлись в потолок и готовы к распределёнке.
4. Прототип, локальная разработка, демо — Chroma. Быстрый старт, потом мигрируете, если проект взлетит.

Частая ошибка — тащить Milvus в MVP «на вырост». В 2026 миграция между движками занимает день-два (эмбеддинги переносимы), а операционная боль от преждевременной распределёнки — постоянна. Начинайте с самого простого варианта, который проходит по объёму.

Векторные движки в 2026-м обновляются буквально еженедельно — новые режимы квантизации, gpu-индексы, гибридный поиск. Чтобы не пропустить релиз, который сэкономит вам половину RAM, загляните в Telegram-канал REDDYX AI — новые репозитории каждые 30-60 минут.