pgvector 0.7 vs Weaviate в продакшне: как мы выбирали векторное хранилище под RAG для двух разных клиентов

Два проекта, обе задачи - RAG-пайплайн поверх корпоративной базы знаний, обе в продакшне с реальными пользователями. И при этом разные векторные хранилища. Не потому что мы любим разнообразие ради разнообразия, а потому что требования у заказчиков оказались принципиально разные. Записываем, чтобы в следующий раз не начинать анализ с чистого листа.

Первый кейс: pgvector 0.7 закрыл задачу

Заказчик - средний производственный холдинг, несколько тысяч внутренних документов: регламенты, технические нормативы, инструкции. Нужен поиск с ответом на естественный вопрос. Concurrency небольшой - десятки одновременных пользователей в пике, не сотни.

Инфраструктурно у них уже работает PostgreSQL 16 на Postgres Pro, к нему привыкли, есть команда, умеющая его обслуживать. Добавлять новый stateful-сервис в стек они не хотели - каждый новый сервис означает отдельный контур резервного копирования, мониторинг, дежурство.

pgvector 0.7 принёс две существенных вещи относительно 0.5/0.6: HNSW-индексы стали стабильными в продакшне и появился halfvec - хранение векторов в float16 вместо float32. Для 768-мерных эмбеддингов (мы использовали sentence-transformers с моделью размерностью 768) это в два раза меньший объём индекса.

Тест на их данных: поисковый запрос по коллекции ~50 тыс. чанков с HNSW-индексом (m=16, ef_construction=64) выдавал top-10 примерно за 15-25 мс на нагрузке в 20-30 одновременных запросов. Для их сценария - поисковый ассистент, где пользователь ждёт ответа LLM в любом случае - это более чем достаточно.

Итоговый стек получился плоским: Postgres + pgvector + pgBouncer + приложение. Никакого нового оператора, никаких отдельных бекапов для векторной базы. Команда заказчика понимает, что происходит - это дорогого стоит.

Второй кейс: почему pgvector не подошёл

Второй заказчик - сервисная компания, живые операторы, у каждого в браузере открыт RAG-ассистент. Обращений - несколько сотен в минуту в прайм-тайм, коллекция около 2 млн чанков и растёт, потому что документооборот активный. И главное - нужна multi-tenancy на уровне хранилища: у разных клиентских сегментов разные базы знаний, данные нельзя смешивать даже в индексе.

Здесь pgvector начал вызывать вопросы. Не потому что медленный - HNSW работает - а потому что:

• Multi-tenancy через схемы или отдельные таблицы в Postgres с сотнями тенантов превращается в головную боль при обслуживании индексов. VACUUM и REINDEX на 300 таблицах с векторами - это не то, чем хочется заниматься.
• Horizontal sharding pgvector в PostgreSQL не предусмотрен нативно. Можно Citus, но это отдельная история сложности.
• Динамическое изменение коллекций - у заказчика документы добавляются и удаляются постоянно, а HNSW-индекс в pgvector при массовых обновлениях требует периодического REINDEX для поддержания качества.

Weaviate в конфигурации v1.25 закрыл эти проблемы. Multi-tenancy там первоклассная фича: каждый тенант изолирован, индекс отдельный, можно ставить тенантов в режим cold (lazy load) если неактивны - экономия памяти. Горизонтальное масштабирование через sharding работает без плясок. HNSW с динамическими обновлениями - это то, что Weaviate оптимизировал специально: векторы добавляются в живой индекс без полной перестройки.

Операционно, правда, стало сложнее: добавился stateful-сервис с собственным lifecycle, с бекапом через S3-snapshots, с Kubernetes-оператором, который иногда ведёт себя неожиданно при rolling update. Это не катастрофа, но это реальная стоимость.

Что получается в сухом остатке

Не существует критерия «pgvector хуже специализированной базы» или наоборот. Критерии выбора в нашем опыте выглядят так:

• Коллекция до нескольких сотен тысяч чанков, concurrency умеренный, Postgres уже в стеке - pgvector 0.7 с HNSW закрывает задачу. Проще, дешевле, меньше движущихся частей.
• Multi-tenancy с изоляцией на уровне индекса - специализированное решение. Weaviate, Qdrant, Milvus - смотрите по удобству API и вашему стеку, но pgvector тут не первый кандидат.
• Коллекция растёт быстро, данные меняются часто - тоже в пользу специализированного решения: у них динамические индексы проработаны глубже.
• Команда умеет Postgres и не умеет ничего другого - это тоже аргумент, и весомый. Инструмент, который никто не понимает, в 3 часа ночи становится проблемой.

Одна вещь, которая нас немного удивила: разрыв в latency между pgvector и Weaviate на сопоставимых условиях оказался меньше, чем ожидали. На коллекции до 100k векторов они практически неотличимы на глаз пользователя. Разница проявляется не в скорости одного запроса, а в поведении под нагрузкой и в управляемости при масштабировании.

Мы работали с инференсом в этих же проектах - про то, как выглядит GPU-инфраструктура под LLM, писали отдельно. Векторная база - один из элементов пайплайна, и выбирать её нужно в контексте всей системы, а не как отдельный benchmark.