Когда я начал строить первый RAG-пайплайн, потратил, наверное, дня три на выбор векторной базы. Открывал документацию, читал бенчмарки, закрывал. Потом снова открывал. В итоге поставил Pinecone — потому что о нём громче всех говорили на YouTube. Примерно через месяц понял, что выбор был, мягко говоря, неоптимальным для моей задачи.
Этот разбор — не про то, какая база «лучшая». Их не существует. Про то, как я разобрался в разнице между тремя самыми популярными вариантами и когда что имеет смысл.
Pinecone: когда хочешь просто чтобы работало
Pinecone — это полностью управляемый облачный сервис. Никакой инфраструктуры, никакого деплоя, API-ключ и поехал.
Я начал с него именно поэтому. Регистрируешься, создаёшь индекс, указываешь размерность векторов — и через минуту можно делать upsert и query. Для прототипа это идеально. За пару часов у меня уже работал семантический поиск по документам, и я чувствовал себя продуктивным.
Проблема обнаружилась позже. У Pinecone закрытый движок — ты не знаешь, что происходит внутри. Гибкость в фильтрации метаданных ограничена. А главное: free tier с лимитом в 100 тысяч векторов заканчивается быстрее, чем думаешь, и дальше счёт начинает расти. Для небольшого пет-проекта с реальными данными я уже за месяц уткнулся в лимит.
Ещё одна вещь, которую я недооценил: vendor lock-in. Данные лежат у них, API только их. Если завтра они поднимут цены или ляжет сервис — ты в заложниках. Для хобби-проекта это терпимо, для продакшна я бы думал дважды.
Короче: Pinecone хорош для быстрого старта и демо. Для серьёзного проекта с большим объёмом данных или требованиями к контролю — уже вопрос.
Weaviate: когда данные сложнее, чем просто векторы
После Pinecone я попробовал Weaviate — и первое впечатление было странным. Там своя схема объектов, свой GraphQL API, своя концепция «классов». Я привык к тому, что векторная база — это просто индекс. Weaviate хочет быть чем-то вроде базы знаний.
Зато когда врубился — понял, зачем это нужно.
В Weaviate каждый объект хранится вместе с метаданными, и фильтровать можно по чему угодно до или после векторного поиска. Плюс там есть встроенные модули: подключаешь OpenAI или Cohere прямо внутри базы, и она сама векторизует текст при записи. Не нужно гонять данные туда-сюда через отдельный embedding-сервис.
Я поднял Weaviate локально через Docker — это заняло минут десять. Self-hosted вариант бесплатный, и это меняет расчёты. Для проекта с парой миллионов чанков разница в стоимости между «платить Pinecone» и «запустить Weaviate на своём сервере» становится очень заметной.
Слабое место — порог входа. Документация хорошая, но объёмная. GraphQL для запросов — на любителя. И если ты привык к простому k-NN поиску через REST, первые часы с Weaviate чувствуешь себя немного потерянным.
Ещё Weaviate поддерживает гибридный поиск: комбинирует векторный поиск с BM25 (классический keyword search) в одном запросе. Для RAG это реально полезно — чисто семантический поиск иногда промахивается по точным терминам и аббревиатурам, а гибрид это компенсирует. Я проверил на своих данных — результаты заметно улучшились.
pgvector: когда у тебя уже есть PostgreSQL
Это тот вариант, который я в итоге использую для большинства задач. И о котором узнал последним — а надо было с него начинать.
pgvector — расширение для PostgreSQL. Добавляет тип данных vector и несколько операторов для поиска по косинусному сходству или евклидову расстоянию. Примерно так:
SELECT id, content
FROM documents
ORDER BY embedding <=> '[0.1, 0.2, ...]'
LIMIT 5;
Вот и весь «специализированный» инструмент.
Красота в том, что если у тебя уже стоит Postgres — ты просто делаешь CREATE EXTENSION vector и всё. Векторы живут в обычной таблице рядом с остальными данными. Фильтруешь через обычный WHERE. Джойнишь с любыми другими таблицами. Транзакции работают как обычно. Никакой синхронизации между двумя базами.
Я переехал на pgvector после того, как устал поддерживать два источника данных: Postgres для основных данных и Pinecone для векторов. Когда запись в одном не совпадала с другим — начиналась головная боль. С pgvector это просто одна таблица.
Честный минус: производительность на больших объёмах. Pinecone и Weaviate построены специально для ANN-поиска и на миллионах векторов работают быстрее. pgvector с индексом HNSW тоже неплохой, но если у тебя реально десятки миллионов векторов и запросы идут в реальном времени — специализированное решение выиграет. Для большинства же задач, где векторов до пары миллионов и запросы не каждую миллисекунду — pgvector справляется без вопросов.
Как я теперь выбираю
После всех экспериментов у меня выработалась грубая эвристика.
Прототип или демо, хочу поднять за день — Pinecone. Не думаю об инфраструктуре, сразу проверяю гипотезу.
Проект серьёзный, данные сложные, нужен гибридный поиск или хочу self-hosted без vendor lock-in — смотрю на Weaviate. Особенно если объём данных такой, что платить за Pinecone будет больно.
Уже есть Postgres и объём разумный — pgvector. Просто потому, что меньше движущихся частей. Один бэкап, одно подключение, одна точка отказа вместо двух.
На больших масштабах с реально высокой нагрузкой — отдельный разговор, там нужны бенчмарки под конкретную задачу.
Главное, что я понял: выбор векторной базы — это на 80% вопрос о том, что у тебя уже есть и чем ты готов управлять, и только на 20% о технических характеристиках. Pinecone продаётся как «просто работает», и это правда — но это правда с ценой. Weaviate даёт гибкость, но требует вникания. pgvector не требует почти ничего, если Postgres уже в стеке.
Я сейчас на pgvector плюс иногда Weaviate — для проектов, где нужен гибридный поиск. Pinecone больше не использую — не потому что плохой, а просто незачем платить за управляемый сервис, когда мои задачи решаются дешевле.
