pgvector নাকি Qdrant — কোনটি সেলফ-হোস্ট করব?

আপনি ইতিমধ্যেই Postgres চালালে (বা আপনার app ডেটা ও embedding দুটোর জন্য একটি database চাইলে), pgvector সবচেয়ে কম-শ্রমের পছন্দ — এটি কেবল একটি extension। আপনার মিলিয়ন-মিলিয়ন vector থাকলে বা দ্রুত filtering সহ একটি purpose-built engine চাইলে, Qdrant আলাদা সার্ভিসের যোগ্য। শুরু করা বেশিরভাগ agent-এর জন্য, Postgres-এ pgvector যথেষ্ট।

একটি vector database-এর কত RAM দরকার?

আপনার আঁচের চেয়ে বেশি, কারণ ভালো search চায় index memory-তে থাকুক। একটি মোটামুটি নিয়ম: কয়েক লক্ষ embedding 2 GB-তে আরামে বসে; একবার কয়েক মিলিয়নে পৌঁছালে, 4 GB+ ধরুন ও index tune করুন। 2 GB-তে শুরু করুন, memory দেখুন, search ধীর হলে resize করুন।

একটি managed-এর বদলে একটি vector store সেলফ-হোস্ট কেন?

মানুষ আসলে দুটি কারণে করে: আপনার embedding প্রায়ই আপনার প্রাইভেট ডেটা ধারণ করে (নোট, নথি, গ্রাহক-কনটেন্ট), আর একটি সেলফ-হোস্টেড store তা আপনার নিয়ন্ত্রিত একটি সার্ভারে রাখে। আর এটি flat-খরচ — একটি managed vector সার্ভিস vector ও query অনুযায়ী বিল করে, যেখানে একটি VPS কোনো per-query মিটার ছাড়া একটি মাসিক সংখ্যা।

একটি vector DB ও আমার agent কি একই VPS-এ চলতে পারে?

হ্যাঁ, ছোট থেকে মাঝারি workload-এর জন্য — একটি বক্সে agent ও একটি pgvector/Qdrant ইনস্ট্যান্স co-locate করা সরল ও latency প্রায়-শূন্যে নামায়। শুধু তখনই এদের আলাদা সার্ভারে ভাগ করুন যখন একটি অন্যটিকে RAM-এর জন্য অভুক্ত করতে শুরু করে, যা পরের একটি ভালো-সমস্যা, প্রথম-দিনের চিন্তা নয়।

embedding কি অনেক ডিস্ক নেয়?

একটি একক embedding কয়েক কিলোবাইট, তাই এক মিলিয়ন কয়েক গিগাবাইট plus index overhead — অর্থপূর্ণ কিন্তু বিশাল নয়। 25–45 GB ডিস্ক বেশিরভাগ agent-এর জন্য একটি উল্লেখযোগ্য memory store কভার করে। RAM, ডিস্ক নয়, সাধারণত আপনার প্রথম ঠেকা সীমা।

একটি VPS-এ AI agent memory-র জন্য একটি vector database হোস্ট করুন

memory ছাড়া একটি AI agent প্রতিটি কথোপকথনে নিজেকে পুনঃপরিচয় করাতে আটকে থাকে। সমাধান একটি vector database — এটি আপনার নথি, নোট বা অতীত chat-এর embedding সঞ্চয় করে যাতে agent চাহিদামতো প্রাসঙ্গিক অংশ মনে করতে পারে (সেটাই RAG-এর "R")। আপনি এটি একটি managed সার্ভিস হিসেবে ভাড়া নিতে পারেন, বা এটি নিজে একটি VPS-এ চালাতে ও আপনার ডেটা — যা প্রায়ই আপনার প্রাইভেট ডেটা — আপনার নিয়ন্ত্রিত একটি বক্সে রাখতে পারেন। এই যে কীভাবে, আর RAM-এ এর আসল খরচ কত।

দুটি ভালো বিকল্প

আপনার বিদেশি-বিচিত্র কিছু লাগে না। দুটি পথ প্রায় সবাইকে কভার করে:

pgvector — একটি Postgres extension। আপনি ইতিমধ্যেই Postgres চালালে (বা চালাতে খুশি হলে), এটি আপনার ইতিমধ্যে থাকা database-এ vector search যোগ করে। একটি সার্ভিস, একটি backup, আপনার জানা SQL। বহু ব্যবধানে সবচেয়ে কম-শ্রমের শুরু।

