Векторна база для бізнесу: як порівняти pgvector, Qdrant, Pinecone і Chroma

Відправна точка вибору залежить від того, що у вас уже є. Якщо компанія працює з PostgreSQL, розумно спершу перевірити pgvector. Якщо потрібен окремий сервіс для векторного пошуку, варто розглянути Qdrant. Якщо команда хоче керований сервіс без власного сервера, Pinecone. Якщо потрібно швидко почати локально, з можливістю пізніше перейти на сервер чи хмару, Chroma.

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

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

Спершу вимоги

Векторна база зберігає числові представлення фрагментів тексту (ембединги) і швидко знаходить найближчі до запиту. Ця функція є в усіх чотирьох кандидатів. Різниця в тому, що навколо неї.

Розмір корпусу. Скільки фрагментів буде в базі зараз і через рік. Від цього залежать вимоги до пам'яті, індексів і масштабування. Важливий не лише поточний обсяг, а й темп зростання.

Фільтри. Чи шукатимете ви лише за схожістю, чи ще й з умовами: документи певного відділу, лише чинні версії, лише документи, доступні цьому працівнику. Для корпоративної бази знань фільтри майже завжди потрібні, і саме з ними бази поводяться по-різному.

Ізоляція орендарів. Якщо в одній базі зберігаються дані кількох клієнтів чи підрозділів, як гарантувати, що запит одного не побачить дані іншого. Це питання і безпеки, і архітектури.

Оновлення. Як часто змінюються документи, як швидко зміни мають потрапляти в пошук, як видаляються застарілі версії.

Резервування і відновлення. Як робиться резервна копія, як з неї відновитися і скільки часу це займе. Перевіряти треба саме відновлення, а не лише наявність копій.

Закритий контур. Чи можуть дані виходити за межі вашої інфраструктури. Якщо ні, керовані хмарні сервіси відпадають або потребують окремого режиму розгортання.

Команда. Хто встановлюватиме, оновлюватиме і моніторитиме базу. Власний сервер дає контроль, але потребує людини, яка за ним доглядає.

pgvector

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

Головна перевага. Якщо PostgreSQL уже є в компанії, не потрібен окремий сервіс: ті самі доступи, ті самі процедури резервування, та сама команда. Фільтр за відділом чи датою документа є звичайною умовою WHERE у SQL.

Пошук. pgvector підтримує точний і наближений пошук найближчих сусідів. Без наближеного індексу точний пошук дає еталонний top-k найближчих векторів за обраною метрикою й фільтрами. Це не гарантує змістовної релевантності: вона залежить також від ембедингів і підготовки документів. Для прискорення є два типи індексів:

• HNSW будує багаторівневий граф. Дає кращий баланс швидкості і повноти пошуку, але будується повільніше і використовує більше пам'яті. Його можна створити на порожній таблиці.
• IVFFlat ділить вектори на списки. Зазвичай будується швидше і використовує менше пам’яті, але має інший компроміс швидкості та повноти. Порівнюйте індекси за однакової цільової повноти й ресурсів. Його створюють після того, як у таблиці вже є дані, і ретельно підбирають параметри для хорошої повноти.

Що перевірити. Найважливіше застереження стосується фільтрів. За документацією, наближені індекси застосовують фільтр після сканування індексу, тому запит з умовою може повернути менше рядків, ніж очікувалося. Для цього є ітеративне сканування індексу, а також часткові індекси (для невеликої кількості значень фільтра) і партиціювання (для великої). Для кількох орендарів документація пропонує партиціювання за списком або окремі таблиці.

Вплив на чинну базу. Побудова HNSW-індексу значно швидша, коли граф вміщується в maintenance_work_mem, але документація застерігає не ставити це значення так високо, щоб вичерпати пам'ять сервера. Якщо векторний пошук розміщується на тому самому сервері, що й облікова система, перевірте, як побудова індексів і пошукові запити впливають на основне навантаження. Іноді правильне рішення: та сама технологія, але окремий екземпляр PostgreSQL.

Резервування. pgvector використовує журнал попереднього запису (WAL) PostgreSQL, тому підтримує реплікацію і відновлення на момент часу. Тобто працюють наявні процедури компанії.

Обмеження розмірності. Для типу vector індексувати можна вектори до 2 000 вимірів. Для більших розмірностей документація пропонує інші типи, наприклад halfvec з половинною точністю, до 4 000 вимірів. Перевірте розмірність ембедингів вашої моделі до вибору.

Qdrant

Qdrant є спеціалізованою системою векторного пошуку з клієнт-серверною архітектурою. Дані зберігаються в колекціях точок, кожна з яких має вектор і необов'язкові метадані (payload). Підтримуються щільні і розріджені вектори та гібридний пошук, що поєднує семантичний і лексичний.

Фільтрація. Індекси за полями метаданих, за документацією, розширюють HNSW-граф, дозволяючи застосовувати умови фільтра під час семантичного пошуку, а не після нього. Для бази знань з багатьма умовами доступу це суттєва архітектурна відмінність, яку варто перевірити на ваших фільтрах.

