Як обрати векторну базу даних: Qdrant, pgvector та критерії вибору

Компанія з 500 тис. фрагментів документів та наявним PostgreSQL стоїть перед питанням, яке ми ставимо собі регулярно: чи не простіше додати pgvector і закрити тему за два дні, чи одразу розгорнути Qdrant? Відповідь залежить від кількох критеріїв, які рідко зустрічаються разом в одній статті. Нижче ми зібрали їх в одному місці.

pgvector — це розширення PostgreSQL, яке додає тип даних vector та оператори подібності (L2, косинусна, скалярний добуток). Вектори зберігаються в тій самій базі, що й решта транзакційних даних (разом з таблицями клієнтів, замовлень та документів). Це велика операційна перевага: один бекап, одні права доступу, один моніторинг.

Спеціалізована векторна база даних (Qdrant, Weaviate, Milvus) — це окремий процес, розроблений виключно для зберігання та пошуку векторів. Її механізм індексування (зазвичай HNSW) оптимізований для наближеного пошуку сусідства (ANN) з дуже низькою латентністю навіть на десятках мільйонів векторів.

Різниця не є бінарною — це спектр компромісів. pgvector з версії 0.7.0 підтримує індекс HNSW (раніше лише IVFFlat), що значно зменшило розрив у продуктивності. При 100-200 тис. векторів та кількох запитах на секунду цей розрив сьогодні незначний.

Масштаб корпусу. pgvector з індексом HNSW добре тримається до приблизно 1-2 млн векторів на середньому сервері (16 ГБ ОЗП, 8 ядер). Вище цього порогу час побудови індексу та споживання пам'яті починають конкурувати з іншими навантаженнями бази. Qdrant керує пам'яттю на рівні колекцій і може зберігати частину індексу на диску (mmap), масштабуючись до сотень мільйонів векторів без заміни сервера.

Фільтрація метаданих (payload filtering). Це пункт, в якому pgvector найчастіше програє на практиці. Фільтрація WHERE category = 'hr' AND status = 'active' перед векторним пошуком у pgvector насправді є фільтром post-ANN або повним скануванням з фільтром pre-ANN. Обидва варіанти коштують ресурсів. Qdrant будує інвертовані індекси на полях payload і об'єднує їх зі шляхом HNSW, тому must: [{ key: "category", match: { value: "hr" } }] не сповільнює запит. Якщо ваш RAG має ізолювати фрагменти за відділом, клієнтом або рівнем доступу, фільтрація payload є критичним критерієм.

Гібридні запити (вектор + повнотекстовий пошук). pgvector не має вбудованого BM25; його потрібно складати з tsvector PostgreSQL і зливати результати вручну (RRF або власна логіка). Qdrant з версії 1.10 має вбудовану підтримку гібридного пошуку з reranking в рамках одного виклику API. Для систем, де користувачі вводять як природні запитання, так і номери документів чи коди, гібрид важливий. Деталі описані в статті про гібридний пошук BM25 та вектори.

Self-hosting vs SaaS та вимоги RODO. Обидва варіанти можна розгорнути на власному сервері. pgvector є частиною PostgreSQL, тому якщо у вас вже є on-prem база та політика зберігання, додавання розширення не змінює модель загроз. Qdrant Cloud (SaaS) вимагає договору доручення даних (ст. 28 RODO) та оцінки DPO щодо data-residency. Дані ембедінгів не є PII, але якщо payload містить вміст клієнтів, регіон зберігання має значення. Qdrant Community Edition, розгорнутий локально, має такий самий профіль RODO, як і pgvector на власному сервері. Більше про інфраструктуру, сумісну з RODO, у статті про self-hosted LLM та RODO.

Операційна складність та TCO. pgvector не додає нових компонентів до стеку: один сервіс, один бекап, одна команда. Qdrant — це окремий сервіс (контейнер або процес), власні метрики, власне оновлення. У невеликій команді без DevOps це реальна різниця: не лише вартість ліцензії, а й час підтримки. З іншого боку, Qdrant надає готові ендпоінти Prometheus та дашборди колекцій, що спрощує observability при великих обсягах.

