Полгода назад я загрузил 10 миллионов эмбеддингов в Weaviate на своём ноутбуке. Коллапс. Docker-контейнер сожрал 28 гигов оперативы, запросы по 800 мс, а я сидел и думал — где именно я свернул не туда.
Знакомая история для любого, кто впервые берётся за векторные базы данных. Три системы, о которых все говорят — pgvector, Pinecone и Weaviate. На бумаге у каждой свои плюсы. В реальности есть подводные камни, которые всплывают только под нагрузкой.
Я походил по граблям на всех трёх. Делюсь что понял.
Почему вообще всё это нужно
Когда у тебя обычная база данных и ты ищешь «близкие» записи — ты используешь точное совпадение или диапазон. Векторные базы решают другую задачу: поиск по смыслу. Берёшь текст, пропускаешь через эмбеддинг-модель, получаешь набор чисел, который отражает смысл. А потом ищешь другие такие наборы, которые «близки» к твоему.
Всё это работает для semantic search, RAG-систем, рекомендаций, поиска изображений. Вот почему все помешались на этой теме.
pgvector: дерзость встроить вектора в PostgreSQL
Идея простая: зачем вам отдельная инфраструктура, если у вас уже есть Postgres? Поставили расширение, создали индекс — и поехали.
На практике это выглядит так. У меня был проект с 2 миллионами товарных описаний. Добавил колонку embedding vector(1536), создал HNSW-индекс. Первый поиск по смыслу с pgvector ivfflat занял 4 мс. После перехода на HNSW — 1.2 мс. А без индекса — 380 мс.
Что понравилось:
- Одна база вместо двух. Не нужно синхронизировать данные между Postgres и отдельным векторным хранилищем. Запрос на джойн данных и поиск по векторам — один SQL-запрос.
- Зрелость PostgreSQL. Резервное копирование, репликация, мониторинг — всё это уже есть. Не нужно изобретать велосипед.
- Никаких дополнительных сервисов. Для стартапа или MVP — идеально.
Что сломало мне мозг:
- Память. HNSW-индекс на 2 млн vectors(1536) занял 14 гигов. Не то чтобы много, но и не мало. На маломощных машинах приходится уменьшать
mиef_constructionпараметры — и терять в качестве поиска. - Фильтрация. Если нужно искать «близкие вектора» внутри определённой категории — это работает, но скорость падает драматически. pre-filtering в pgvector не оптимизирован так хорошо, как в специализированных решениях.
- Обновления. HNSW-индексы в pgvector не поддерживают инкрементальные обновления. Обновил 5% векторов — перестраивай индекс целиком.
Для проекта до 5–10 миллионов векторов с простой структурой pgvector — отличный выбор. Особенно если у вас уже есть Postgres и не хочется плодить сущности.
Pinecone: облако, которое просто работает
Pinecone — это managed-сервис. Загружаешь данные через API, платишь за инфраструктуру, а они занимаются масштабированием.
Я использовал Pinecone для проекта с RAG-системой. 50 миллионов чанков документации. Начинал с serverless tier, потом перешёл на pod-based, потому что serverless не умеет в real-time updates.
Что в Pinecone хорошего:
- Скорость стабильна. 15–40 мс на запрос практически при любом объёме данных. Не магия — просто у них хорошо оптимизирована инфраструктура.
- Metadata filtering работает прилично. Можно искать по векторам и одновременно фильтровать по полю
category = "legal". Запросы остаются быстрыми. - Не нужно думать об инфраструктуре. Создал namespace, загрузил данные — и забыл.
Что раздражало:
- Цена. Serverless tier кажется дешёвым, пока не упрёшься в лимиты. Pod-based с репликацией и несколькими индексами легко выходит в несколько сотен долларов в месяц. Для большого стартапа это не вопрос, для своего пет-проекта — ощутимо.
- Vendor lock-in. Вы не контролируете ничего. Если Pinecone изменит ценообразование или сломается API — вы адаптируетесь. Не теоретический риск, а практический момент.
- Debugging. Когда запрос тормозит — доступа к метрикам индекса нет. Видишь latency на своей стороне и гадаешь, виноват ли Pinecone или твой код.
Pinecone — правильный выбор, когда нужен результат без операционной головной боли. Если у вас команда и бюджет — берёте и используете.
Weaviate: мощь и контроль
Weaviate — специализированная векторная база с открытым исходным кодом. Можно поставить на своём сервере, можно через их облако.
Я начинал с self-hosted Weaviate. Docker, один файл docker-compose — и у тебя работающая векторная база. Это привлекает.
Что в Weaviate интересного:
- Гибридный поиск. Можно одновременно искать по векторам и по ключевым словам. Называется BM25 + vector hybrid search. Для задач, где важны и смысл, и точные термины — это решает.
- Модули. Weaviate умеет генерировать эмбеддинги прямо на лету через интеграции с OpenAI, Cohere, HuggingFace. Не нужно отдельно готовить вектора.
- GraphQL API. Необычно для векторных баз, но гибко.
Вот только есть нюанс. Поставил Weaviate на сервере с 32 гигами RAM, загрузил тестовый датасет в 3 миллиона векторов. Через 20 минут понял, что что-то не так. Weaviate по умолчанию жрёт память агрессивно. Пришлось перенастраивать PERSISTENCE_DATA_PATH, LIMIT_ADMIN_MEMORY, играться с _vectorIndexConfig.
После настройки стало лучше, но осадочек остался. Weaviate требует больше внимания к конфигурации, чем pgvector.
Репликация и шардирование поддерживаются из коробки — для масштабирования это плюс. Но заставить это работать стабильно — отдельная задача.
Weaviate хорош, когда нужен гибридный поиск и вы готовы разбираться в настройках.
Сравнение, которое реально полезно
Вместо таблицы «features vs features» — практическая шпаргалка.
До 5 миллионов векторов и уже есть Postgres — ставьте pgvector. Сэкономите время и деньги. Качество поиска при правильной настройке HNSW будет достаточным для 95% задач.
Важна скорость и есть бюджет — Pinecone. Не будете тратить дни на оптимизацию индексов. За эти деньги вы покупаете своё время.
Нужен гибридный поиск и готовы вкладываться в DevOps — смотрите на Weaviate. Или Qdrant, кстати, который в некоторых сценариях работает быстрее.
Что я выбрал для себя
Для своих проектов остановился на связке: основные данные в Postgres с pgvector, а для тяжёлых RAG-задач — отдельный инстанс Qdrant. Qdrant не упомянут в заголовке, но за полгода я убедился, что по соотношению скорость/простота он часто обходит Weaviate.
Главное, что я усвоил: векторная база — это не магия. Это инструмент с конкретными компромиссами по памяти, скорости и операционным затратам. Выбирайте исходя из своих ограничений, а не из хайпа.
На прошлой неделе коллега спросил: «Какую векторную базу выбрать для стартапа?» Я ответил: «Сначала поймите, сколько у вас данных и кто будет это обслуживать. Ответ изменится в зависимости от ответа». Он посмотрел на меня как на идиота. Наверное, слишком очевидный совет.
