Qdrant проти Chroma проти pgvector: вибір правильної векторної БД для self-hosted RAG

Qdrant проти Chroma проти pgvector: вибір правильної векторної БД для self-hosted RAG

Вибір між Qdrant, Chroma та pgvector зводиться до компромісу трьох підходів: швидкість спеціалізованого рішення, простота прототипування або робота всередині екосистеми Postgres. Кожен із цих підходів працює; питання лише в тому, який компроміс найкраще відповідає вашому RAG-пайплайну.

Короткий підсумок: яку векторну базу даних обрати?

Обирайте Qdrant, якщо вам потрібен векторний пошук рівня production із розширеною фільтрацією, підтримкою мультитенантності, і ви не проти запускати окремий сервіс.

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

Обирайте pgvector (+ pgvectorscale), якщо ви вже використовуєте PostgreSQL і хочете отримати векторний пошук без додавання нової інфраструктури, особливо тепер, коли індекс StreamingDiskANN від pgvectorscale скоротив розрив у продуктивності.

Якщо ви створюєте RAG-додаток з нуля, решта цієї статті допоможе вам обрати правильний фундамент.

Продуктивність: наскільки швидка кожна база даних?

Продуктивність стає важливою, коли ви виходите за межі кількох тисяч документів. Саме тут ці три рішення суттєво розходяться.

Qdrant

Qdrant створено з нуля спеціально для векторного пошуку. Його реалізація на Rust та власний індекс HNSW забезпечують стабільно низьку затримку; бенчмарки показують затримку запиту близько 94 мс навіть під конкурентним навантаженням. Він підтримує скалярну, бінарну та продуктову квантизацію для стиснення векторів і прискорення пошуку, зберігаючи повноту (recall) на рівні понад 95%.

Справжня сила Qdrant проявляється у фільтрованому пошуку. На відміну від баз даних, які спочатку знаходять найближчих сусідів, а потім фільтрують результати, фільтрований HNSW у Qdrant враховує обмеження метаданих під час обходу графа. Це означає, що ви не втрачаєте повноту при поєднанні векторного пошуку з фільтрами, такими як category = "technical" або date > 2025-01-01.

Chroma

Реліз 1.0 Chroma переписав ядро на Rust, що забезпечило в 3–5 разів швидший запис і запити порівняно з оригінальною реалізацією на Python. Подальше оновлення у серпні 2025 року додало кодування векторів у base64, що дало додаткове зростання пропускної здатності на 70%.

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

pgvector + pgvectorscale

Це «темна конячка». Звичайний pgvector з HNSW працює у 5250 разів швидше, ніж послідовне сканування, а pgvector 0.8.0 додав ітеративне сканування індексу, щоб вирішити проблему надмірної фільтрації, яка переслідувала попередні версії.

Але головна історія — це pgvectorscale. Розширення від Timescale додає індекс StreamingDiskANN, натхненний дослідженнями DiskANN від Microsoft, який зберігає індекс на диску, а не в оперативній пам'яті. У бенчмарку на 50 мільйонів ембедінгів Cohere (768 вимірів) pgvectorscale досяг 471 запитів за секунду (QPS) з повнотою 99%. Це в 11,4 раза вища пропускна здатність, ніж 41 QPS у Qdrant на тому ж рівні повноти, і в 28 разів нижча затримка p95, ніж у оптимізованому для зберігання індексі Pinecone.

Але є нюанс: ці бенчмарки проводилися на потужному екземплярі EC2. Ваші результати можуть відрізнятися залежно від обладнання. Однак тенденція очевидна: PostgreSQL більше не є варіантом «достатньо добре» для векторного пошуку, він справді конкурентоспроможний.

Вердикт: pgvector + pgvectorscale перемагає за сирими цифрами бенчмарків. Qdrant перемагає у продуктивності фільтрованого пошуку. Chroma достатньо швидкий для прототипів, але не створений для масштабування.

Налаштування та досвід розробника

Як швидко можна перейти від нуля до роботи з векторами?

