pgvector, Qdrant или Milvus: выбор для векторного поиска на VDS

pgvector, Qdrant и Milvus представляют три разных архитектурных подхода к одной задаче. pgvector добавляет векторный поиск в PostgreSQL, Qdrant работает как специализированный поисковый сервис, а Milvus рассчитан как на автономный сервер, так и на крупную распределённую инфраструктуру с раздельным масштабированием компонентов.

Выбирать только по скорости ANN-поиска неправильно. На реальном CPU VDS результат определяют не только алгоритм индекса и размер векторов, но и селективность фильтров, частота обновлений, доступная память, скорость локального SSD, требования к транзакциям и готовность команды обслуживать отдельную базу. Система с лучшим результатом в изолированном тесте может оказаться неудобной или слишком дорогой в эксплуатации.

Краткий ответ: что выбрать

• pgvector — первый кандидат, если документы, права доступа, статусы и векторы уже хранятся в PostgreSQL, важны SQL, JOIN и атомарное обновление всех полей в одной транзакции. Это наиболее простой вариант для небольшого и среднего AI-сервиса, особенно когда PostgreSQL всё равно нужен приложению.
• Qdrant — практичный выбор для выделенного векторного поиска на одном или нескольких VDS. Он особенно полезен при активной фильтрации по метаданным, высокой доле поискового трафика и необходимости независимо масштабировать основную БД и поисковый слой.
• Milvus — выбор для больших коллекций, разных типов индексов, дисковых сценариев и заранее ожидаемого перехода к распределённому кластеру. На одном небольшом VDS его преимущества часто не компенсируют повышенные требования к памяти и эксплуатации.

Если проект только запускается и PostgreSQL уже входит в архитектуру, разумно начать с pgvector и измерить пределы на собственных данных. Если поиск является самостоятельной высоконагруженной подсистемой, чаще удобнее Qdrant. Milvus стоит выбирать тогда, когда его масштабируемая архитектура и широкий набор индексов решают конкретную задачу, а не ради абстрактного запаса на будущее.

Для самостоятельного развёртывания поискового сервиса потребуется сервер с административным доступом: на виртуальном хостинге нельзя устанавливать системные пакеты, запускать постоянные контейнеры и настраивать службы. Подходящую конфигурацию можно выбрать на странице VPS-серверов.

Облачный VDS-сервер

Виртуальные серверы с быстрым запуском и гибкой конфигурацией от 390₽ / мес

Доступные локации

Россия Нидерланды

Смотреть тарифы

Чем архитектурно различаются системы

pgvector: векторы внутри реляционной базы

pgvector — расширение PostgreSQL, а не отдельный сервер. Вектор становится типом столбца таблицы, поэтому рядом можно хранить идентификатор владельца, текст, категорию, состояние публикации и другие данные. Запрос объединяет обычные условия SQL с сортировкой по расстоянию между векторами.

Главное преимущество такого подхода — единая модель данных. Добавление документа, изменение его статуса и запись нового вектора можно выполнить в одной транзакции. Не требуется синхронизировать PostgreSQL с внешним поисковым хранилищем или решать, какая система является источником истины.

pgvector поддерживает точный поиск, HNSW и IVFFlat, а также полноточные, половинной точности, бинарные и разреженные векторы. Для приблизительных индексов доступны итеративные сканирования, помогающие получать нужное число результатов после применения фильтра.

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

Qdrant: отдельный поисковый сервис

Qdrant хранит в одной точке вектор и payload — набор метаданных, используемых для фильтрации. Приложение обращается к нему через HTTP или gRPC. Основная реляционная БД при этом обычно остаётся источником бизнес-данных, а Qdrant становится специализированной поисковой проекцией.

Для плотных векторов Qdrant использует HNSW, но дополняет его payload-индексами, планировщиком запросов, хранением векторов на диске и несколькими вариантами квантования. Движок может выбирать между обходом HNSW и полным просмотром небольшого набора кандидатов. Фильтруемый HNSW получает дополнительные связи на основе проиндексированных полей payload, что важно для сочетания семантической близости с условиями по пользователю, категории или другим атрибутам.

В односерверном режиме это сравнительно компактный сервис без реляционного планировщика и JOIN. В распределённом режиме коллекции разбиваются на шарды, для них создаются реплики, а состояние топологии координируется между узлами.

Milvus: платформа для масштабируемого поиска

