Векторные базы данных в 2026: pgvector, Milvus, Qdrant и RAG в продакшне

Введение

В 2026 году векторные базы данных перестали быть экспериментальной технологией — они стали производственным стандартом для систем ИИ. Каждая уважающая себя компания, внедряющая RAG-пайплайны или агентные архитектуры, рано или поздно упирается в вопрос: «Какую векторную БД выбрать?». Рынок за три года проделал огромный путь от разрозненных стартапов до зрелых решений с миллиардными индексами, GPU-ускорением и встроенным гибридным поиском. Однако разнообразие опций породило новую проблему: паралич выбора.

Согласно опросу CNCF за первый квартал 2026 года, 68% организаций уже используют векторные базы данных в продакшне, но лишь 30% оценивают свой стек как «оптимальный». Остальные либо переплачивают за избыточную инфраструктуру, либо упираются в проблемы производительности, которые можно было предвидеть на этапе выбора. Эта статья — дорожная карта по современным векторным базам данных. Мы разберём трёх главных игроков открытого кода — pgvector, Qdrant и Milvus, — сравним их производительность на основе независимых бенчмарков 2026 года и дадим практический фреймворк для выбора под ваш сценарий.

Из статьи вы узнаете, как устроен production-level RAG в 2026-м, почему выбор векторной БД — это операционное, а не архитектурное решение, и как не переплатить за возможности, которые вам никогда не понадобятся. Материал основан на данных ANN-Benchmarks, VectorDBBench, опросах CNCF и DORA, а также на реальных кейсах внедрения в enterprise-секторе.

Три философии: pgvector, Qdrant и Milvus

Все три решения, доминирующие на рынке в 2026 году, представляют принципиально разные подходы к хранению и поиску векторов. pgvector — это расширение для PostgreSQL, которое добавляет векторный поиск в уже существующую базу данных. Qdrant — самостоятельная векторная БД на Rust, спроектированная вокруг производительности и фильтрации. Milvus — распределённая система, рассчитанная на миллиарды векторов и крупные enterprise-инсталляции.

Разница между ними не только в бенчмарках, но и в операционной модели. pgvector не требует нового стека — вы просто включаете расширение в своём PostgreSQL. Qdrant работает как отдельный сервис, но его можно поднять одной Docker-командой. Milvus требует целой экосистемы: etcd, MinIO (или S3-совместимое хранилище) и отдельные узлы для запросов, индексации и координации. Каждый из этих подходов оптимален для своего класса задач, и ни один не является универсальным решением.

pgvector: нулевая операционная стоимость

pgvector (версия 0.9, выпущенная в начале 2026 года) — это расширение PostgreSQL с открытым исходным кодом. Его главное преимущество не в скорости (хотя и с ней всё неплохо), а в том, что это просто PostgreSQL. Если вы уже используете эту базу данных — а по опросу Stack Overflow 2025, PostgreSQL используют 49% разработчиков, — то вы получаете векторный поиск без единого нового сервиса в инфраструктуре.

Версия 0.9 принесла значительные улучшения: ускорение IVFFlat, поддержку разреженных векторов (sparse vectors) и оптимизацию HNSW-индекса. Разработчики pgvector также улучшили производительность гибридного поиска, позволив комбинировать tsvector (полнотекстовый поиск PostgreSQL) с векторным поиском в одном запросе. Но настоящий прорыв произошёл благодаря экосистеме: расширение pgvectorscale от Timescale добавило индекс StreamingDiskANN, который хранит граф на SSD вместо RAM, позволяя эффективно работать с коллекциями, в 10 раз превышающими объём доступной памяти.

На 50 миллионах векторов размерности 768 pgvectorscale показывает 471 QPS при 99% точности — в 28 раз меньшую задержку, чем Pinecone s1 на том же объёме данных, при 75% более низкой стоимости самостоятельного хостинга. Практический предел pgvector — от 10 до 50 миллионов векторов на одном узле, после чего производительность начинает заметно деградировать из-за конкуренции за общий пул буферов и отсутствия нативной шардировки для векторных нагрузок.