Qdrant: Docker і Go

Qdrant потребує власного контейнера:

docker run -p 6333:6333 -v $(pwd)/qdrant_storage:/qdrant/storage qdrant/qdrant

Потім вставте вектори через REST API або один із офіційних SDK (Python, Rust, Go, TypeScript):

from qdrant_client import QdrantClient
from qdrant_client.models import VectorParams, Distance

client = QdrantClient(url="http://localhost:6333")
client.create_collection(
    collection_name="documents",
    vectors_config=VectorParams(size=1536, distance=Distance.COSINE),
)

Панель керування Qdrant за адресою localhost:6333/dashboard — приємний бонус: ви можете переглядати колекції, виконувати запити та візуально перевіряти пейлоади. Шлях від розробки до production чистий: ваша локальна конфігурація Docker працює ідентично на production-сервері або в Qdrant Cloud.

Chroma: pip install і готово

Chroma впевнено перемагає у гонці простоти:

import chromadb

client = chromadb.Client()  # In-memory, zero config
collection = client.create_collection("documents")
collection.add(
    documents=["Your RAG document here"],
    ids=["doc1"]
)

Ніякого Docker. Ніякого сервера. Він навіть автоматично генерує ембедінги, якщо ви не надаєте вектори самостійно. Для прототипу RAG ви можете перейти від pip install chromadb до працюючого пошуку менш ніж за 10 рядків коду.

