Vector databases для RAG: Weaviate vs Qdrant vs Milvus vs pgvector

Векторная база данных — это специализированное хранилище, которое ищет по смыслу, а не по ключевому слову: индексирует числовые эмбеддинги и возвращает ближайшие по cosine similarity. В 2026 году у self-hosted RAG-команд четыре практических варианта — Weaviate, Qdrant, Milvus и pgvector, — каждый со своим профилем производительности и операционной сложности.

Этот текст — реальное сравнение на корпоративных RAG-задачах с измерениями производительности, требований к ресурсам, и рекомендациями под конкретные сценарии.

Что должна делать векторная БД для RAG

Базовые требования:

Векторный поиск — по cosine similarity / dot product / euclidean distance
Метаданные — фильтрация по дополнительным полям (дата, автор, тип документа)
Hybrid search — комбинация векторного и ключевого (BM25) поиска
Масштабирование — от 100K до 100M векторов
Производительность — query latency < 50ms на десятках миллионов векторов
Backup/restore — на случай сбоев
Многопользовательский доступ — RBAC, изоляция коллекций

Все четыре кандидата покрывают 1-3 базово, но различаются на 4-7.

Weaviate

Что: open-source vector DB с фокусом на developer experience и встроенные ML-фичи.

Сильные стороны:

Hybrid search out-of-the-box — vector + BM25 в одном запросе с настраиваемым alpha-коэффициентом
Schema-aware — типизированные коллекции с полями, валидацией, реляциями
GraphQL API + REST — гибкий интерфейс для frontend
Module system — встроенные интеграции для embedders, reranker, generative AI
Multi-tenancy — встроенная поддержка для SaaS-приложений
Backup на S3 — стандартный путь
Apache 2.0 лицензия

Слабые стороны:

Тяжелее в памяти чем Qdrant (на тех же объёмах)
GraphQL не всем нравится
Cluster setup требует Kubernetes для production

Когда брать:

Production-grade RAG-системы
Когда нужен hybrid search и multi-tenancy
Команда комфортна с GraphQL или готова использовать REST
Корпоративные приложения с complex schema

Qdrant

Что: vector DB на Rust, фокус на производительность и эффективность ресурсов.

Сильные стороны:

Самая быстрая в чистом vector search — в 1.5-2x быстрее Weaviate на benchmarks
Эффективнее по памяти — на тех же 10M векторов использует 40-50% меньше RAM
gRPC + REST — высокопроизводительный интерфейс
Filtering — продвинутая фильтрация по метаданным с индексами
Snapshots — встроенный backup механизм
Apache 2.0 лицензия

Слабые стороны:

Hybrid search требует доп. интеграции (нет встроенного BM25)
Меньше встроенных ML-фич чем Weaviate
Schema менее формализована

Когда брать:

Real-time поиск с очень низкой latency (< 20ms)
Большие объёмы (10M+ векторов)
Когда экономия памяти критична
Простые use-case’ы без сложной schema

Milvus

Что: distributed vector DB от Zilliz. Industrial-strength для очень больших объёмов.

Сильные стороны:

Лучшее масштабирование — distributed-architecture для миллиардов векторов
Множество индексов — HNSW, IVF, FLAT, DISKANN — оптимизация под разные сценарии
GPU acceleration — для massive-scale поиска
Multi-replica и sharding — для high-availability
Apache 2.0 лицензия

Слабые стороны:

Сложнее в развёртывании (Kubernetes practically required)
Overkill для большинства корпоративных кейсов (< 10M векторов)
Outback в Python/Go SDK уступает Weaviate/Qdrant

Когда брать:

Very large scale (100M+ векторов)
Distributed deployment с автоматическим sharding
Команда с DevOps опытом

pgvector

Что: extension для PostgreSQL. Не отдельная БД, а векторный поиск внутри обычной Postgres.

Сильные стороны:

Уже есть PostgreSQL — никакого нового сервиса
Транзакции и SQL — atomic операции с векторами и обычными данными
Известная operational модель — все знают как обслуживать Postgres
Простота — для прототипов разворачивается за минуты
PostgreSQL License (BSD-like)

Слабые стороны:

Производительность хуже специализированных БД на больших объёмах (5-10x медленнее на 10M+ векторов)
Лимиты HNSW в pgvector хуже стандартных
Нет встроенного BM25 (доступно через ts_vector в Postgres, но менее оптимизированно)
Не masштабируется для very large scale

Когда брать:

Прототипы и MVP
Малые объёмы (< 1M векторов)
Когда уже есть Postgres-инфраструктура и не хочется добавлять новый сервис

Сравнение производительности

Публичный проект VectorDBBench от Zilliz регулярно публикует воспроизводимые бенчмарки специализированных векторных БД на различных датасетах. Результаты варьируются в зависимости от размерности векторов, объёма коллекции и железа, поэтому ниже — качественная картина, актуальная в 2026 году:

