pgvector 0.8 vs отдельные векторные базы: когда Postgres достаточно для RAG

Когда в апреле мы переводили RAG-ассистент на корпоративной wiki в прод, вопрос про векторное хранилище решили быстро: взяли pgvector, потому что Postgres уже стоял и нагрузки были понятные. С тех пор к нам приходило несколько клиентов с похожим вопросом - «мы хотим RAG, какую векторную базу взять?» - и ответы каждый раз разные. Пора разложить это по полочкам.

В конце 2024 года вышел pgvector 0.8 с заметными изменениями в производительности индексов, и это хороший повод сравнить расклад: когда pgvector в Postgres Pro закрывает задачу, а когда приходится тянуть отдельный Weaviate или Qdrant.

Что изменилось в pgvector 0.8

Ключевое в 0.8 - переработанный HNSW-индекс. В предыдущих версиях построение HNSW на больших коллекциях (от нескольких миллионов векторов) было медленным и памятеёмким настолько, что приходилось осторожничать с параметрами m и ef_construction. В 0.8 параллельное построение индекса стало работать без патчей - max_parallel_maintenance_workers теперь реально используется при CREATE INDEX.

Второе - iterative index scans. Раньше при поиске с фильтрами по метаданным (например, «найди ближайшие векторы, но только из документов категории X») pgvector мог деградировать до seq scan, потому что после применения ANN-индекса результатов после фильтрации не хватало до запрошенного LIMIT. В 0.8 движок умеет расширять поиск итеративно - сначала берёт N кандидатов, применяет фильтр, если не хватает - берёт ещё. Это не магия, и на очень жёстких фильтрах всё равно будет больно, но типичные рабочие кейсы перестали требовать костылей.

Третье - улучшенная работа с квантизацией: halfvec и int8 форматы появились ещё в 0.7, но в 0.8 их интеграция с HNSW доработана. На больших коллекциях сжатие индекса за счёт уменьшения точности векторов даёт реальную экономию памяти - это важно для инсталляций, где Postgres на жёстко ограниченном железе.

В Postgres Pro Enterprise 16/17 pgvector обновляется централизованно, что в корпоративном контуре важнее, чем кажется: не надо следить за upstream вручную и пересобирать расширение при каждом минорном апдейте.

Когда pgvector достаточно

Прямой ответ: если у вас до 3-5 миллионов векторов, одна коллекция или несколько небольших, и Postgres уже в стеке - pgvector закрывает задачу без вопросов.

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

RAG на корпоративной документации - типичный случай. Несколько сотен тысяч chunk-ов, поиск с фильтрацией по разделу или категории, умеренная нагрузка - это pgvector без натяжки. В нашем апрельском кейсе с wiki на 400 пользователей HNSW-индекс на pgvector отрабатывал ANN-поиск быстрее, чем LLM успевала обработать промпт. То есть векторный поиск вообще не был узким местом.

Транзакционность. В pgvector векторы живут в тех же транзакциях, что и основные данные. Обновил документ - в той же транзакции обновил его chunk-и. Это удобно, когда источник данных - реляционная таблица или документ с версионированием. В отдельных векторных базах синхронизацию с источником правды придётся выстраивать отдельно.

Когда нужна отдельная векторная база

Weaviate и Qdrant решают другие задачи - там, где pgvector начинает проседать.

Масштаб. Если векторов десятки миллионов и выше, с плотным поиском и высоким RPS - pgvector как расширение Postgres будет конкурировать за ресурсы с основной OLTP-нагрузкой. Специализированные базы оптимизированы под одну задачу, умеют горизонтальное шардирование векторного индекса и лучше держат производительность при росте коллекции.

Мультитенантность с изоляцией. В Weaviate класс с отдельным HNSW-индексом на каждого тенанта - это встроенная концепция. В pgvector мультитенантность решается через row-level security или отдельные схемы, что работает, но с ростом числа тенантов управление усложняется.

Разные типы поиска в одном месте. Qdrant умеет sparse + dense hybrid search нативно: одновременно ANN по dense-вектору и BM25-подобный поиск по sparse-вектору. Для RAG это важно, потому что на части запросов keyword-поиск выигрывает у семантического. В pgvector гибридный поиск собирается руками через tsvector + векторный индекс + RRF-ранжирование - решаемо, но не из коробки.

Мультивекторность. Если на один документ нужно хранить несколько векторов разных моделей (например, dense от e5-large и sparse от SPLADE) - в специализированных базах это первоклассный гражданин. В pgvector это несколько колонок с разными индексами, что тоже работает, но менее удобно при операциях над коллекцией.

Что выбирают клиенты на практике

Честный срез по последним проектам: большинство корпоративных RAG-пилотов, которые мы видим, запускаются на pgvector. Причина прагматичная - Postgres уже есть в инфраструктуре, pgvector ставится за 10 минут, и объёмы документации у типичного корпоративного клиента не такие, чтобы это было узким местом.

Отдельная векторная база появляется там, где:

• RAG - не единственный случай использования векторного поиска, и команда планирует мультимодальный поиск или рекомендации
• несколько тысяч пользователей с высоким RPS к поиску
• требуется горизонтальное масштабирование без перестройки архитектуры

Weaviate в замкнутом контуре - это отдельная история про развёртывание. On-premise установка через Helm существует, но поддержка в изолированной среде без доступа к внешним registry требует подготовки. Qdrant в этом смысле проще: один бинарь, минимальные зависимости.

Где мы сейчас

Для аналитических задач и RAG-пайплайнов мы сейчас рекомендуем следующую логику выбора: если Postgres уже в контуре и векторов до нескольких миллионов - pgvector 0.8 и не усложнять. Если нагрузка или функциональность выходит за эти рамки - смотреть на Qdrant как более простой в развёртывании вариант, Weaviate - когда нужна мультитенантность с богатой схемой данных.

Главный вывод пока такой: специализированные векторные базы решают реальные задачи, но большинство корпоративных RAG-кейсов эти задачи не имеют. Отдельный сервис - это отдельные операционные расходы, и тащить его ради пилота на 200 тысяч chunk-ов - это переусложнение.