RAG: pgvector, Qdrant, Weaviate, Pinecone - какую векторную базу брать в 2026

Все носятся с выбором модели и эмбеддингов, а векторную базу выбирают «на глаз» — и потом полгода с ней мучаются. А зря: именно она в RAG-системе чаще всего становится точкой, где у вас неожиданно вырастает счёт, ломается latency или появляется второй сервис, который некому поддерживать.

В большинстве RAG-пайплайнов основной счёт — это токены LLM, а векторная база — копеечная строчка в смете. Пока вы не вышли на серьёзный масштаб и высокий QPS, переоптимизировать выбор базы — значит экономить на спичках. Поэтому правильный вопрос не «что масштабируется до миллиарда векторов», а «что закроет мою задачу с минимумом боли прямо сейчас».

Больше про LLM и AI — в нашем Telegram-канале (@devgeek_sh). Разбираем новые модели, делимся опытом и полезными находками.

Рынок к 2026-му устаканился. По оценке Gartner, векторные базы используют уже около 78% корпоративных ИИ-команд, а IDC оценивает рынок в ~$3,2 млрд на 2026 год. Из десятков движков в продакшене реально доминируют четыре, и у каждого — своя философия.

Четыре разные философии, а не четыре одинаковых базы

Они не конкурируют «лоб в лоб» — они отвечают на разные вопросы.

pgvector — это не отдельная база, а расширение PostgreSQL. Векторы лежат в той же таблице, что и остальные данные. Никакого нового сервиса, никакой синхронизации, всё тот же SQL и те же транзакции.

Qdrant — специализированная векторная база на Rust, заточенная под одно: быстро искать по векторам и фильтровать. Отдельный сервис, максимум производительности на вложенный доллар.

Weaviate — векторная база на Go с богатой обвязкой: нативный гибридный поиск, мультитенантность, модули векторизации и GraphQL поверх всего.

Pinecone — полностью управляемый serverless. Вы вообще ничего не админите: ни нод, ни индексов, ни шардов. Платите за использование. Простота операционки — за деньги.

Дальше — по каждому подробно

pgvector: «просто добавь векторы в свой Postgres»

Если ваш источник правды и так в PostgreSQL — это путь по умолчанию. Установка занимает буквально одну строку, и у вас уже есть векторный поиск рядом со всеми остальными данными:

SQL

Вот и всё. Никакого второго сервиса, никакой логики синхронизации, ноль новых движущихся частей. Вы делаете векторный поиск и тут же джойните его с реляционными данными, накладываете SQL-фильтры через обычный WHERE, опираетесь на привычную репликацию и зрелую операционную тулзу. Для команды, которая уже живёт на Postgres, это огромная экономия нервов.

Производительность начинает проседать примерно после 10 млн векторов на «голом» pgvector. С pgvectorscale планка сдвигается до 50–100 млн — и тут есть приятный сюрприз: на 50 млн векторов pgvectorscale выдаёт около 471 QPS при 99% recall, что на порядок выше, чем у некоторых специализированных движков в той же точке. Но есть нюанс: построение индекса у pgvectorscale пока однопоточное (команда Timescale работает над параллелизацией), так что на больших объёмах индексирование может быть медленным. И базовая модель масштабирования — вертикальная, в один узел. Это часто предсказуемее и проще, но это не горизонтальный масштаб «из коробки».

Кому. Вы уже на Postgres, у вас до ~10 млн векторов (или до ~50–100 млн с pgvectorscale), вам нужны ACID, джойны и один стек вместо двух. Для огромной доли реальных проектов этого хватает за глаза.

Qdrant: чемпион по сырой скорости и цене

Qdrant написан на Rust и с самого начала проектировался под векторные нагрузки. Это видно по цифрам: на воспроизводимых тестах ANN-Benchmarks он выдаёт около 1840 QPS на миллионе векторов — самый высокий результат среди четвёрки. Движок использует HNSW с SIMD-ускорением и в пересчёте на доллар даёт примерно в 3–5 раз больше пропускной способности на масштабе, чем pgvector.

Две вещи, за которые Qdrant реально любят. Первая — фильтрация. Здесь она first-class: filterable HNSW и payload-индексы означают, что поиск остаётся быстрым, даже когда вы навешиваете несколько фильтров поверх векторного сходства («найди похожее на это изображение, но только размер 10 и в наличии»). Под частые фильтры Qdrant прямо советует строить payload-индексы. Вторая — квантизация. Scalar, product и binary: память ужимается в 4–40 раз, а скорость даже растёт. На одном и том же датасете HNSW со скалярной квантизацией у Qdrant ест примерно на 65% меньше памяти, чем IVFFlat у pgvector. Для memory-constrained деплоев это решающий аргумент.

Лицензия — Apache 2.0, запускается где угодно. Free tier — щедрый: 1 ГБ навсегда. Self-host на небольшом VPS ($30–50/мес) тянет миллионы векторов; в облаке на CPU-инстансе — порядка $0,40/час.