Коли вам знадобиться збереження даних, перейдіть на `chromadb.PersistentClient(path="./chroma_data")". Для багатопроцесного або мережевого доступу Chroma має серверний режим, але на цьому етапі ви починаєте втрачати перевагу простоти.

pgvector: суцільний SQL

Якщо Postgres уже є у вашому стеку, pgvector додається одним рядком:

CREATE EXTENSION vector;

CREATE TABLE documents (
  id SERIAL PRIMARY KEY,
  content TEXT,
  embedding vector(1536)
);

CREATE INDEX ON documents USING hnsw (embedding vector_cosine_ops);

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

Додавання pgvectorscale поверх цього є простим, якщо ви використовуєте Docker-образ від Timescale або керованого провайдера Postgres, який його підтримує:

CREATE EXTENSION vectorscale;
CREATE INDEX ON documents USING diskann (embedding);

Недолік? SQL не такий зручний, як DSL для фільтрації пейлоадів у Qdrant або Python-подібний API Chroma. І вам потрібно буде керувати власним пайплайном ембедінгів, оскільки pgvector не генерує їх за вас.

Вердикт: Chroma перемагає у швидкості створення прототипу. pgvector перемагає, якщо Postgres уже є у вашому стеку. Qdrant має найкращий баланс між зручністю розробки (DX) та готовністю до production.

Масштабування та готовність до production

Прототипування — це одне. Запуск RAG-пайплайну, який обробляє мільйони векторів зі стабільною затримкою, — зовсім інше.

Qdrant: створений для горизонтального масштабування

Qdrant підтримує горизонтальне шардування «з коробки». Ви можете розподіляти колекції між кількома вузлами з настроюваними факторами реплікації для високої доступності. Дорожня карта на 2026 рік включає розділення читання/запису та інтеграцію блочного сховища для ще кращого масштабування.

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

Операційна частина солідна: вбудовані резервні копії, ендпоінти метрик для Prometheus та відновлення після збоїв на основі WAL. Qdrant розроблено для self-hosted використання у production.

Chroma: стеля односерверної архітектури

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

Chroma Cloud став загальнодоступним на початку 2026 року як serverless-варіант із керованим розподіленим середовищем, тож ви можете перекласти горизонтальне масштабування на нього, замість того щоб робити це самостійно. Але історія self-hosted open-source версії все ще зводиться до принципу «один сервер, один екземпляр Chroma». Якщо ваш набір даних поміщається на одному комп'ютері (до кількох мільйонів векторів залежно від розмірності), це нормально. За межами цього self-hosted Chroma впирається в стіну, і вам доведеться обирати між Chroma Cloud та міграцією.

pgvector: масштабується разом із Postgres

pgvector успадковує перевірену часом стратегію масштабування PostgreSQL. Ви отримуєте репліки читання, пул з'єднань через PgBouncer та логічну реплікацію. Керовані провайдери, такі як Neon та подібні serverless-платформи Postgres, роблять вертикальне масштабування майже беззусильним.

Індекс StreamingDiskANN від pgvectorscale є ключем до масштабування. Оскільки він зберігає індекс на диску (SSD), а не в RAM, ви можете обробляти набори даних, які інакше вимагали б дорогих екземплярів із великим обсягом пам'яті. На 50 мільйонах векторів він уже конкурентоспроможний зі спеціалізованими векторними базами даних.

Обмеженням є горизонтальне шардування. PostgreSQL не має нативного шардування, як у Qdrant. Існують рішення на кшталт Citus, але вони додають складності. Для більшості self-hosted RAG-навантажень менше 100 млн векторів вертикального масштабування з pgvectorscale цілком достатньо.

Вердикт: Qdrant перемагає у горизонтальному масштабуванні та мультитенантності. pgvector перемагає завдяки використанню наявної інфраструктури Postgres. Chroma не призначений для production-масштабів.

Вартість self-hosting

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

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

Використання ресурсів Qdrant є ефективним для його набору функцій, але це окремий сервіс, тому вам потрібно враховувати операційні витрати на запуск і моніторинг ще одного елементу інфраструктури.

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

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

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

Фільтрація та гібридний пошук

RAG — це не просто «знайти найближчий вектор». Вам потрібно поєднувати пошук за схожістю з фільтрами метаданих, діапазонами дат, контролем доступу, а іноді й ключовими словами.

Qdrant: король фільтрації

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

DSL для фільтрації є виразним:

from qdrant_client.models import Filter, FieldCondition, MatchValue

results = client.search(
    collection_name="documents",
    query_vector=embedding,
    query_filter=Filter(
        must=[
            FieldCondition(key="category", match=MatchValue(value="engineering")),
            FieldCondition(key="year", range=Range(gte=2024)),
        ]
    ),
    limit=10,
)

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

Chroma: базовий, але придатний до використання

Chroma підтримує фільтрацію метаданих за допомогою умов where:

results = collection.query(
    query_embeddings=[embedding],
    where={"category": "engineering"},
    n_results=10,
)

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

pgvector: SQL — ваша суперсила

pgvector успадковує всю потужність SQL для фільтрації:

SELECT content, embedding <=> $1 AS distance
FROM documents
WHERE category = 'engineering'
  AND created_at > '2024-01-01'
  AND content @@ to_tsquery('RAG & retrieval')
ORDER BY distance
LIMIT 10;

Останній рядок поєднує векторну схожість із вбудованим повнотекстовим пошуком PostgreSQL в одному запиті. Жодного зовнішнього пошукового двигуна не потрібно. Ви можете робити join із таблицею користувачів для контролю доступу, агрегувати результати, використовувати CTE — будь-що, що вміє SQL.

Ітеративне сканування у pgvector 0.8.0 також допомагає. Якщо початкове сканування HNSW не повертає достатньо фільтрованих результатів, воно автоматично продовжує пошук, а не повертає частковий набір.

Вердикт: Qdrant перемагає у складній фільтрації метаданих у великих масштабах. pgvector перемагає у гнучкості гібридного пошуку (SQL + повнотекстовий пошук + вектори в одному запиті). Фільтрація Chroma adequate лише для прототипів.

Коли використовувати кожне:框架 прийняття рішень

Ось версія у вигляді дерева рішень: Чи використовує ваш додаток вже Postgres? Якщо так, почніть з pgvector, ви завжди можете мігрувати пізніше, якщо переростете його. Якщо ні, ви займаєтеся прототипуванням або будуєте для production? Для прототипування обирайте Chroma. Для production — Qdrant.

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

Фактор pgvectorscale: чому Postgres наздоганяє конкурентів

Цього варто детальніше торкнутися, оскільки це змінює розрахунки для багатьох команд.

До появи pgvectorscale головним недоліком pgvector завжди було твердження: «це добре працює з менш ніж мільйоном векторів, але не масштабується». Це було правдою. Індекси HNSW повністю перебувають у RAM, і коли ваш набір даних перевищує доступну пам'ять, продуктивність різко падає.

StreamingDiskANN змінює рівняння. Зберігаючи графовий індекс на SSD замість RAM, pgvectorscale обробляє 50 мільйонів векторів зі швидкістю 471 QPS з повнотою 99%. Статистична бінарна квантизація (SBQ) стискає вектори з мінімальною втратою точності: повнота знижується з 98,6% до 96,5% навіть при агресивному стисненні.

Практичний вплив: команда, яка запускає RAG-пайплайн на Postgres, більше не потребує планування міграції на спеціалізовану векторну базу даних «коли справи стануть серйозними». Для багатьох навантажень pgvector + pgvectorscale є серйозним варіантом.

Тим не менш, pgvectorscale не є панацеєю. Це розширення від TigerData (раніше Timescale), тому вам потрібен або їхній Docker-образ, або провайдер, який його постачає. Реліз 2026 року додав фільтрований векторний пошук на основі міток до StreamingDiskANN, натхненний дослідженнями Filtered DiskANN від Microsoft, що звужує давню перевагу Qdrant у фільтрованих запитах. Але якщо вам потрібна ізоляція мультитенантності або нативна підтримка розріджених векторів, Qdrant все ще має перевагу.

Як Techsy підходить до вибору векторної бази даних

Коли ми будуємо RAG-пайплайни для клієнтів, наш процес оцінки виглядає так:

1. Аудит наявного стеку. Якщо команда вже використовує Postgres, pgvector є стандартною відправною точкою. Немає сенсу додавати складність інфраструктури без чіткої причини.
2. Профілювання шаблонів запитів. Важка фільтрація метаданих з полями високої кардинальності? Це схиляє вибір до Qdrant. Простий семантичний пошук? pgvector або Chroma цілком підійдуть.
3. Оцінка траєкторії масштабування. Менше 5 млн векторів і залишатиметься так? Будь-який варіант працює. Плануєте 50 млн+? pgvectorscale або Qdrant, залежно від пункту 2.
4. Перевірка операційних можливостей команди. Стартапу з двох осіб не слід керувати кластером Qdrant. Керований провайдер Postgres з pgvector зазвичай є правильним вибором.

Ми побудували production-системи RAG з усіма трьома рішеннями. Чесна відповідь полягає в тому, що вибір бази даних має менше значення, ніж ваша стратегія чанкінгу, модель ембедінгів та дизайн пайплайну отримання даних. Якщо ви витрачаєте більше часу на дебати Qdrant проти pgvector, ніж на тестування різних розмірів чанків, ви оптимізуєте не те, що треба.

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

Поширені запитання

Чи достатньо хороший pgvector для production RAG?

Так, особливо з pgvectorscale. Індекс StreamingDiskANN обробляє 50 млн+ векторів з повнотою 99% на рівнях пропускної здатності, які в бенчмарках перевершують спеціалізовані векторні бази даних. Якщо ви вже використовуєте Postgres, рідко є причина додавати окрему векторну базу даних для RAG.

Чи може Chroma масштабуватися до мільйонів векторів?

Chroma може обробляти кілька мільйонів векторів на одному вузлі за наявності достатньої кількості RAM, але він не має вбудованого горизонтального масштабування. Для наборів даних, більших за те, що може вмістити одна машина, вам доведеться мігрувати на Qdrant, pgvector або керований сервіс.

Чи підтримує Qdrant гібридний пошук з ключовими словами?

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

Скільки RAM потрібно для кожної бази даних?

Це залежить від кількості векторів та їх розмірності. Як орієнтовний показник: 1 млн векторів із 1536 вимірами займає близько 6 ГБ у Qdrant або pgvector з HNSW. Chroma використовує трохи більше через накладні витрати Python. Індекс DiskANN від pgvectorscale різко знижує потреби в RAM, зберігаючи індекс на SSD.

Чи можна пізніше мігрувати між цими базами даних?

Так. Усі три працюють зі стандартними масивами float, тому вектори є портативними. Вам потрібно буде повторно створити індекси та адаптувати шар запитів, але це міграція даних, а не переписування. Більшість інструментів міграції, таких як офіційний інструмент міграції Qdrant, спрощують цей процес.

Який із них найкраще працює з LangChain та LlamaIndex?

Усі три мають офіційні інтеграції з LangChain та LlamaIndex. Chroma часто є варіантом за замовчуванням у туторіалах, що робить його найзручнішим для початку. Інтеграції Qdrant та pgvector однаково зрілі для використання у production. Перегляньте наш посібник щодо найкращих інструментів RAG для ширшого огляду екосистеми.

Чи варто використовувати pgvector чи pgvectorscale?

Використовуйте обидва. pgvector надає основний тип vector та індекс HNSW. pgvectorscale додає поверх нього StreamingDiskANN для кращої продуктивності при масштабуванні. Це взаємодоповнюючі розширення, а не альтернативи.

Чи є Qdrant безкоштовним для self-hosting?

Повністю безкоштовний за ліцензією Apache 2.0. Qdrant Cloud — це платний керований варіант, який починається з безкоштовного тарифу на 1 ГБ. Для self-hosting ви платите лише за обчислювальну інфраструктуру.

А як щодо Milvus або Weaviate?

Обидва є солідними альтернативами. Milvus сильніший у дуже великих масштабах (мільярди+ векторів) з прискоренням на GPU. Weaviate має гарний вбудований пайплайн векторизації. Але для self-hosted RAG менше 100 млн векторів Qdrant, Chroma та pgvector покривають переважну більшість випадків використання з меншою операційною складністю.

Чи може pgvector обробляти конкурентні RAG-запити у production?

Так. PostgreSQL створено для конкурентних навантажень. pgvector успадковує пул з'єднань (PgBouncer), репліки читання та контроль конкурентності MVCC. Для RAG з високою пропускною здатністю поєднуйте pgvector із пулером з'єднань та налаштуйте shared_buffers і effective_cache_size.

Остаточний вердикт

Загалом: Для більшості self-hosted RAG-пайплайнів pgvector + pgvectorscale є прагматичним вибором. Він достатньо швидкий, масштабується до десятків мільйонів векторів і зберігає простоту вашого стеку. Ви вже знаєте SQL. Ваша команда вже керує Postgres. Один сервіс менше означає одну річ менше, яка може зламатися о 2-й ночі.

Якщо вам потрібен розширений фільтрований пошук, мультитенантність або ви будуєте продукт, де векторний пошук є основною функцією (а не допоміжною можливістю), Qdrant є правильною інвестицією. Це найбільш функціональна open-source векторна база даних не просто так.

Chroma заслуговує свого місця як інструмент для прототипування. Використовуйте його, щоб перевірити свій підхід до RAG, протестувати різні стратегії чанкінгу та ітеративно покращувати якість отримання даних. Коли будете готові до production, мігруйте на той із двох інших варіантів, який найкраще підходить вашому стеку.

Найкраща порада? Припиніть дебати і почніть будувати. Обирайте pgvector, якщо у вас є Postgres, Qdrant, якщо ні, і змусьте ваш RAG-пайплайн працювати. Ви завжди можете змінити векторне сховище пізніше; модель ембедінгів, стратегія чанкінгу та логіка отримання даних мають набагато більше значення.

Джерела

• Бенчмарки Qdrant
• Реліз Chroma 1.0: у 4 рази швидше
• pgvectorscale: StreamingDiskANN для PostgreSQL
• pgvector тепер швидший за Pinecone при витратах на 75% менших
• pgvector 0.8.0: Ітеративне сканування індексу
• Ціни Qdrant