Qdrant — একটি purpose-built vector engine। আপনার অনেক vector (কয়েক মিলিয়ন+) থাকলে বা দ্রুত metadata filtering ও একটি dedicated API চাইলে এর দিকে হাত বাড়ান। এটি চালানোর একটি আলাদা সার্ভিস, কিন্তু ঠিক এই কাজের জন্য বানানো।

পায়ের নিচে মাটি খোঁজা বেশিরভাগ agent-এর জন্য, pgvector-ই সঠিক প্রথম উত্তর। এটি ছাড়িয়ে গেলে Qdrant-এ যান, তার আগে নয়।

RAM-এর বাস্তবতা (এই অংশটা মানুষ কম আঁচ করে)

Vector search দ্রুত কারণ index memory-তে থাকে — তাই RAM, ডিস্ক নয়, আপনার আসল বাধা। একটি মোটামুটি নির্দেশিকা:

কয়েক লক্ষ embedding — 2 GB-তে আরামদায়ক।
কয়েক মিলিয়ন — 4 GB+ ধরুন ও index tune করুন।
ডিস্ক সহজ অংশ: এক মিলিয়ন embedding কেবল কয়েক GB, তাই 25–45 GB একটি গুরুতর store কভার করে।

তাই ফাইলের জন্য নয়, index-এর জন্য size করুন। (সাধারণ sizing গাইড-এর একই যুক্তি — ভারী জিনিসটা মাপা পর্যন্ত স্পষ্ট নয়।)

দ্রুত শুরু: pgvector

Postgres সহ একটি বক্সে (Docker সবচেয়ে সহজ — n8n সেলফ-হোস্টিং-এর একই প্যাটার্ন):

CREATE EXTENSION IF NOT EXISTS vector;

CREATE TABLE memory (
  id bigserial PRIMARY KEY,
  content text,
  embedding vector(1536)        -- আপনার embedding মডেলের dimension মেলান
);

-- ডেটা পাওয়ার পরে, দ্রুত search-এর জন্য একটি index বানান:
CREATE INDEX ON memory USING hnsw (embedding vector_cosine_ops);

আপনার agent content + এর embedding insert করে, তারপর নিকটতম memory টানতে ORDER BY embedding <=> $query_embedding LIMIT 5 দিয়ে query করে। ওটাই পুরো loop।

Qdrant পছন্দ? এটি একটি HTTP/gRPC API উন্মুক্ত করা একটি একক Docker container; আপনি আপনার vector আকার সহ একটি collection তৈরি করেন ও point upsert করেন। একই ধারণা, dedicated engine।

এটি কি agent-এর সাথে একটি বক্স শেয়ার করতে পারে?

হ্যাঁ — ছোট-থেকে-মাঝারি memory store-এর জন্য, vector DB-কে agent-এর একই VPS-এ চালান। এটি সরলতর ও latency মূলত শূন্য। শুধু তখনই এদের আলাদা সার্ভারে ভাগ করুন যখন একটি অন্যটিকে RAM থেকে ভিড় করে বের করতে শুরু করে। সেটি পরের, ভালো-সমস্যা-থাকার সিদ্ধান্ত, প্রথম-দিনের নয়।

সৎ সতর্কতা

RAM-ই দেয়াল, আর এটি নীরব। index memory-তে না-আঁটা পর্যন্ত search দ্রুত থাকে, তারপর অবনতি হয়। memory দেখুন ও এটি কামড় দেওয়ার আগে resize করুন — ধীর query আপনাকে বলার অপেক্ষা করবেন না।
embedding তৈরিতে token খরচ হয়। আপনি যে প্রতিটি নথি embed করেন তা একটি embedding মডেলে একটি API call। store হোস্ট করা সস্তা; vector তৈরি করাই বারবার-খরচ — একটি agent চালানোর আসল খরচ-এর সাথে প্রাসঙ্গিক।
এটি backup করুন। আপনার agent-এর memory অন্য যেকোনো কিছুর মতো ডেটা। এটি গুরুত্বপূর্ণ হলে, snapshot করুন।

এর মধ্যে, একটি সেলফ-হোস্টেড vector store আপনার প্রাইভেট ডেটা একটি তৃতীয় পক্ষকে না-দিয়ে একটি agent-কে টেকসই memory দেওয়ার একটি পরিচ্ছন্ন উপায়। একটি 2 GB বক্সে pgvector দিয়ে শুরু করুন, RAM-এ নজর রাখুন, ও সংখ্যা বললেই কেবল Qdrant বা একটি বড় প্ল্যানে বেড়ে উঠুন।