Milvus предлагает больше вариантов физических индексов: FLAT, семейство IVF, HNSW с разными способами сжатия, DiskANN и другие реализации для отдельных типов данных и режимов нагрузки. Это позволяет подбирать структуру под доступную память, требуемый recall, размер top-K и характеристики SSD.

В standalone-развёртывании Milvus запускается на одном сервере. В distributed-режиме его архитектура разделяет доступ, координацию, потоковую обработку, выполнение запросов, фоновую обработку и хранение. Вычислительные компоненты можно масштабировать независимо, но за эту гибкость приходится платить большим количеством движущихся частей.

Milvus лучше всего раскрывается там, где один сервер перестаёт быть целевой архитектурой. Для маленького проекта на одном VDS широкий выбор индексов сам по себе редко является достаточной причиной принимать дополнительную эксплуатационную сложность.

Сравнение по основным критериям

Индексы и качество поиска

pgvector: HNSW или IVFFlat

HNSW обычно выбирают, когда важны низкая задержка и хороший recall при умеренном top-K. Индекс можно создавать до загрузки данных, но построение и последующие вставки требуют заметных CPU и памяти. Параметры графа влияют на размер индекса, время построения и качество результатов.

IVFFlat разбивает пространство на списки и просматривает только часть из них. Он быстрее строится и использует меньше памяти, но требует осмысленно выбрать количество списков и probes. Индекс желательно создавать после загрузки репрезентативного объёма данных, поскольку разбиение зависит от распределения векторов. При существенном изменении набора данных может потребоваться перестроение.

pgvector также позволяет уменьшать индекс с помощью halfvec либо строить выражение для бинарно квантованного представления, отбирать расширенный набор кандидатов и затем пересортировывать его по исходным векторам. Это полезно на ограниченном VDS, но точность и задержку необходимо измерять: универсального безопасного коэффициента сжатия или размера списка для повторного ранжирования нет.

Qdrant: один основной граф, но разные варианты размещения

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

Такой подход уменьшает число архитектурных решений. Команде не нужно выбирать между большим семейством ANN-алгоритмов, но всё равно придётся настроить размер графа, глубину поиска, пороги индексирования, число сегментов и работу фонового оптимизатора.

Qdrant поддерживает скалярное, продуктовое и бинарное квантование, а также более компактные представления. Квантованный индекс способен сократить потребление памяти, после чего кандидаты при необходимости пересчитываются по полным векторам. Сжатие повышает роль CPU и параметров повторного пересчёта, поэтому его нельзя включать только ради красивого показателя RAM.

Milvus: выбор индекса под конкретный предел

Milvus предоставляет больше вариантов. HNSW подходит для высокой точности и небольшого top-K, семейство IVF даёт контроль над компромиссом между памятью и числом просматриваемых кластеров, SQ и PQ уменьшают объём представления, а DiskANN предназначен для случаев, когда граф и исходные данные не должны полностью помещаться в RAM.

Широкий выбор полезен, если команда проводит полноценные нагрузочные тесты. Без них он превращается в дополнительный источник ошибок: два индекса с одинаковым названием класса могут иметь разный профиль построения, потребления памяти, recall и задержки на конкретном наборе векторов. На CPU VDS особенно важно учитывать, что экономия RAM с помощью PQ или дискового индекса может увеличить вычислительную нагрузку и количество случайных чтений.

Фильтрация по метаданным

Фильтрованный поиск часто сильнее влияет на выбор системы, чем чистая скорость ANN. Типичный AI-сервис ищет не по всей коллекции, а только по данным конкретного пользователя, проекта, языка, периода или уровня доступа.

Как фильтрует pgvector

PostgreSQL даёт полноценные условия SQL, JOIN, подзапросы, row-level security и обычные B-tree, GIN, GiST, BRIN и другие индексы. Если фильтр оставляет очень мало строк, планировщик может сначала получить кандидатов обычным индексом и точно вычислить расстояние только для них. Это простой и качественный вариант.

С приблизительным векторным индексом есть особенность: условия WHERE могут применяться к уже найденным ANN-кандидатам. При строгом фильтре результатов окажется меньше запрошенного лимита. Итеративное сканирование HNSW или IVFFlat продолжает обход, пока не набрано нужное количество строк либо не достигнут предел работы.

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

При росте нагрузки полезно отдельно анализировать план SQL и статистику таблиц: проблемы производительности нередко связаны не с самим векторным индексом, а с неэффективным отбором строк.

Как фильтрует Qdrant

