Векторная база данных нужна там, где обычный WHERE title LIKE '%...%' не находит смысл, а находит только точное совпадение букв. Эмбеддинг превращает текст, картинку или аудио в вектор чисел, а векторная БД быстро ищет соседние по смыслу записи среди миллионов. Три самых частых кандидата на VDS — Qdrant, Weaviate и Milvus. Разберём, чем они отличаются на практике и что поставить в вашем случае.

Что такое векторная база данных и зачем она нужна

Классический индекс ищет точное вхождение строки. Векторный индекс ищет ближайшие точки в многомерном пространстве по метрике расстояния — косинусной близости или евклидовой. Запрос тоже превращается в вектор той же модели эмбеддингов, а база возвращает top-k ближайших записей за миллисекунды даже на десятках миллионов векторов.

Такой поиск лежит в основе RAG-систем, рекомендаций, дедупликации и поиска похожих изображений. Выбор конкретной базы влияет на потребление RAM, скорость записи и сложность эксплуатации на своём сервере.

Qdrant: простота и низкий порог входа

Qdrant написан на Rust, ставится одним бинарником или Docker-контейнером и не требует внешних зависимостей вроде ZooKeeper или etcd. Хранит векторы вместе с payload-полями и поддерживает фильтрацию по метаданным прямо во время поиска, а не после него.

docker run -d --name qdrant \
  -p 6333:6333 -p 6334:6334 \
  -v /opt/qdrant/storage:/qdrant/storage \
  qdrant/qdrant:latest

На VDS с 4 ГБ RAM Qdrant спокойно держит коллекцию на пару миллионов векторов размерности 768. Подробная установка описана в статье про настройку Qdrant на VPS.

Weaviate: модули и встроенная векторизация

Weaviate написан на Go и добавляет слой модулей: можно подключить векторизацию текста через внешний API прямо внутри базы, не гоняя данные через отдельный сервис эмбеддингов. Схема данных строится через классы с типизированными свойствами, что удобно, если у записи много атрибутов помимо вектора.

Из минусов — Weaviate требовательнее к памяти при большом числе классов и активнее использует GraphQL-интерфейс, который придётся освоить отдельно от привычного REST.

Milvus: масштабирование для больших нагрузок

Milvus рассчитан на десятки и сотни миллионов векторов и распределённую архитектуру: отдельные узлы для приёма записи, индексации и запросов. Такая схема оправдана на кластере из нескольких серверов, но на одном VDS добавляет накладные расходы — Milvus в docker-compose поднимает etcd и MinIO как обязательные зависимости.

wget https://github.com/milvus-io/milvus/releases/download/v2.4.0/milvus-standalone-docker-compose.yml -O docker-compose.yml
docker compose up -d

Standalone-режим Milvus снимает часть сложности, но всё равно потребляет больше RAM в простое, чем Qdrant или Weaviate на той же задаче.

Сравнение по ключевым параметрам

Параметр	Qdrant	Weaviate	Milvus
Язык реализации	Rust	Go	Go + C++
Зависимости для старта	нет	нет	etcd, MinIO
RAM в простое	от 200 МБ	от 400 МБ	от 1.5 ГБ
Фильтрация по payload	да, встроена	да, через классы	да, через схему
Лучше всего подходит	один сервер, RAG	сложная схема данных	кластер, сотни млн векторов

Что поставить на свой VDS

Для чат-бота с базой знаний, поиска по каталогу товаров или личного проекта на VDS с 4-8 ГБ RAM разумный выбор — Qdrant: минимум движущихся частей, один процесс, понятный REST API. Если данные уже структурированы как объекты со множеством связанных свойств и хочется встроенную векторизацию — берите Weaviate. Milvus имеет смысл только при явном плане роста до кластера и десятков миллионов записей, иначе его etcd и MinIO будут просто съедать ресурсы впустую.

Как альтернативу без отдельного сервиса стоит рассмотреть pgvector в PostgreSQL, если у проекта уже есть эта СУБД и нагрузка не превышает пары миллионов записей.

До 2-5 млн векторов, один сервер — Qdrant.
Сложная схема объектов, нужна встроенная векторизация — Weaviate.
Кластер, десятки-сотни миллионов векторов — Milvus.
Проект уже на PostgreSQL, нагрузка небольшая — pgvector вместо отдельной БД.

Чек-лист перед выбором

Прежде чем разворачивать любую из баз, оцените три вещи: сколько векторов будет через год, сколько свободной RAM есть на сервере и нужна ли фильтрация по метаданным на каждом запросе. Ошибка на этом шаге стоит дороже, чем миграция данных между базами — формат векторов у всех разный, и придётся заново гонять эмбеддинги.

Посчитайте прогнозируемое число векторов и их размерность.
Проверьте свободную RAM: Milvus без запаса памяти будет падать по OOM.
Решите, нужна ли фильтрация по полям вместе с векторным поиском.
Начните с Qdrant, если сомневаетесь — миграция на более тяжёлое решение проще, чем откат с него.

Векторные базы данных: сравнение Qdrant, Weaviate и Milvus