Qdrant: король производительности

Qdrant, написанный на Rust, — это самый быстрый open-source движок векторного поиска на одном узле. Независимые бенчмарки 2026 года стабильно показывают p50 latency на уровне 2–4 миллисекунд и p99 latency в районе 12–18 миллисекунд на коллекции в 1–10 миллионов векторов. С бинарной квантизацией (Binary Quantization), представленной ещё в 2024 году, эти цифры падают до 1,2 миллисекунды p50 при сокращении потребления памяти в 32 раза — с 8,2 до 2,1 ГБ, при минимальной потере точности (с 0,987 до 0,961 Recall@10).

Главное конкурентное преимущество Qdrant — нативная фильтрация по payload. Большинство векторных БД применяют фильтры после ANN-поиска (post-filtering), что убивает recall при селективности фильтра ниже 1%. Qdrant использует payload-индексы для предварительной фильтрации: ANN-поиск выполняется только среди векторов, прошедших фильтр, что сохраняет качество ранжирования даже при жёстких multi-tenant ограничениях. На наборе из 10 миллионов векторов с фильтром, совпадающим с 1% записей, Qdrant оказывается в 3–5 раз быстрее Pinecone и Weaviate.

Версии Qdrant 1.17–1.18 (2026 год) добавили relevance feedback (обратная связь по релевантности для дообучения ранжирования на лету), TurboQuant — метод квантования из Google Research, снижающий размер векторов без дополнительной потери точности, GPU-индексацию в Qdrant Cloud и Multi-AZ репликацию. Qdrant Distributed, режим горизонтального масштабирования, расширяет предел до миллиардов векторов, хотя на текущий момент уступает Milvus в зрелости распределённой архитектуры.

Milvus: масштаб как архитектура

Milvus — это распределённая векторная база данных, спроектированная как set of loosely coupled microservices с самого начала. В 2026 году актуальна версия 2.6, которая устранила одну из главных операционных проблем — зависимость от Kafka/Pulsar, заменив их на встроенный Woodpecker WAL (Write-Ahead Log). Это радикально упростило архитектуру: исчез целый класс отказов, связанных с настройкой и мониторингом очередей сообщений. Однако стек всё ещё требует etcd, MinIO и отдельные типы узлов (Query Node, Index Node, Data Node, Coordinator).

Производительность Milvus раскрывается на объёмах от 100 миллионов векторов. GPU-ускоренная индексация через NVIDIA CAGRA строит HNSW-индекс на 100 миллионов векторов за минуты, а не часы, как у pgvector. Partition keys и Resource Groups позволяют гибко изолировать нагрузку разных команд или продуктов в рамках одного кластера. Zilliz Cloud — managed-версия Milvus — берёт на себя операционную сложность, но стоимость быстро растёт с объёмом данных. Milvus — это выбор для зрелых организаций с выделенной платформенной командой, которые оперируют сотнями миллионов векторов.

Сравнительное тестирование: что говорят бенчмарки 2026 года

Независимые бенчмарки 2026 года, проведённые на одинаковом оборудовании (AWS m6i.2xlarge, 8 vCPU, 32 ГБ RAM, gp3 SSD) с векторами размерности 768 (аналог OpenAI text-embedding-3-small), дают следующие результаты на коллекции в 1 миллион векторов:

| База данных | p50 (ms) | p95 (ms) | p99 (ms) | Recall@10 | RAM (ГБ) |

|---|---|---|---|---|---|

| Qdrant (HNSW) | 2,8 | 6,1 | 12,4 | 0,987 | 8,2 |

| Qdrant (BQ) | 1,2 | 3,4 | 7,1 | 0,961 | 2,1 |