В Qdrant поля, которые участвуют в фильтрах, следует объявлять payload-индексами. Тогда движок может оценить количество подходящих точек и выбрать стратегию: пройти фильтруемый HNSW либо обработать небольшой набор без графа. Если payload хранится на диске, индексированные значения фильтров всё равно могут оставаться в памяти, что позволяет не читать полный JSON для каждой точки.

Это делает Qdrant сильным вариантом для многопользовательского поиска. Однако payload не заменяет реляционную модель. Сложные JOIN, внешние ключи и произвольные аналитические условия лучше вычислять в основной БД, а в Qdrant передавать минимальный набор атрибутов, действительно нужных поисковому планировщику.

Как фильтрует Milvus

Milvus поддерживает скалярные поля, JSON, массивы и индексы для разных типов метаданных. Фильтр может применяться до векторного этапа либо учитываться планом поиска в зависимости от индекса и селективности. Для частых условий скалярные поля необходимо индексировать, иначе проверка большого объёма метаданных снизит пропускную способность.

Milvus удобен, когда схема коллекции проектируется специально под поиск. Если же запрос требует постоянно обращаться к нормализованным бизнес-таблицам, вынос данных в отдельную vector database создаст дублирование и задачу синхронизации, но не устранит потребность в PostgreSQL.

Консистентность и обновление данных

pgvector

В PostgreSQL вектор участвует в тех же ACID-транзакциях и MVCC, что и остальные столбцы. Приложение не увидит строку с новым текстом и старым вектором, если оба значения корректно обновляются одной транзакцией. Доступны стандартные уровни изоляции PostgreSQL, ограничения целостности, журнал WAL и восстановление на момент времени.

Это серьёзное преимущество для сервисов, где результаты должны немедленно учитывать удаление документа, изменение прав или публикацию новой версии. При чтении с реплики всё равно возможна задержка репликации, поэтому критичные запросы read-after-write следует направлять на primary либо контролировать позицию воспроизведения.

Qdrant

На одном узле Qdrant записывает изменения в WAL, после чего применяет их к сегментам. В кластере доступны коэффициент подтверждения записи, режим согласованности чтения и порядок обновлений. По умолчанию настройки ориентированы на доступность и пропускную способность; более строгие гарантии повышают задержку и могут ограничить запись при недоступности реплик. Raft отвечает за топологию и структуру коллекций, но операции над отдельными точками не становятся распределённой SQL-транзакцией.

Если исходные документы хранятся в PostgreSQL, атомарной транзакции между ним и Qdrant нет. Практический шаблон — считать PostgreSQL источником истины, фиксировать событие изменения в той же транзакции, доставлять его в Qdrant с повторными попытками и периодически сверять версии. Простой dual write из обработчика запроса оставляет окно, в котором запись прошла только в одну систему.

Milvus

Milvus предлагает уровни согласованности strong, bounded staleness, session и eventual; по умолчанию используется bounded staleness. Более строгий уровень уменьшает риск чтения устаревших данных, но может увеличить задержку.

Как и в случае Qdrant, согласованность внутри Milvus не решает атомарность с внешней бизнес-БД. Для надёжной интеграции нужны идемпотентные upsert и delete, версия документа в метаданных, очередь изменений либо outbox и фоновая сверка.

Память и диски на CPU VDS

Начальную оценку объёма полноточных векторов можно получить по формуле:

число векторов × размерность × 4 байта

Например, один миллион векторов размерностью 768 занимает около 3,07 ГБ в десятичном представлении только для координат. В эту оценку не входят граф HNSW, идентификаторы, версии записей, payload, реляционные строки, временные данные построения индекса, page cache и запас для фоновых операций. Репликация дополнительно умножает потребность в диске, а часто и в суммарной памяти кластера.

На VDS нельзя планировать систему так, чтобы расчётный рабочий набор занимал всю RAM. Память нужна ОС, файловому кэшу, процессам базы, соединениям и перестроению индексов. При упоре в swap задержка ANN-запросов становится нестабильной, поэтому полезнее оставить запас и держать под наблюдением не только среднюю, но и p95/p99 latency.

Память pgvector

PostgreSQL хранит таблицы и индексы на диске и использует собственные буферы вместе с page cache ОС. HNSW не обязан целиком постоянно находиться в RAM, но случайные обращения к холодным страницам ухудшают задержку. Построение индекса может требовать большого maintenance_work_mem; чрезмерное значение опасно на небольшом VDS, особенно при параллельных операциях.

