Выбор векторной базы данных для RAG: сравнение pgvector, Pinecone, Qdrant, Weaviate и Milvus. Узнайте, какая БД подходит вам, и начните строить прямо сейчас.
Каждый туториал по RAG делает одно и то же. Он проводит вас через эмбеддинги, чанкинг, поиск, а затем, в самый ответственный момент, говорит: «теперь выберите векторную базу данных» — и просто переходит дальше. Как будто это решение уровня «выбрать шрифт». Это не так. База данных, которую вы выберете, определяет скорость запросов, затраты на инфраструктуру и то, насколько miserable станет ваша жизнь, когда трафик утроится. И вот что я понял, исследуя эту тему: база данных, с которой вы начинаете, часто не та, с которой вы выходите в продакшн. Команды мигрируют, иногда не по одному разу. Некоторые миграции — чистые победы; другие — недели боли и постмортем. Давайте попробуем избежать сожалений. Я потратил много времени, изучая бенчмарки, производственные отчёты и компромиссы, которые люди обнаруживают только постфактум. Это руководство, которое я хотел бы иметь, когда начинал: в чём каждая из этих пяти (pgvector, Pinecone, Qdrant, Weaviate и Milvus) действительно хороша, где каждая тихо проваливается и как выбрать, не утонув в матрице функций. Я испорчу концовку, потому что это самое полезное здесь: выбирайте на основе инфраструктуры, которую вы уже используете, а не на основе бенчмарка, который вы только что прочитали. Если вы уже на Postgres, ответ, вероятно, pgvector, и вы можете почти перестать читать. Если вы никогда не хотите касаться инфраструктуры — Pinecone. Всё остальное — тонкая настройка.
| Если это вы | Используйте | Суть |
|---|---|---|
| Уже на Postgres, менее ~50M векторов | pgvector | Одна база данных, ноль новых проблем |
| Хотите, чтобы всё работало «из коробки», готовы платить | Pinecone | Дайте им ключ, уходите |
| Хостите сами и одержимы скоростью | Qdrant | На Rust. Быстро. |
| Гибридный поиск — вся суть | Weaviate | Делал keyword + vector до того, как это стало модно |
| Движетесь к миллиарду векторов | Milvus | Построен для масштаба, который ломает всё остальное |
Я понимаю соблазн. Бенчмарки прямо здесь, с их красивыми столбчатыми диаграммами, и одна база данных на 3 мс быстрее другой — и это кажется решением. В основном — нет. В масштабе, в котором почти все реально работают, каждая база данных из этого списка достаточно быстра, чтобы пользователи никогда не почувствовали разницы. Война за задержки в основном ведётся за рабочие нагрузки, которых у вас пока нет. Что на самом деле решает выбор, в примерно таком порядке, это четыре скучных вопроса:
Ответьте на эти четыре вопроса честно — и база данных выберет себя сама. Вот каждая из них под этим углом.
pgvector — это не база данных. Это расширение Postgres. Вы учите базу данных, которая у вас уже есть, выполнять векторный поиск — и в этом весь трюк. Никакого нового сервиса. Никакого слоя синхронизации. Никаких ночных звонков от системы, которую вы настроили в спешке и так до конца не поняли.
Ваши векторы находятся рядом с вашими реальными данными, поэтому вы можете запрашивать их в одной транзакции, ваши существующие бэкапы уже их покрывают, а фильтрация — это просто SQL-предложение WHERE: JOIN, подзапросы — всё работает. Старая жалоба «Postgres слишком медленный для векторов» действительно устарела; она из эпохи IVFFlat. После появления индексации HNSW pgvector начал соответствовать выделенным базам данных на миллионе векторов, а с расширением pgvectorscale он уверенно держится и дальше, обеспечивая конкурентоспособную пропускную способность при 99% полноте на десятках миллионов векторов. Для огромной доли RAG-проектов это правильный ответ, и его единственный реальный недостаток — быть неинтересным.
При переходе за пару миллионов векторов на одной машине построение индекса начинает занимать более 20 минут, а процесс VACUUM в Postgres начинает конкурировать с запросами за ресурсы. Есть и более тонкая ловушка: pgvector фильтрует после поиска, поэтому строгий фильтр в большой коллекции означает сканирование кучи кандидатов, чтобы вернуть вам горстку. Где-то около 50-100 миллионов векторов вы начнёте задумываться о read-репликах, партиционировании или выходе.
вы на Postgres, менее ~50M векторов и вам не нужно выигрывать конкурс по задержке. Большинство команд именно такие и не осознают этого.
Pinecone по сути изобрёл категорию управляемых векторных баз данных и до сих пор задаёт в ней стандарт. Вы получаете API-ключ, создаёте индекс, кидаете в него векторы и запрашиваете их обратно. Не нужно ничего настраивать, ничего тюнинговать, ничего поддерживать. Это не список функций. Это вся суть, и она действительно хороша.
«Мне нужна векторная база данных, и я отказываюсь думать об этом дальше» — это абсолютно легитимная позиция, и Pinecone создан именно для такого человека. Он масштабируется до миллиардов векторов, поддерживает гибридный поиск, имеет корпоративные чекбоксы комплаенса. Вы перекладываете всю операционную головную боль на того, чья работа — поддерживать его в рабочем состоянии.
Это закрытый исходный код, и самохостинг невозможен, точка. Ваши данные живут в их облаке, и если их цены изменятся или у них будет плохой день, у вас нет плана Б. Serverless-уровень меняет задержку на удобство и фиксирует полноту на уровне около 90% без возможности регулировки. Pinecone просто не позволяет вам трогать внутренности HNSW. Записи в конечном счёте согласованы, поэтому свежедобавленные векторы появляются с задержкой. Фильтрация слабее SQL (нет JOIN, подзапросов), поэтому всё, что выходит за рамки простого, перекладывается в код приложения. И счёт растёт вместе с вами, иногда быстрее, чем хотелось бы.
отсутствие управления инфраструктурой для вас важнее контроля над настройками, и вы смирились с lock-in как с ценой за то, чтобы больше никогда об этом не думать.
Qdrant — это open-source, написан на Rust и с самого начала создан для векторного поиска и ничего больше. Эта фокусировка заметна.
Он лидер по скорости среди open-source решений, с самой низкой задержкой p50, и разрыв увеличивается под высокой нагрузкой запросов, где это наиболее важно. Но настоящая фишка — фильтрованный поиск: Qdrant выполняет фильтры внутри обхода поиска, а не добавляет их после, поэтому запрос «найди похожие туфли, но только красные в наличии», который заставляет pgvector потеть, здесь остаётся быстрым. Добавьте бинарное квантование, которое может значительно сократить память, а также новые облачные функции, такие как GPU-ускоренное индексирование и multi-AZ отказоустойчивость, и вы получите много базы данных за свои деньги. Бесплатный уровень — самый щедрый в этом списке.
Экосистема моложе. Вы найдёте меньше тредов на Stack Overflow в полночь, меньше случайных блог-постов, которые решают вашу точную проблему. Хотя LangChain и LlamaIndex поддерживают его нормально, так что вы не в глуши. Некоторые команды сообщали о проблемах при очень высоких конкурентных записях, поэтому если вы пишете с высокой интенсивностью, протестируйте это специально перед принятием решения.
вы с радостью управляете собственной инфраструктурой, хотите лучшую производительность за рубль и быстрый фильтрованный поиск является ключевым для вашего продукта.
Weaviate тоже open-source, но он играет в другую игру. Он не просто хочет хранить ваши векторы — он хочет быть основой всего вашего AI-пайплайна.
Две причины. Первая — гибридный поиск, который Weaviate запустил ещё в конце 2022 года, задолго до того, как большинство подхватило. Его реализация действительно зрелая (правильное слияние keyword-оценки с векторными результатами), поэтому если смешивание семантического и точного поиска является ключевым для вашего продукта, это самый взрослый нативный вариант. Вторая — он сам делает эмбеддинги: отправьте сырой текст, и Weaviate векторизует его на входе, используя OpenAI, Cohere, Hugging Face — что угодно. Меньше движущихся частей в пайплайне — это реальное улучшение качества жизни.
Встроенные векторизаторы не бесплатны. Они вызывают те же API эмбеддингов, которые вы бы вызывали сами, так что вы платите эту задержку и стоимость, просто в менее заметном месте. GraphQL API — это настоящая кривая обучения, если ваш мозг заточен под SQL или обычный REST. А Java-рантайм прожорлив при самохостинге; операционная сложность растёт по мере добавления модулей и мультитенантности.
нативный гибридный поиск — жёсткое требование, или вы действительно хотите, чтобы база данных обрабатывала векторизацию, чтобы в вашем пайплайне было меньше частей, которые могут сломаться.
Milvus — самый звёздный open-source вариант на GitHub, поддерживаемый Zilliz (чей управляемый Zilliz Cloud — прокачанная корпоративная версия). Он существует по одной причине: масштаб, который заставляет всё остальное падать.
Ничто другое здесь не сравнится с его распределённой архитектурой, когда вы действительно большие. Движетесь к миллиарду векторов? Нужно GPU-ускоренное индексирование? Это инструмент, созданный для такого дня. В диапазоне 100M+ он серьёзный кандидат, точка.
Это много машин. Операционная сложность превышает Qdrant для обычных случаев. Закладывайте реальное инженерное время на укрощение Kubernetes и готовьте команду к кривой обучения. Есть также известный подводный камень с производительностью, связанный с полями вывода, который может проявиться в RAG-пайплайнах. Если у вас меньше нескольких десятков миллионов векторов, Milvus почти наверняка избыточен для вашей задачи.
вы действительно движетесь в территорию 100M-1B+ или вам нужно распределённое GPU-индексирование, и у вас есть возможности для администрирования.
ChromaDB заслуживает почётного упоминания. Он работает прямо внутри вашего Python-процесса без конфигурации и отлично подходит для прототипирования. Просто у него нет продакшн-инструментов (высокая доступность, снапшоты, реальный мониторинг), как у большой пятёрки, так что думайте о нём как о стартовой точке, а не как о конечной. Faiss (библиотека, а не база данных), LanceDB (мультимодальный), Vespa и облачные управляемые варианты вроде Vertex Vector дополняют широкое поле, но пять выше — это те, о которых люди действительно спорят в продакшн-слаках.
Вот он, потому что он тихо определяет больше решений, чем ожидают. Чистый векторный поиск прекрасен ровно до тех пор, пока кто-то не ищет точный SKU, имя человека или «v2.3.1», и вдруг ваши прекрасные семантические эмбеддинги возвращают что-то тематически близкое, но бесполезное. Реальным системам нужно и то и другое: нечёткое семантическое совпадение и точное ключевое слово в одном запросе. Weaviate и Qdrant предоставляют это нативно. Pinecone добавил это позже. pgvector заставляет вас собирать это вручную. Если вы строите память агента или RAG над разнородным контентом, считайте гибридный поиск обязательным и позвольте ему склонить чашу весов. Это уже не «приятно иметь»; это базовый стандарт, маскирующийся под дифференциатор.
Если вы вынесете отсюда одну вещь: вы на Postgres и у вас менее ~50M векторов? Используйте pgvector и идите строить. Прекратите читать и начните делать. Если вы никогда не хотите касаться инфраструктуры — Pinecone. Если вы хотите максимальную производительность за свои деньги и готовы администрировать — Qdrant. Если гибридный поиск — ваше всё — Weaviate. Если вы целитесь в миллиарды векторов — Milvus. А теперь идите и стройте.
Хочешь закрепить знания на практике?
Решай задачи на Algolit — интерактивная платформа для обучения
Начать бесплатно →