Порівняння векторних баз даних: pgvector, Qdrant, Weaviate, Milvus і Pinecone для продакшен-RAG

Кожен проєкт із retrieval-augmented generation рано чи пізно ставить запитання: яку векторну базу обрати? Ринок переповнений — спеціалізовані рушії Qdrant, Weaviate і Milvus, керовані сервіси на кшталт Pinecone і векторні розширення для баз, які ви вже використовуєте, насамперед pgvector для PostgreSQL. Бенчмарки від вендорів рідко відповідають вашому навантаженню. У гайді пояснюємо, чим насправді відрізняються варіанти, які запитання визначають вибір і чому для багатьох бізнес-проєктів відповідь — «PostgreSQL, який у вас уже є».

Що робить векторна база даних

Векторна база зберігає ембеддинги — масиви чисел, що представляють зміст тексту, зображень чи інших даних, — і відповідає на запит «знайди k векторів, найподібніших до цього». Точний пошук порівнює запит із кожним вектором; це прийнятно для десятків тисяч елементів, але надто повільно для мільйонів. Продакшен-системи використовують індекси наближеного пошуку найближчих сусідів (ANN), що жертвують трохи повнотою заради прискорення на порядки.

Поверх цього ядра продакшен-сховищу векторів потрібні:

Фільтрація за метаданими: «подібні документи, але лише для орендаря 42, мова uk, оновлені після 2026-01-01».
Гібридний пошук: поєднання векторної подібності з релевантністю за ключовими словами (BM25).
CRUD і узгодженість: оновлення й видалення документів без перебудови індексу.
Експлуатація: бекапи, реплікація, моніторинг, контроль доступу.

Як працюють ANN-індекси, коротко