Использование halfvec уменьшает объём координат по сравнению с float32. IVFFlat обычно легче строить, чем HNSW. Но PostgreSQL одновременно обслуживает таблицу, WAL, autovacuum и запросы приложения, поэтому недопустимо оценивать pgvector отдельно от всей базы.

Память Qdrant

Qdrant позволяет хранить векторы и payload в RAM либо на диске через memory mapping. При достаточной памяти горячие страницы останутся в page cache; после рестарта или при наборе данных значительно больше RAM возрастёт число чтений с диска. Квантованное представление можно держать в памяти и использовать для первичного отбора, а полные векторы — на SSD для пересчёта кандидатов.

Такой режим хорошо подходит для VDS с ограниченной RAM, но требует локального быстрого SSD или NVMe. Сетевые файловые системы для постоянного хранилища Qdrant не подходят: движку требуется блочное хранилище с POSIX-совместимой файловой системой.

Память Milvus

Milvus умеет применять mmap к исходным данным и индексам, а DiskANN переносит значительную часть структуры на SSD. Это позволяет работать с коллекцией больше RAM, но не отменяет потребность в памяти для процессов, метаданных, кэшей и кодов квантования.

Требования для standalone указывают минимум 8 ГБ RAM и рекомендуют 16 ГБ, а также не менее четырёх CPU-ядер в качестве рекомендации. Фактический объём зависит от данных, но уже этот базовый уровень показывает, почему Milvus редко является лучшим соседом для веб-приложения на маленьком VDS.

Горизонтальное масштабирование

pgvector: сначала вертикальный рост

pgvector наследует масштабирование PostgreSQL. Можно увеличить ресурсы сервера, создать read replica, секционировать таблицу или внедрить внешний слой шардинга. Однако обычная потоковая репликация дублирует весь набор данных и в первую очередь масштабирует чтение, а не ёмкость одной логической коллекции.

Распределить векторный top-K между независимыми шардами можно на уровне приложения: отправить запрос каждому шарду, получить локальных кандидатов и объединить их по расстоянию. Но тогда приложение отвечает за маршрутизацию, обработку отказов, перебалансировку и корректность глобального результата. Это уже отдельная распределённая система, а не функция расширения.

Qdrant: шарды и реплики как часть продукта

Qdrant делит коллекцию на шарды и размещает их на узлах. Реплики повышают доступность, а добавление шардов распределяет объём и вычисления. Запрос поступает на один из узлов, выполняется на нужных шардах, после чего частичные результаты объединяются.

Для настоящей отказоустойчивости нужны несколько VDS в разных физических доменах отказа и как минимум три голосующих узла для устойчивого Raft-кворума. Два сервера могут хранить реплики данных, но потеря одного узла не оставляет большинства для операций, требующих консенсуса. Следовательно, переход от одного Qdrant к HA-кластеру увеличивает бюджет не в два условных контейнера: также понадобятся балансировщик, закрытая межузловая сеть, резервное копирование и мониторинг.

Milvus: независимое масштабирование ролей

В distributed-режиме Milvus позволяет отдельно увеличивать ресурсы для запросов, приёма данных и фоновой обработки. Такой подход эффективен, когда профиль нагрузки асимметричен: например, поисковых запросов значительно больше, чем вставок, либо массовая загрузка не должна отнимать CPU у Query Node.

Обратная сторона — Kubernetes, объектное хранилище, метаданные, WAL и несколько типов сервисов. Для группы обычных VDS без готовой кластерной платформы Qdrant чаще проще. Milvus становится убедительнее, когда Kubernetes и наблюдаемость уже являются частью инфраструктуры, а коллекции и поток запросов действительно требуют независимого масштабирования.

Эксплуатация и резервное копирование

pgvector обслуживается как PostgreSQL. Нужны резервные копии, архивирование WAL при необходимости PITR, контроль autovacuum, размера таблиц и индексов, статистики планировщика, блокировок и репликации. Преимущество — знакомые инструменты. Риск — тяжёлое построение HNSW или массовая загрузка могут повлиять на обычные транзакции приложения.

Qdrant легко запустить одним контейнером или бинарным файлом, но production-развёртывание требует постоянного тома данных, snapshots, контроля фоновой оптимизации и свободного места для временных сегментов. Самостоятельный сервер по умолчанию не следует публиковать в интернет: необходимо ограничить доступ сетевым экраном или приватной сетью, включить аутентификацию и при необходимости TLS.