Qdrant стабильно показывает наименьшую latency и наименьший расход памяти на единицу векторов среди dedicated-движков — преимущество Rust-реализации HNSW.
Weaviate близок к Qdrant по latency на средних объёмах (1-10M), при этом выигрывает встроенным hybrid search, что экономит отдельный BM25-сервис.
Milvus берёт масштабом: distributed-архитектура с GPU-acceleration даёт преимущество при 100M+ векторов; на меньших объёмах операционная сложность не окупается.
pgvector в разы медленнее специализированных движков на коллекциях от 5M+ векторов — это расплата за работу внутри Postgres без выделенного HNSW-сервера.

Актуальные цифры на разных датасетах и железе — на странице результатов VectorDBBench и ANN-Benchmarks.

Реальные сценарии

Сценарий 1: средняя корпоративная RAG-система (1M векторов)

Рекомендация: Weaviate

Достаточно производительности для 1M
Hybrid search встроен — экономит время разработки
Schema-aware упрощает работу с метаданными
Production-ready без дополнительных интеграций

Сценарий 2: real-time customer-facing поиск (5M векторов)

Рекомендация: Qdrant

Низкая latency критична
Memory эффективность позволяет уместиться в одну ноду
Простота API
Hybrid search через дополнительный BM25-сервис

Сценарий 3: enterprise data lake с миллиардами векторов

Рекомендация: Milvus

Distributed-architecture для масштаба
GPU acceleration на больших объёмах
Готов к multi-DC deployment

Сценарий 4: прототип / proof-of-concept

Рекомендация: pgvector

Если есть Postgres — нулевая нагрузка
Быстрый старт
Достаточно для < 100K векторов

Hybrid search: важная деталь

В RAG hybrid search (vector + keyword) даёт +5-15% recall. Это особенно важно на запросах с конкретными именами/числами/кодами, где чистый embedder может промахнуться.

Поддержка hybrid:

Weaviate: ✅ встроенный BM25 + vector с настраиваемым alpha
Qdrant: ⚠️ через дополнительный сервис (Elasticsearch/Tantivy)
Milvus: ⚠️ через дополнительный сервис
pgvector: ⚠️ через ts_vector (медленнее специализированных)

Для большинства корпоративных RAG hybrid search обязателен — это аргумент в пользу Weaviate.

Stack рекомендация для AGmind

Дефолт в AGmind: Weaviate.

Причины:

Hybrid search встроенный — не нужно ставить отдельный Elasticsearch
Schema позволяет хорошо организовать корпоративные коллекции (юристы / продажники / поддержка — отдельные tenants)
Backup на S3 интегрирован
Sufficient производительности для 1-10M векторов на одной ноде

Альтернативы: для специфических кейсов могут быть оправданы:

Qdrant — если real-time latency критична
Milvus — для распределённого deployment >100M векторов
pgvector — для пилотов и небольших проектов

Грабли при работе с vector DB

1. Размерность вектора фиксируется при создании коллекции. Поменять с 1024 на 768 без переindex’а нельзя.

2. HNSW параметры влияют на качество. ef_construction, M, ef_search — от их настройки зависит точность поиска. Стандартные defaults (M=16, ef=128) дают приличный baseline, но для production нужен tuning.

3. Метаданные раздувают БД. Если в каждом векторе хранить много полей (full text, JSON metadata) — объём диска быстро растёт. Стратегия: только поля для фильтрации в DB, полный текст в отдельном S3.

4. Memory mapping vs in-memory. Все четыре БД могут работать в обоих режимах. In-memory быстрее но требует RAM. Memory-mapped — медленнее но позволяет работать с базой больше RAM.

5. Backup стратегия. Vector DB без backup’а = потеря базы при сбое = пересчёт всех эмбеддингов = часы downtime. Регулярные snapshot’ы обязательны.

Стоимость владения

Для команды 30 человек, 5M векторов в RAG:

Параметр	Weaviate	Qdrant	Milvus	pgvector
Дополнительный сервис нужен?	Да (Weaviate)	Да (Qdrant)	Да (Milvus + etcd + Pulsar)	Нет (Postgres уже есть)
RAM для базы	12 GB	7 GB	14 GB	18 GB
Disk	50 GB	35 GB	60 GB	80 GB
Operational complexity	Средняя	Низкая	Высокая	Низкая

В реальной AGmind инфраструктуре vector DB занимает 15-20% общего ресурса GPU-сервера.

Что часто упускают

1. Reindex дорого. При смене эмбеддера или существенных изменений schema нужно переcчитать все векторы. На 10M документах это 12-24 часа GPU-времени.

2. Cold start vs warm. После рестарта БД может тратить минуты на загрузку индексов в RAM. Для production важно warmup-strategy.

3. Multi-tenancy — отдельная задача. Если разные отделы должны видеть только свои данные — это нужно архитектурно поддержать, не «потом добавим».

4. Network latency. Vector DB на отдельной machine от LLM-сервера = +5-15ms на каждый запрос. Лучше collocate если возможно.

Итог

Выбор vector DB определяется масштабом, требованиями к latency и нужностью hybrid search:

1-10M векторов с hybrid search: Weaviate (дефолт для AGmind)
5-50M, фокус на скорость: Qdrant
50M+, distributed: Milvus
<1M, пилоты: pgvector

В AGmind мы стандартно ставим Weaviate. Для специальных кейсов можем перейти на другую БД на этапе аудита.

Связанные тексты: архитектура AI-помощника, embedding модели для русского, реранкеры, RAG объяснение.