Экосистема меньше, чем у Pinecone или Weaviate: интеграции с LangChain и LlamaIndex есть, документация добротная, но Stack Overflow-ответов, постов и готовых примеров заметно меньше — гуглить решения сложнее. И при очень высоком объёме записи под нагрузкой бывают вопросы с конкурентными апдейтами — зависит от конфигурации и железа. Для read-heavy и умеренной записи держится отлично; если вы постоянно и массово переписываете векторы, проверьте поведение на своём профиле нагрузки.

Кому. Нужна максимальная производительность и лучшее соотношение цена/скорость, важна продвинутая фильтрация и квантизация, любите open-source и готовы держать отдельный сервис.

Weaviate: гибридный поиск и мультитенантность из коробки

Weaviate (на Go) — это про «больше, чем просто хранилище векторов». Его главный козырь в 2026-м — гибридный поиск: нативный BM25, который комбинирует векторное сходство с keyword-матчингом в одном запросе, причём за keyword-индексы не доплачиваешь хранилищем. Для большинства RAG-задач именно гибрид заметно поднимает recall — чистого вектора часто мало, особенно на точных терминах, артикулах и именах собственных.

Второй сильный сценарий — мультитенантность. Если вы строите SaaS, где у каждого клиента своя изолированная коллекция, Weaviate спроектирован под это. Плюс встроенные модули векторизации (OpenAI, Cohere, Hugging Face): можно класть сырой текст, а эмбеддинги Weaviate посчитает сам. И GraphQL-интерфейс поверх всего.

По деньгам: self-host бесплатно, а Weaviate Cloud стартует от $25/мес — это самый дешёвый входной тариф среди управляемых решений «большой четвёрки».

За богатство платишь сложностью: схема, модули, конфигурация — порог входа выше, чем «CREATE EXTENSION». На умеренном масштабе облако выходит дороже Qdrant и pgvector. И это всё-таки отдельный сервис со своей операционной поверхностью.

Кому. Нужен сильный гибридный поиск и/или строгая мультитенантность, хочется выбор «self-host или managed», и вы готовы вложиться в настройку ради функциональности.

Pinecone: платишь за то, чтобы ничего не админить

Pinecone — единственный в подборке полностью проприетарный и managed-only. И это его суть: вы не поднимаете ноды, не думаете про шарды и индексы, не дежурите по ночам. Serverless v2 (Q1 2026) ещё снизил latency и улучшил экономику. Самый быстрый путь до прода — без вопросов.

Раньше Pinecone ругали за дорогую pod-модель; serverless (с 2024) это починил — теперь платите за потребление. Гибридный поиск поддерживается через sparse-векторы (SPLADE), есть нативная компрессия (сжатие в 4–6 раз). Free tier на старте — 2 ГБ и 5 индексов, для прототипа хватает.

А вот теперь — про деньги, потому что здесь главная ловушка. Биллинг serverless состоит из трёх частей: хранилище $0,33/ГБ в месяц, чтение $8,25 за миллион read units, запись $2 за миллион write units. Звучит дёшево — пока вы не посчитаете read units. Один запрос с метадата-фильтрацией стоит не 1 read unit, а 5–10. На миллионе запросов в день это уже $250–500/мес только на чтении. А агентские, write-heavy нагрузки и вовсе ломают модель, которая заточена под read-heavy RAG: реальные счета у таких команд бывают в 3–5 раз выше прикидок из калькулятора. Не зря отдельные аналитики прямо отмечают: pricing-страницы всех вендоров занижают итог в среднем в 2,5–4 раза против фактического счёта в проде. У Pinecone это чувствуется острее всего, потому что считать заранее тяжелее.

Кому. Хотите ноль операционки, нужно максимально быстро в прод, бюджет предсказуемый и нагрузка скорее read-heavy, чем агентская-write-heavy.

Обзор

Если не хочется читать всё — короткая логика выбора:

Уже на Postgres, до ~10 млн векторов, нужны SQL/ACID и один стек — берите pgvector. Это самый дешёвый по нервам старт, и для большинства проектов он не «временное решение», а вполне финальное.

Нужен ноль операционки и максимально быстро в прод, бюджет предсказуемый, нагрузка read-heavy — Pinecone. Только заранее посчитайте read units и держите в уме, что агентские write-heavy сценарии ломают его экономику.

Главное — гибридный поиск и/или мультитенантность для SaaS — Weaviate. Нативный BM25 и изоляция тенантов — его родная территория.

Нужна максимальная скорость на доллар, продвинутая фильтрация и квантизация, любите open-source — Qdrant. Лучший выбор, когда производительность и контроль важнее размера экосистемы.

И самый практичный паттерн, который выбирают команды, реально катящие RAG: начните на pgvector для v1 (вы в проде за пару недель), мониторьте latency и стоимость — и мигрируйте на Qdrant/Weaviate/Pinecone тогда, когда нагрузка этого реально потребует. Миграция почти всегда дешевле, чем недели на выбор «идеального» движка заранее. Исключение одно: если вы уже на старте точно знаете, что масштаб, гибридный поиск или строгая мультитенантность — это must-have, берите специализированный движок сразу и примите более высокий операционный порог.

Больше про LLM и AI — в нашем Telegram-канале (@devgeek_sh). Разбираем новые модели, делимся опытом и полезными находками.