| Milvus (HNSW) | 5,2 | 14,1 | 28,6 | 0,985 | 10,1 |

| Milvus (IVF_SQ8) | 3,8 | 9,5 | 19,2 | 0,952 | 4,8 |

| pgvector (HNSW) | 7,5 | 16,8 | 32,1 | 0,976 | 12,4 |

| Weaviate | 4,6 | 11,2 | 20,8 | 0,982 | 9,5 |

| Pinecone (serverless) | 7,8 | 17,5 | 33,2 | 0,979 | N/A |

Ключевой вывод: recall перестал быть дифференциатором. Все ведущие движки на HNSW показывают 97–99% при k=10. Разница в десятые доли процента не имеет значения для production RAG, где retrieval — лишь первый этап пайплайна, за которым следует reranker. Выбор векторной БД на основе recall в 2026 году — всё равно что выбирать ноутбук по критерию «может ли он запустить браузер». Настоящая битва идёт за latency, throughput и стоимость операции.

На 100 миллионах векторов картина меняется кардинально. pgvector на одном узле показывает p99 latency 58–85 миллисекунд (в 3–5 раз выше специализированных решений), а Qdrant и Milvus удерживают 18–25 миллисекунд. Qdrant на 3 узлах выдаёт 35 000 QPS при p99 latency 12 миллисекунд, Milvus на 5 узлах — 45 000 QPS при 15 миллисекундах. Разница в пропускной способности между pgvector и специализированными решениями на этом масштабе достигает 5–7×.

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

При выборе векторной БД нельзя игнорировать экономику. Сводные данные по стоимости на 10 миллионов векторов (1024-мерные, ~1K QPS, p99 < 100ms):

| Решение | Месячная стоимость | Тип |

|---|---|---|

| pgvector (self-hosted на PostgreSQL) | $1 000 – $2 000 | Размер инстанса |

| Qdrant (self-hosted) | $1 500 – $3 000 | Размер кластера |

| Qdrant Cloud | $9 – $500+ | От объёма |

| Milvus (self-hosted) | $2 000 – $4 000 | Кластер |

| Zilliz Cloud (Milvus managed) | $0 – $2 000+ | Free tier + usage |

| Pinecone Serverless | $2 000 – $5 000+ | Usage-based |

Важный нюанс: managed-сервисы часто показывают в pricing-страницах заниженную стоимость в 2,5–4 раза. Реальный счёт включает реплики для HA, egress-трафик, запас по пропускной способности и, в случае Pinecone, плату за запись. Self-hosted решения требуют инженерных часов на эксплуатацию, но при масштабах от 10 миллионов векторов их TCO (Total Cost of Ownership) почти всегда ниже managed-альтернатив.

RAG-пайплайн 2026: от векторов к ответам

Векторная база данных — лишь один компонент production RAG-системы. В 2026 году сформировался эталонный пайплайн, который используется в большинстве промышленных внедрений:

1. Подготовка данных. Документы парсятся в чистый Markdown (через Unstructured.io или LlamaParse для PDF), затем нарезаются на чанки. Рекомендуемый размер — 512–1024 токена с перекрытием 10–20%. Для точного фактологического поиска лучше 256–512 токенов, для аналитики — 1024–2048. Ключевая оптимизация 2026 года — parent-child chunking: маленькие чанки для точного поиска, но при генерации возвращается родительский чанк целиком для лучшего понимания контекста.

2. Контекстуальная вставка. Перед эмбеддингом каждого чанка к нему добавляется однопараграфный контекст, сгенерированный лёгкой моделью (Claude Haiku или GPT-4o-mini). Промпт: «Вот полный документ. Вот один чанк. Напиши контекст в 50–100 токенов, который помещает этот чанк в документ». Этот метод, представленный Anthropic в сентябре 2024 года, до сих пор остаётся недооценённым: он снижает количество неудачных извлечений на 49%, а в комбинации с reranker'ом — на 67%. Стоимость: примерно $1 за миллион токенов исходных документов — одноразовые инвестиции, которые окупаются сразу.