Milvus Standalone в актуальной архитектуре упаковывает основные компоненты в один образ и использует встроенные службы для метаданных и WAL, поэтому стал проще прежних многоконтейнерных схем. Тем не менее резервное копирование, обновление и диагностика остаются сложнее, чем у одного Qdrant. Distributed-вариант требует полноценного сопровождения кластера, а не только мониторинга одного процесса.

Независимо от выбранного движка резервную копию нужно не только создавать, но и регулярно восстанавливать в изолированном окружении. Проверка восстановления покажет фактическое RTO, полноту данных и работоспособность процедуры до инцидента.

Как сравнивать на собственном VDS

Готовые рейтинги ANN показывают потенциал алгоритма, но не отвечают на вопрос о вашем приложении. Для корректного теста подготовьте одинаковый набор данных и одинаковые запросы для всех кандидатов.

1. Зафиксируйте количество и размерность векторов, тип метрики и распределение значений.
2. Соберите реальные фильтры: от широких до условий, оставляющих доли процента коллекции.
3. Разделите нагрузку на чтение, вставки, обновления и удаления. Не тестируйте только неподвижный индекс.
4. Измеряйте recall относительно точного поиска, а не только число запросов в секунду.
5. Записывайте p50, p95 и p99 latency, загрузку CPU, RAM, page faults, чтение и запись на диск.
6. Проводите холодный тест после перезапуска и прогретый тест после серии запросов.
7. Повторите измерения во время фоновой индексации, compaction, autovacuum или перестроения сегментов.
8. Проверьте восстановление из резервной копии и время возврата сервиса, а не только создание backup.

Для CPU VDS важна предсказуемость вычислительных ресурсов. На тарифе с разделяемыми ядрами результаты могут меняться из-за нагрузки соседей. Если требуется стабильная p99 latency, полезнее выделенные CPU и локальный NVMe, чем номинально больше виртуальных ядер с непредсказуемой производительностью.

Типичные ошибки выбора

• Выбирать по максимальному числу векторов в документации. Практический предел задаётся размерностью, фильтрами, индексом, recall и ресурсами конкретного VDS.
• Хранить всё в RAM без расчёта. Помимо исходных координат существуют граф, метаданные, временные сегменты и фоновые процессы.
• Считать отдельную vector database источником бизнес-данных. Qdrant и Milvus оптимизированы для поиска, но обычно не заменяют реляционные ограничения и транзакции приложения.
• Не индексировать поля фильтров. В любой из трёх систем это способно превратить быстрый ANN-запрос в дорогое чтение большого объёма данных.
• Переносить синтетические параметры в production. Значения HNSW, IVF и квантования должны проверяться на реальном распределении векторов.
• Строить кластер на двух VDS и считать его полностью отказоустойчивым. Реплика данных не всегда означает наличие кворума управления после отказа узла.
• Игнорировать стоимость синхронизации. Вынос поиска из PostgreSQL добавляет очередь изменений, повторные попытки, удаление устаревших точек и сверку версий.

Итоговая матрица выбора

Выбирайте pgvector, если PostgreSQL уже является центром приложения, коллекция помещается на одном мощном VDS, фильтры удобно выражаются через SQL, а транзакционная согласованность важнее независимого масштабирования поиска. Это также хороший стартовый вариант, когда команда не хочет обслуживать вторую базу до появления измеримых ограничений.

Выбирайте Qdrant, если поисковая нагрузка должна быть изолирована от основной БД, метаданные имеют сравнительно простую документную форму, фильтры являются частью большинства запросов, а проекту нужен понятный путь от одного VDS к шардированному кластеру. Для типичного специализированного AI-сервиса на CPU VDS это наиболее сбалансированный отдельный движок.

Выбирайте Milvus, если ожидается большой объём данных, нужен выбор между HNSW, IVF, сжатыми и дисковыми индексами, а инфраструктура готова к более сложной эксплуатации. Он особенно оправдан, когда распределённый режим и независимое масштабирование ролей являются текущим требованием, а не гипотетической задачей далёкого будущего.

Универсального победителя нет. На одном VDS простота часто важнее предельного benchmark QPS: pgvector уменьшает число систем, Qdrant даёт специализированный поиск без чрезмерной сложности, а Milvus предоставляет максимальную архитектурную гибкость ценой ресурсов и сопровождения. Окончательное решение следует принимать после теста на собственных векторах, фильтрах и профиле обновлений.