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

> Векторная база данных для RAG и поиска: чем отличаются Qdrant, Weaviate и Milvus и что поставить на VDS.

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

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

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

Такой поиск лежит в основе [RAG-систем](https://www.zevshost.net/ru/kb/rag-sistema-nastroika/), рекомендаций, дедупликации и поиска похожих изображений. Выбор конкретной базы влияет на потребление 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](https://www.zevshost.net/ru/kb/qdrant-nastroika-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](https://www.zevshost.net/ru/kb/pgvector-postgresql/), если у проекта уже есть эта СУБД и нагрузка не превышает пары миллионов записей.

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

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

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

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

## Частые вопросы

### Можно ли мигрировать данные между Qdrant, Weaviate и Milvus позже, если выбор окажется неверным?

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

### Как векторный поиск соотносится с полнотекстовым — нужно выбирать между ними?

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

### Что произойдёт, если модель эмбеддингов сменится позже — придётся переделывать всю базу?

Смена модели эмбеддингов требует пересчитать векторы для всех существующих записей — старые и новые векторы несовместимы между собой, даже если размерность совпадает случайно, потому что числа кодируют смысл по-разному. На практике это означает прогнать весь корпус данных через новую модель заново и либо перезаписать коллекцию, либо создать её рядом и переключиться после полного пересчёта.

### Нужна ли отдельная векторная база, или достаточно расширения для уже имеющейся реляционной СУБД?

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

---

Источник: https://www.zevshost.net/ru/kb/vektornye-bd-sravnenie/