3. Гибридный поиск. Чистый векторный поиск считается антипаттерном для продакшна. Стандарт 2026 года — гибридный поиск: BM25 (лексический) и dense vector (семантический) запускаются параллельно, результаты объединяются через Reciprocal Rank Fusion (RRF) с константой k=60. BM25 отлавливает точные совпадения и идентификаторы, которые пропускает семантический поиск. Векторный поиск находит концептуальные соответствия, недоступные лексике. Вместе они покрывают оба failure mode. Большинство векторных БД — Qdrant, Milvus, Weaviate, Elasticsearch — поддерживают гибридный поиск нативно.

4. Переранжирование (Reranking). Cross-encoder reranker — это самое эффективное улучшение качества RAG по соотношению затрат и результата. После того как векторная БД вернула top-50–100 кандидатов, reranker переоценивает каждую пару «запрос-документ» с полным вниманием между токенами. Bi-encoder (эмбеддинговая модель) кодирует запрос и документ независимо, теряя нюансы совместного контекста. Cross-encoder видит их вместе — и даёт принципиально более точную оценку релевантности.

Лучшие open-source reranker'ы 2026 года: BGE-reranker-v2-m3 (30ms на GPU), Qwen3-Reranker (семейство от 0.5B до 8B параметров), Jina Reranker v2 для мультиязычных сценариев. Managed-решения: Cohere Rerank 3.5 (100ms, API). Добавление reranker'а повышает Recall@5 на 10–30 пунктов и сокращает контекст LLM на 60–80%, что снижает и задержку генерации (на 1–1.5 секунды), и стоимость токенов.

5. Генерация с цитированием. Финальный промпт содержит top-5 отранжированных чанков с обязательными ссылками на источники. Модель инструктируется цитировать каждый фактический тезис. Постпроцессинг через отдельный entailment-модель (или второй LLM-вызов) проверяет, что каждое утверждение в ответе действительно поддерживается одним из извлечённых чанков. RAGAS Faithfulness < 0,9 — красный флаг, требующий немедленного вмешательства в retrieval-пайплайн.

6. Оценка и observability. Автоматизированная оценка через RAGAS на золотом наборе из 50–100 пар «вопрос-ответ» с ground truth. Пороговые значения: Faithfulness > 0,9, Context Precision > 0,8, Answer Relevancy > 0,8. Production-трассировка: Phoenix или LangSmith для каждого запроса. Без eval'юна и live tracing production RAG-система — это демо, а не инфраструктура.

Фреймворк выбора: как принять решение

После анализа 47 enterprise-внедрений сформулировано простое эмпирическое правило, которое мы приводим как основной фреймворк:

Меньше 10 миллионов векторов: pgvector. Если ваша команда уже использует PostgreSQL, добавление pgvector — это CREATE EXTENSION vector;. Вы получаете ACID-транзакции, SQL-джойны, знакомую модель бекапов и мониторинга. pgvector не требует нового стека, новой команды и новой on-call-ротации. Ни один специализированный движок не окупит своей операционной стоимости на этом масштабе.

10–100 миллионов векторов: Qdrant. Когда датасет перерастает возможности одного PostgreSQL-узла или появляются тяжёлые фильтры по payload (multi-tenant RAG с тысячами клиентов, фильтрация по дате/типу документа/юрисдикции), Qdrant становится выбором по умолчанию. Rust-движок обеспечивает минимальную tail latency, payload-фильтрация без post-filtering — уникальное преимущество. Развёртывание: один бинарник, Docker-контейнер или Kubernetes-оператор.

Более 100 миллионов векторов: Milvus (или Qdrant Distributed). Для датасетов, исчисляемых сотнями миллионов векторов, нужна распределённая архитектура с горизонтальным шардированием. Milvus — наиболее зрелое решение с proven-историей на масштабах миллиардов векторов, GPU-индексацией и resource group isolation. Требует выделенной платформенной команды или managed-сервиса Zilliz Cloud.