HNSW (Hierarchical Navigable Small World) будує багаторівневий граф, де кожен вектор пов'язаний із сусідами; пошук починається з розрідженого верхнього рівня й спускається вниз (Malkov & Yashunin, 2016). Він дає чудову повноту й затримку та підтримує інкрементальні вставки, але ціною пам'яті: граф живе в RAM разом із векторами. Ключові параметри: m (зв'язків на вузол), ef_construction (якість побудови) і ef_search (компроміс повноти й швидкості під час запиту).

IVF (inverted file) кластеризує вектори й шукає лише в найближчих кластерах. Він швидше будується й займає менше пам'яті, але повнота залежить від того, скільки кластерів перевіряти, і індекс потребує перенавчання, коли дані змінюються.

Квантизація стискає вектори — скалярна (float32 → int8), продуктова чи бінарна — зменшуючи пам'ять у 4–32 рази ціною певної повноти, яку зазвичай відновлюють повторним ранжуванням топ-кандидатів за повними векторами. Індекси в стилі DiskANN тримають більшість даних на SSD для дуже великих колекцій.

Незалежні порівняння ANN-алгоритмів публікує ann-benchmarks.com. Практичний урок: для чистої продуктивності пошуку вибір індексу й параметрів важить більше, ніж бренд бази.

Учасники порівняння

Варіант	Тип	Сильні сторони	На що зважати
pgvector	Розширення PostgreSQL	Одна база, SQL-join, транзакції, наявні бекапи й інструменти; HNSW та IVFFlat	Дуже великі колекції й інтенсивний пошук із фільтрами потребують тюнінгу; планування vacuum і пам'яті
Qdrant	Спеціалізований рушій (Rust), OSS + хмара	Потужна фільтрація, інтегрована в HNSW, квантизація, розріджені вектори для гібридного пошуку	Ще одна система в експлуатації
Weaviate	Спеціалізований рушій (Go), OSS + хмара	Вбудований гібридний пошук, модулі векторизації, multi-tenancy	Більше споживання пам'яті; специфічна схема
Milvus	Розподілений рушій, OSS + хмара Zilliz	Мільярди векторів, багато типів індексів, зокрема GPU і DiskANN	Операційна складність розподіленої системи
Pinecone	Повністю керований SaaS	Без експлуатації, serverless-тарифи, зручність для розробників	Прив'язка до вендора, місце зберігання даних, вартість у масштабі
Elasticsearch / OpenSearch	Пошукові рушії з підтримкою векторів	Зрілий BM25 плюс вектори в одному місці	Ресурсоємні; векторні можливості залежать від версії

Усі вони достатньо добрі для типових RAG-навантажень. Рішення переважно стосується експлуатації, масштабу й керування даними.

Запитання, що визначають вибір

1. Скільки векторів насправді?

Оцінюйте чесно. Корпоративна база знань на 20 тис. документів, порізаних на 200 тис. фрагментів по 1024 виміри, — це приблизно 800 МБ векторів float32, що комфортно вміщується в один інстанс PostgreSQL. Десять мільйонів фрагментів — це близько 40 ГБ без урахування накладних витрат індексу, і картина змінюється. Сотні мільйонів і мільярди потребують спеціалізованого розподіленого рушія або агресивної квантизації.

2. Наскільки важлива фільтрація?

Multi-tenant SaaS, документи з контролем доступу й пошук по каталогу залежать від фільтрів. Наївне «спершу знайти, потім відфільтрувати» ламається, коли фільтр вибірковий: ви просите топ-10, ANN повертає 10 сусідів, а 9 з них належать іншим орендарям. Рушії по-різному поєднують фільтрацію з індексом. Qdrant і Weaviate інтегрують фільтри в обхід графа; pgvector у свіжих версіях підтримує ітеративні сканування індексу, а також часткові індекси чи партиціювання за орендарем. Тестуйте з реальною вибірковістю ваших фільтрів.

3. Чи потрібен гібридний пошук?

Для бізнес-документів — артикули, номери статей законів, імена, повідомлення про помилки — чистий векторний пошук пропускає точні збіги. Гібридний пошук BM25 плюс вектори зі злиттям через reciprocal rank fusion (Cormack et al., 2009) — варіант за замовчуванням, який ми радимо; див. RAG для бізнесу. Weaviate, Qdrant (розріджені вектори), Elasticsearch і OpenSearch підтримують його нативно; у PostgreSQL поєднуйте pgvector із повнотекстовим пошуком в одному SQL-запиті.

4. Хто це експлуатуватиме?

Спеціалізований рушій — ще одна система зі станом: бекапи, оновлення, моніторинг, патчі безпеки, планування ємності. Якщо ваша команда вже добре експлуатує PostgreSQL — з перевіреними бекапами й відновленням після збоїв, — додавання pgvector майже нічого не коштує операційно. Керований сервіс прибирає експлуатацію, але додає вендора, рахунок, що росте з даними, і питання про місце зберігання даних; див. приватність LLM-застосунків.

5. Як змінюються дані?

Дані, що часто оновлюються (ціни, залишки, тікети), потребують ефективних upsert і видалень. HNSW добре справляється зі вставками; видалення в деяких рушіях залишають «надгробки», що потребують періодичного прибирання чи переіндексації. Масове переембеддингування при зміні моделі ембеддингів — це запланована міграція в будь-якій системі, тож зберігайте сирий текст, щоб мати змогу переембеддити.

Гібридний пошук у PostgreSQL

Компактний приклад поєднання pgvector і повнотекстового пошуку з reciprocal rank fusion:

-- Схема
CREATE EXTENSION IF NOT EXISTS vector;
CREATE TABLE chunks (
  id bigserial PRIMARY KEY,
  tenant_id int NOT NULL,
  content text NOT NULL,
  tsv tsvector GENERATED ALWAYS AS (to_tsvector('simple', content)) STORED,
  embedding vector(1024) NOT NULL
);
CREATE INDEX ON chunks USING hnsw (embedding vector_cosine_ops) WITH (m = 16, ef_construction = 64);
CREATE INDEX ON chunks USING gin (tsv);
CREATE INDEX ON chunks (tenant_id);

-- Запит: $1 = ембеддинг запиту, $2 = текст запиту, $3 = орендар
WITH vec AS (
  SELECT id, row_number() OVER (ORDER BY embedding <=> $1) AS r
  FROM chunks WHERE tenant_id = $3
  ORDER BY embedding <=> $1 LIMIT 50
), kw AS (
  SELECT id, row_number() OVER (ORDER BY ts_rank(tsv, q) DESC) AS r
  FROM chunks, plainto_tsquery('simple', $2) q
  WHERE tenant_id = $3 AND tsv @@ q
  ORDER BY ts_rank(tsv, q) DESC LIMIT 50
)
SELECT c.id, c.content,
       COALESCE(1.0 / (60 + vec.r), 0) + COALESCE(1.0 / (60 + kw.r), 0) AS score
FROM chunks c
LEFT JOIN vec ON vec.id = c.id
LEFT JOIN kw  ON kw.id  = c.id
WHERE vec.id IS NOT NULL OR kw.id IS NOT NULL
ORDER BY score DESC
LIMIT 10;

Конфігурація 'simple' уникає англійського стемінгу для українського тексту; для кращого повнотекстового пошуку українською розгляньте окремий словник або пошуковий рушій. Налаштовуйте hnsw.ef_search на рівні запиту під потрібну повноту.

Бенчмарк під ваше навантаження

Бенчмарки вендорів оптимізовані під вендора. Проведіть власний — невеликий, але реалістичний:

Візьміть 100–500 реальних запитів з відомими релевантними документами (ваш набір для evals).
Завантажте реальні дані з вашою моделлю ембеддингів і метаданими.
Виміряйте recall@k відносно точного пошуку, p95 затримки з фільтрами, пам'ять і час побудови індексу.
Протестуйте оновлення — вставте й видаліть 10% даних і перевиміряйте.
Оцініть місячну вартість із репліками й бекапами.

Більшість команд з'ясовують, що різниця в наскрізній якості RAG походить від чанкінгу, ембеддингів, гібридного пошуку й переранжування, а не від бази даних. Див. ембеддинги та чанкінг.

Наші рекомендації за замовчуванням

До ~5–10 млн векторів і PostgreSQL уже в стеку: pgvector з HNSW, гібридний пошук у SQL. Найпростіша експлуатація, транзакційна узгодженість із бізнес-даними.
Інтенсивна фільтрація, multi-tenant у масштабі або потреба в просунутій квантизації: Qdrant чи Weaviate, self-hosted у Kubernetes або як керована хмара.
Сотні мільйонів векторів чи пошук із прискоренням на GPU: Milvus/Zilliz.
Немає ресурсу на експлуатацію й обмежень щодо місця зберігання даних: Pinecone або інший керований сервіс.

Що б ви не обрали, тримайте сирий текст і метадані джерелом істини, а векторний індекс розглядайте як похідну, яку можна перебудувати.

FAQ

Чи pgvector «готовий до продакшену»? Так, для масштабу, потрібного більшості бізнес-застосунків. Плануйте пам'ять під HNSW-індекси, налаштуйте maintenance_work_mem для побудови й моніторте vacuum.

Чи зберігати вектори поруч із бізнес-даними? Часто так: це спрощує контроль доступу й join і тримає видалення узгодженими (видалення за GDPR має прибирати й вектори).

Скільки вимірів використовувати? Це визначає модель ембеддингів. Моделі з навчанням у стилі Matryoshka дозволяють обрізати виміри для економії пам'яті з невеликою втратою якості.

Чи можна змінити базу пізніше? Так, якщо шар пошуку схований за тонким інтерфейсом і ви зберігаєте сирий текст для переіндексації.

Джерела

Malkov, Y., Yashunin, D. (2016). Efficient and robust approximate nearest neighbor search using Hierarchical Navigable Small World graphs.
pgvector на GitHub.
Документація Qdrant, Weaviate, документація Milvus, документація Pinecone.
ANN-Benchmarks.
Cormack, G., Clarke, C., Buettcher, S. (2009). Reciprocal Rank Fusion outperforms Condorcet and individual Rank Learning Methods.
Douze et al. (2024). The Faiss library.