pgvector чи Qdrant — що self-host?

Якщо вже крутите Postgres (або хочете одну БД і під дані застосунку, і під ембединги) — pgvector найменш витратний, це просто розширення. Якщо у вас мільйони векторів або потрібен профільний рушій із швидкою фільтрацією — Qdrant вартий окремого сервісу. Для більшості агентів на старті pgvector на Postgres більш ніж достатньо.

Скільки RAM потрібно векторній БД?

Більше, ніж здається, бо хороший пошук хоче індекс у пам'яті. Грубо: пара сотень тисяч ембедингів комфортно в 2 ГБ; на низьких мільйонах закладайте 4 ГБ+ і тюньте індекс. Старт із 2 ГБ, стежте за пам'яттю, збільшуйте, коли пошук сповільниться.

Навіщо self-host векторне сховище, а не managed?

Дві причини, з яких це реально роблять: ембединги часто містять ваші приватні дані (нотатки, документи, клієнтський контент), і self-hosted сховище тримає це на сервері, який ви контролюєте. І це фікс-ціна — managed-сервіс бере за вектори й запити, а VPS — одне число на місяць без лічильника за запит.

Чи можуть векторна БД і агент жити на одному VPS?

Так, для малих-середніх навантажень — розмістити агента й pgvector/Qdrant на одній машині просто й ріже затримку майже в нуль. Розносьте по різних серверах, лише коли один починає відбирати RAM в іншого — це приємна проблема на потім, не турбота першого дня.

Ембединги їдять багато диска?

Один ембединг — пара кілобайт, тож мільйон — це кілька гігабайт плюс накладні індексу: відчутно, але не величезно. 25–45 ГБ диска покривають солідне сховище пам'яті для більшості агентів. RAM, не диск, зазвичай перший ліміт, у який упираєшся.

Власна векторна БД для пам'яті AI-агента на VPS

AI-агент без пам'яті приречений знову відрекомендовуватися щорозмови. Рішення — векторна БД: зберігає ембединги ваших документів, нотаток чи минулих чатів, щоб агент на запит згадував потрібні шматки (це «R» у RAG). Можна взяти managed-сервіс, а можна підняти самому на VPS і тримати дані — часто ваші приватні — на машині, яку контролюєте ви. Ось як, і що це реально коштує по RAM.

Два хороші варіанти

Нічого екзотичного не потрібно. Два шляхи покривають майже всіх:

pgvector — розширення Postgres. Якщо вже крутите Postgres (чи не проти) — воно додає векторний пошук у БД, що у вас уже є. Один сервіс, один бекап, знайомий SQL. Найненапружніший старт із великим відривом.

Qdrant — профільний векторний рушій. Беріть, коли багато векторів (низькі мільйони+) або потрібна швидка фільтрація за метаданими й окремий API. Це окремий сервіс, але він зроблений рівно під цю задачу.

Для більшості агентів, що стають на ноги, pgvector — правильна перша відповідь. До Qdrant переходьте, коли переросли, не раніше.

Реальність по RAM (це й недооцінюють)

Векторний пошук швидкий, бо індекс живе в пам'яті — тож RAM, не диск, ваше реальне обмеження. Грубий орієнтир:

Пара сотень тисяч ембедингів — комфортно в 2 ГБ.
Низькі мільйони — закладайте 4 ГБ+ і тюньте індекс.
Диск — легка частина: мільйон ембедингів це лише кілька ГБ, тож 25–45 ГБ покривають серйозне сховище.

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

Швидкий старт: pgvector

На машині з Postgres (Docker найпростіше — той самий патерн, що self-host n8n):

CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE memory (
  id bigserial PRIMARY KEY,
  content text,
  embedding vector(1536)        -- під розмірність вашої моделі ембедингів
);

-- коли з'являться дані, побудуйте індекс для швидкого пошуку:
CREATE INDEX ON memory USING hnsw (embedding vector_cosine_ops);

Агент вставляє content + його ембединг, потім запитує ORDER BY embedding <=> $query_embedding LIMIT 5, щоб дістати найближчі спогади. Це весь цикл.

Хочете Qdrant? Це один Docker-контейнер із HTTP/gRPC API; створюєте колекцію з розміром вектора й upsert'ите точки. Та сама ідея, профільний рушій.

Чи може він ділити машину з агентом?

Так — для малих-середніх сховищ запускайте векторну БД на тому самому VPS, що й агент. Простіше, і затримка майже нуль. Розносьте по різних серверах, лише коли один починає тіснити інший по RAM. Це пізня приємна проблема, не задача першого дня.

Чесні застереження

RAM — це стіна, і тиха. Пошук лишається швидким, поки індекс влазить у пам'ять, потім деградує. Стежте за пам'яттю й збільшуйте до того, як укусить — не чекайте повільних запитів як сигналу.
Ембединги коштують токенів. Кожен документ, що ви ембедите, — виклик API моделі ембедингів. Сховище дешево тримати; генерація векторів — повторюваний витрата, релевантно тому, що реально коштує тримати агента.
Бекапте. Пам'ять агента — дані як будь-які інші. Важливо — снапшотьте.

У цих межах self-hosted векторне сховище — чистий спосіб дати агенту міцну пам'ять, не віддаючи приватні дані третім. Старт із pgvector на 2 ГБ, стежте за RAM, і ростіть у Qdrant чи більший тариф, лише коли цифри скажуть.