Критична tail latency (агентные системы, real-time): Qdrant. Если ваша система делает 3–4 векторных поиска на один запрос пользователя (как в агентных архитектурах), tail latency каждого поиска суммируется. Qdrant с его 2–4 ms p50 против 5–8 ms у конкурентов даёт ощутимую разницу в пользовательском восприятии.

Максимум простоты (нулевой DevOps): Pinecone или Qdrant Cloud. Если у вас нет возможности администрировать ещё один сервис, managed-решения — правильный выбор. Pinecone Serverless — самое простое: никаких индексов, никаких нод, только API. Цена: в 3–4 раза выше self-hosted альтернатив на том же объёме данных. Qdrant Cloud — неплохая середина с бесплатным кластером на 1 ГБ.

Главный совет: стартуйте с pgvector, если вы на PostgreSQL. Мигрируйте на Qdrant при росте. Используйте Milvus только тогда, когда single-node решения действительно перестали справляться. Стоимость миграции с pgvector на Qdrant минимальна — экспорт данных через один SQL-запрос и смена клиента в коде. Эмбеддинги не меняются, API абстрагируется за единым интерфейсом. Стоимость преждевременной оптимизации — потерянные месяцы на эксплуатацию инфраструктуры, которая вам не нужна.

Заключение

Векторные базы данных в 2026 году перешли из категории «экспериментальных технологий» в категорию «зрелой инфраструктуры». Recall на HNSW-индексах сравнялся у всех ведущих движков, выбор перестал быть вопросом алгоритмов и стал вопросом операционной модели. pgvector даёт нулевую операционную стоимость для команд на PostgreSQL. Qdrant обеспечивает максимальную производительность на одном узле с уникальной payload-фильтрацией. Milvus открывает путь к миллиардам векторов ценой операционной сложности. Ни одно решение не является серебряной пулей, и это нормально — правильный выбор определяется вашим масштабом, командой и требованиями к latency.

FAQ

Можно ли использовать pgvector для production RAG с 10 миллионами векторов?

Да, и это наиболее частый сценарий. С HNSW-индексом и pgvectorscale StreamingDiskANN pgvector показывает конкурентную latency (8–18 ms p50) и 99% recall. Убедитесь, что векторный поиск выполняется на выделенной read-replica, чтобы не влиять на OLTP-нагрузку.

Qdrant или Milvus: что выбрать для стартапа?

Для стартапа — Qdrant. Он проще в развёртывании (один бинарник против etcd + MinIO + Kubernetes-оператора), дешевле (бесплатный кластер на 1 ГБ) и быстрее на масштабах до 100 миллионов векторов. Milvus — выбор зрелого enterprise с платформенной командой и датасетами от 100 миллионов векторов.

Нужен ли reranker, если векторный поиск и так работает хорошо?

Нужен. Reranker — самое эффективное улучшение качества RAG с точки зрения затрат. Он повышает Recall@5 на 10–30 пунктов и сокращает контекст LLM на 60–80%. Большинство production-систем без reranker'а упираются в плато качества на уровне 70–80% точности ответов.

Гибридный поиск — это маркетинг или необходимость?

Необходимость. Чистый семантический поиск пропускает точные термины и идентификаторы. Чистый BM25 пропускает парафразы. Гибрид (BM25 + dense + RRF) покрывает оба failure mode с минимальными затратами. В 2026 году это production baseline, а не опция.

Какую модель эмбеддингов использовать?

OpenAI text-embedding-3-large для общего случая, Cohere embed-v3 для мультиязычных сценариев, open-source (bge-large или e5-large-v2) для self-hosted сценариев с требованиями к приватности. Всегда используйте одну модель для документов и запросов — смешивание разрушает качество поиска.