Векторный поиск перестал быть экзотикой: семантический поиск по каталогу, RAG, рекомендации, дедупликация лидов — везде нужны эмбеддинги. Главный архитектурный выбор: класть векторы в существующий Postgres через pgvector или поднимать отдельный Qdrant. Разбираем, где какой инструмент уместен.
pgvector: когда хватает Postgres
pgvector — расширение Postgres с типом vector и индексами IVFFlat и HNSW. Главный плюс — он живёт в той же базе, что и ваши заказы, пользователи, документы. Можно делать честный JOIN между векторным поиском и реляционными фильтрами: «найди похожие товары среди тех, что в наличии и стоят менее 5000 рублей».
Пороги, при которых pgvector работает спокойно: до 5–10 млн векторов размерности 1536, нагрузка до 50 RPS на поиск. Индекс HNSW на этом объёме строится за 10–30 минут и держит latency p95 в районе 30–80 мс. Бэкап и репликация — стандартные средства Postgres, без отдельной системы.
Минусы: индекс не обновляется инкрементально без перестройки (для IVFFlat), HNSW жрёт память, при шардинге и больших объёмах операционная боль растёт быстрее, чем у специализированной БД.
Qdrant: когда нужно больше
Qdrant — векторная БД на Rust с богатой моделью фильтров (payload-фильтры, geo, full-text), горизонтальным шардингом, инкрементальными обновлениями HNSW и встроенными квантизациями (scalar, product). Латенси на 50 млн векторов — единицы миллисекунд при правильной настройке.
Ключевые сценарии для Qdrant: каталог более 10 млн товаров с сложными фильтрами, мультитенантность с десятками тысяч коллекций, требование sub-10ms latency, потребность в alias-роутинге для blue-green переиндексации. Из коробки есть REST и gRPC, есть managed-версия в Yandex Cloud и Selectel.
Эксплуатация: что больно с обоими
С pgvector главная боль — память. Индекс HNSW на 5 млн векторов 1536d легко съедает 30+ ГБ RAM. Если Postgres делит ресурсы с OLTP-нагрузкой, конкуренция за shared_buffers убивает обе системы. Решение: вынести векторный поиск на отдельную реплику.
С Qdrant больно с операционкой. Это ещё одна БД, которую нужно мониторить, бэкапить (snapshot API), обновлять. Если в команде нет SRE, готовьтесь тратить 5–10% времени на её обслуживание. Зато масштабирование честно горизонтальное.
Гибридный поиск и реранжирование
В обоих случаях чистый векторный поиск редко даёт лучший результат. Гибрид — BM25 на текстовом поле плюс векторный поиск, объединение через Reciprocal Rank Fusion — поднимает релевантность на 15–25%. В pgvector делается через ts_vector + векторный score. В Qdrant — через sparse vectors и hybrid search API.
Сверху обычно ставится реранкер: cross-encoder (BGE-reranker, Cohere Rerank) пересчитывает топ-50 кандидатов и выдаёт топ-10. Это медленнее на 50–150 мс, но качество ответа взлетает.
Что выбрать на старте
Если у вас уже есть Postgres и менее 5 млн векторов — берите pgvector. Меньше движущихся частей, проще деплой, JOIN с реляционными данными. Перейти на Qdrant можно за 1–2 недели, когда рост покажет, что нужны его возможности.
Если стартуете с нуля и знаете, что объём пойдёт за 10 млн, либо нужна мультитенантность с тысячами клиентов — сразу Qdrant. Гибридная схема (горячие данные в Qdrant, холодные в pgvector для аналитики) встречается, но для большинства проектов это оверинжиниринг.
Итого
pgvector — рабочая лошадка для большинства задач до средних масштабов; Qdrant — выбор для высоких нагрузок и сложных фильтров. Оба требуют гибридного поиска и реранжирования для серьёзного качества. Начинайте с того, что проще эксплуатировать в вашей команде.
Частые вопросы
Когда хватает pgvector для векторного поиска?
pgvector — расширение Postgres с типом vector и индексами IVFFlat и HNSW. Главный плюс — он живёт в той же базе, что и ваши заказы, пользователи, документы. Можно делать честный JOIN между векторным поиском и реляционными фильтрами. Пороги, при которых pgvector работает спокойно: до 5–10 млн векторов размерности 1536, нагрузка до 50 RPS на поиск. Индекс HNSW на этом объёме строится за 10–30 минут и держит latency p95 в районе 30–80 мс.
Когда нужен Qdrant вместо pgvector?
Qdrant — векторная БД на Rust с богатой моделью фильтров (payload-фильтры, geo, full-text), горизонтальным шардингом, инкрементальными обновлениями HNSW и встроенными квантизациями. Латенси на 50 млн векторов — единицы миллисекунд при правильной настройке. Ключевые сценарии: каталог более 10 млн товаров со сложными фильтрами, мультитенантность с десятками тысяч коллекций, требование sub-10ms latency, потребность в alias-роутинге для blue-green переиндексации. Из коробки REST и gRPC.
Какие операционные сложности у pgvector и Qdrant?
С pgvector главная боль — память. Индекс HNSW на 5 млн векторов 1536d легко съедает 30+ ГБ RAM. Если Postgres делит ресурсы с OLTP-нагрузкой, конкуренция за shared_buffers убивает обе системы. Решение: вынести векторный поиск на отдельную реплику. С Qdrant больно с операционкой. Это ещё одна БД, которую нужно мониторить, бэкапить (snapshot API), обновлять. Если в команде нет SRE, готовьтесь тратить 5–10% времени на её обслуживание.
Что такое гибридный поиск и зачем он нужен?
Чистый векторный поиск редко даёт лучший результат. Гибрид — BM25 на текстовом поле плюс векторный поиск, объединение через Reciprocal Rank Fusion — поднимает релевантность на 15–25%. В pgvector делается через ts_vector + векторный score. В Qdrant — через sparse vectors и hybrid search API. Сверху обычно ставится реранкер: cross-encoder (BGE-reranker, Cohere Rerank) пересчитывает топ-50 кандидатов и выдаёт топ-10. Это медленнее на 50–150 мс, но качество ответа взлетает.
Можно ли мигрировать с pgvector на Qdrant?
Да, миграция занимает 1–2 недели. Стандартный путь: установить Qdrant параллельно, перелить эмбеддинги через batch-импорт, настроить dual-write на время переключения, переключить чтение на Qdrant, оставить pgvector в read-only для аналитики. Гибридная схема (горячие данные в Qdrant, холодные в pgvector для аналитики) встречается, но для большинства проектов это оверинжиниринг. Перейти на Qdrant можно за 1–2 недели, когда рост покажет, что нужны его возможности.
Что выбрать на старте нового проекта с векторным поиском?
Если у вас уже есть Postgres и менее 5 млн векторов — берите pgvector. Меньше движущихся частей, проще деплой, JOIN с реляционными данными. Если стартуете с нуля и знаете, что объём пойдёт за 10 млн, либо нужна мультитенантность с тысячами клиентов — сразу Qdrant. Оба требуют гибридного поиска и реранжирования для серьёзного качества. Начинайте с того, что проще эксплуатировать в вашей команде. Без SRE Qdrant будет проблемой.