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

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

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

## Що таке векторна база даних і навіщо вона потрібна

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

Такий пошук лежить в основі [RAG-систем](https://www.zevshost.net/uk/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/uk/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/uk/kb/pgvector-postgresql/), коли у проєкту вже є ця СУБД, а навантаження не перевищує пари мільйонів записів.

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

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

Перш ніж розгортати будь-яку з баз, оцініть три речі: скільки векторів буде за рік, скільки вільної RAM є на сервері та чи потрібна фільтрація за метаданими на кожному запиті. Помилка на цьому кроці коштує дорожче, ніж міграція даних між базами — формат векторів у всіх різний, доведеться заново ганяти ембединги.

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

## Часті питання

### Чи можна мігрувати дані між Qdrant, Weaviate і Milvus пізніше, якщо вибір виявиться хибним?

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

### Як векторний пошук співвідноситься з повнотекстовим — чи потрібно обирати між ними?

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

### Що станеться, якщо модель ембедингів зміниться пізніше — доведеться переробляти всю базу?

Зміна моделі ембедингів вимагає перерахувати вектори для всіх наявних записів — старі і нові вектори несумісні між собою, навіть якщо розмірність випадково збігається, бо числа кодують зміст по-різному. На практиці це означає прогнати весь корпус даних крізь нову модель наново і або перезаписати колекцію, або створити її поруч і перемкнутися після повного перерахунку.

### Чи потрібна окрема векторна база, чи вистачить розширення для вже наявної реляційної СУБД?

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

---

Джерело: https://www.zevshost.net/uk/kb/vektornye-bd-sravnenie/