pgvector має сенс, коли у вас вже є PostgreSQL у компанії, ваш корпус вміщується в 500 тис. – 1 млн фрагментів, запити прості (без складної фільтрації payload) і ви не хочете додавати новий компонент до інфраструктури. Впровадження зводиться до CREATE EXTENSION vector, додавання стовпця та побудови індексу HNSW. Команда може зробити це за один день. При такому обсязі латентність запитів становить 20-80 мс, що для більшості внутрішніх асистентів знань є абсолютно достатнім.

pgvector також є природним вибором для семантичного пошуку, коли персональні дані не можуть залишати транзакційну базу: ембедінги та payload залишаються в тому самому движку з тією ж моделлю прав доступу.

Сигнали, що настав час для Qdrant або іншої спеціалізованої бази:

• Корпус перевищує 2 млн фрагментів, а час побудови індексу HNSW у pgvector виходить за межі вікна обслуговування.
• Потрібна фільтрація payload перед пошуком ANN, наприклад, ізоляція клієнтів у системі multi-tenant, фільтри за статусом документа або рівнем доступу.
• Впроваджуєте гібридний пошук (вектор + BM25) і не хочете підтримувати окрему логіку злиття результатів.
• Хочете ізолювати колекції за продуктом або клієнтом без впливу на продуктивність запитів інших колекцій.
• Плануєте багато паралельних операцій запису (інкрементальна реіндексація щогодини) і не хочете, щоб вони навантажували основну транзакційну базу.

При масштабуванні понад 5-10 млн фрагментів спеціалізована база — практично єдиний розумний варіант. Детальніше про це в статті про підготовку корпоративних даних для AI.

Якщо ви починаєте з pgvector і через кілька місяців переростаєте поріг, міграція простіша, ніж здається. Вектори — це числа з плаваючою комою. Експорт з pgvector у формат JSON та імпорт до Qdrant — це питання одного ETL-скрипта. Схему payload потрібно зіставити один раз. Весь процес для 2 млн векторів займає 2-4 години. Шаблон dual-index (старий pgvector + новий Qdrant працюють паралельно, трафік переноситься поступово) мінімізує ризики, як і при міграції з API на власний модель AI.

Так, для наборів до 1-2 млн фрагментів та індексу HNSW (pgvector 0.7+) це повністю продакшн-рішення. Багато компаній впроваджують RAG саме на pgvector, оскільки це не вимагає нового компонента інфраструктури. Обмеження виникають при розширеній фільтрації payload та великому масштабі; у таких випадках варто оцінити Qdrant.

При 500 тис. векторів різниця незначна (обидва вкладаються в 20-60 мс на типовий сервер). При 5 млн векторів Qdrant з сегментами на диску (mmap) тримає 30-80 мс, тоді як pgvector може виходити на 200-500 мс при недостатньому обсязі ОЗП. Це сильно залежить від конфігурації сервера та параметрів ef_construction / m індексу HNSW.

Так, Qdrant Community Edition, розгорнутий on-premises, має такий самий профіль RODO, як і pgvector на власному сервері: дані не залишають інфраструктури, немає зворотної телеметрії до виробника (у стандартній конфігурації). Qdrant Cloud (SaaS) вимагає окремої оцінки data-residency та договору доручення. Ключовим є те, що в payload колекції не повинні міститися персональні дані у незашифрованому вигляді, незалежно від обраної бази.

Qdrant Community Edition — це програмне забезпечення з відкритим кодом без ліцензійних платежів. Витрати на впровадження — це час команди (1-3 дні на конфігурацію, інтеграцію API та тестування), сервер (при 2 млн векторів BGE-M3 1024-dim потрібно близько 8-12 ГБ ОЗП для індексу HNSW) та час підтримки. Для колекцій понад 10 млн векторів варто розглянути Qdrant Cloud або виділений сервер. Калькулятор загальної вартості впровадження можна знайти в калькуляторі ROI.

Так, і це має сенс в архітектурі, де транзакційні дані (короткі описи, метадані) зберігаються в pgvector, а великі колекції документів — у Qdrant. Шаблон dual-index також корисний при міграції: нові фрагменти потрапляють до Qdrant, старі залишаються в pgvector до повного реімпорту. Обидві системи можна опитувати паралельно та зливати результати через reranking.