Варіанти розміщення. Документація перелічує чотири: власне розгортання версії з відкритим кодом, керовану хмару Qdrant, гібридну хмару з розділеною відповідальністю на ваших кластерах і приватну хмару з повним володінням. Це дає шлях від власного сервера до керованого сервісу без зміни технології.

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

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

Pinecone і Chroma

Ці два варіанти часто протиставляють як «хмарний сервіс» і «локальну бібліотеку». Обидва описи неповні.

Pinecone

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

Ізоляція. Простори імен (namespaces) розділяють дані різних орендарів в одному індексі.

Експлуатація. Головна відмінність від власного сервера в тому, хто відповідає за інфраструктуру. Документація згадує резервні копії індексів, виділені вузли для стабільно високого навантаження і варіант Bring Your Own Cloud, тобто розгортання у власному хмарному обліковому записі клієнта. Для компанії без інфраструктурної команди це суттєва перевага. Для закритого контуру треба окремо перевірити, чи підходить вам будь-який з доступних варіантів розміщення.

Chroma

Chroma є інфраструктурою даних для ШІ з відкритим кодом за ліцензією Apache 2.0. Документація описує три способи роботи: локально, у власному розгортанні або в Chroma Cloud як керованому безсерверному сервісі. Серед можливостей: щільний, розріджений і гібридний пошук, пошук за ключовими словами і регулярними виразами без ембедингів, фільтрація за метаданими і пошук по зображеннях та інших модальностях.

Огляд описує можливості продукту загалом: доступність кожного типу пошуку потрібно звірити для конкретної версії та режиму. Можливість Chroma Cloud не слід автоматично приписувати локальній інсталяції. Тому описувати Chroma лише як інструмент для прототипу на ноутбуці некоректно. Її сильна сторона в тому, що почати можна дуже швидко і локально, а потім перейти на сервер чи в хмару. Але, як і для будь-якої бази, вимоги продуктивної експлуатації (резервування, права, моніторинг, навантаження) треба перевірити для того режиму, який ви плануєте використовувати, а не для того, у якому робили прототип.

Порівняльна таблиця

Таблиця описує, що перевіряти для кожного варіанта. Колонки затримки і ціни немає навмисно: без однакового вимірювання на ваших даних такі цифри вводять в оману.

Механізм розділення даних сам по собі не замінює авторизацію. Сервер має визначати дозволений tenant, namespace або фільтр із перевіреної особи користувача, а не довіряти значенню з клієнтського запиту. Окремо перевірте спроби читання й зміни чужих даних; це вимога до вашої системи для будь-якої з чотирьох баз.

Як чесно тестувати

Порівняння векторних баз легко зробити несправедливим. Щоб результат щось означав, однаковими мають бути шість речей.

Ембединги. Та сама модель ембедингів, ті самі вектори. Якщо одна база створює ембединги сама, а для іншої ви рахуєте їх окремо, ви порівнюєте моделі, а не бази.

Запити. Однаковий набір реальних запитів користувачів, а не синтетичні випадкові вектори.

Фільтри. Ті самі умови, які будуть у робочій системі: відділ, статус документа, права доступу. Тест без фільтрів може показати зовсім іншу картину, ніж робота з ними.

Якість пошуку. Спочатку виміряйте ANN recall@k: яку частку еталонних top-k сусідів за тією самою метрикою й фільтрами повернув наближений індекс. Точний пошук pgvector може дати такий еталон. Потім окремо перевірте змістовну релевантність за відповідями фахівців і якість кінцевих відповідей моделі. Найближчий вектор не обов’язково є потрібним бізнес-документом.

Навантаження. Реалістична кількість одночасних запитів і одночасні оновлення даних. База, швидка на порожньому сервері, може поводитися інакше під час переіндексації.

Конфігурація. Порівнянні ресурси і налаштування індексів. Параметри HNSW чи IVFFlat суттєво впливають і на швидкість, і на повноту, тому записуйте їх поруч з результатами.

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

Рішення і план міграції

Вибір бази не остаточний на роки. Але міграція дешевша, якщо її спланувати до старту.

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

Зберігайте джерело окремо. Тримайте вихідні тексти фрагментів, метадані і версію моделі ембедингів у власному сховищі, незалежно від векторної бази. Тоді переїзд можливий навіть без вивантаження векторів: базу можна перебудувати з нуля. Це ж знадобиться при зміні моделі ембедингів, коли вектори все одно доведеться перерахувати.

Відновлення. Відновіть базу з резервної копії на тестовому середовищі ще до запуску. Запишіть, скільки це зайняло і що довелося робити вручну.

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

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

Що зробити найближчим часом:

1. Запишіть вимоги: обсяг і зростання, фільтри, ізоляцію орендарів, частоту оновлень, резервування, закритий контур, команду.
2. За таблицею оберіть одного-двох кандидатів, які відповідають наявній інфраструктурі.
3. Проведіть тест на однакових ембедингах, реальних запитах і робочих фільтрах, з точним пошуком як еталоном повноти.
4. Перевірте відновлення з резервної копії в обраному режимі розгортання.
5. Налаштуйте окреме зберігання вихідних текстів, метаданих і версії моделі ембедингів.
6. Запишіть процедуру вивантаження і переїзду, поки система ще невелика.

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