pgvector: چرا دیتابیس فعلی شما بهترین گزینه برای ذخیره بردارهاست

اگر امروز در حال طراحی یک سامانه تولید بازیابی‌افزا (RAG) هستید، احتمالاً اولین فکرتان خرید یا راه‌اندازی یک دیتابیس برداری تخصصی است. اما حقیقت این است که برای اکثر تیم‌های توسعه، همان دیتابیس PostgreSQL فعلی، بهینه‌ترین نقطه برای شروع است.

طبق یک راهنمای فنی که در ۲ اکتبر ۲۰۲۶ منتشر شد، pgvector با یک دستور ساده، یک دیتابیس استاندارد را به یک ذخیره‌ساز برداری تبدیل می‌کند. این یعنی دیگر نیازی نیست داده‌ها را بین دو سامانه مختلف همگام‌سازی کنید و با ریسک‌های ناسازگاری مواجه شوید.

برای بسیاری از برنامه‌نویسان، اضافه کردن یک دیتابیس برداری مجزا، کابوس «نوشتن دوگانه» (dual-write) و خطرات مربوط به سازگاری نهایی (eventual consistency) را به همراه می‌آورد. تصور کنید تمام متن سند و بردار معنایی (Embedding) — که مثل یک کارت معرفی عددی برای هر واژه است و می‌گوید این کلمه همسایه چه کلمات دیگری است — در یک تراکنش واحد و اتمیک ذخیره شوند. این سادگی، برتری اصلی یک افزونه در برابر ابزارهای مستقل است.

زمینه و ادغام

به دلیل ماهیت افزونه‌ای، pgvector تمام اکوسیستم Postgres را به ارث می‌برد؛ این شامل تراکنش‌های ACID، سیستم‌های پشتیبان‌گیری، ابزارهای مانیتورینگ، کنترل دسترسی و رپلیکاهای خواندنی (read replicas) است. در محیط‌های چندمستاجری (multi-tenant)، توسعه‌دهندگان می‌توانند از امنیت سطح ردیف (RLS) برای جداسازی کامل داده‌های هر کاربر استفاده کنند.

همان‌طور که در تحلیل‌های قبلی ما درباره زیرساخت‌های مدل‌های زبانی اشاره کردیم، سادگی در لایه داده، سرعت توسعه را دوچندان می‌کند. ادغام این ابزار برای توسعه‌دهندگان بک‌اند بسیار راحت است، زیرا تمام ORMهای اصلی مثل Django، Rails، SQLAlchemy و Prisma از آن پشتیبانی می‌کنند. این پروژه که در ابتدا توسط اندرو کین (Andrew Kane) هدایت می‌شد، اکنون دارای یک جامعه مشارکت‌کننده در حال رشد است و توسط شرکت‌هایی مثل Supabase، Neon و Timescale حمایت می‌شود.

قابلیت‌های فنی

pgvector یک نوع داده تخصصی برای بردارها ارائه می‌دهد و از سه معیار فاصله اصلی پشتیبانی می‌کند: L2، کسینوسی (cosine) و ضرب داخلی (inner product). از نسخه ۰.۶، قابلیت halfvec برای کاهش مصرف حافظه و همچنین پشتیبانی از بردارهای پراکنده (sparse vectors) اضافه شد. همچنین نسخه ۰.۷ با معرفی اسکن‌های نمایه‌ای تکرار شونده (iterative index scans)، سرعت جست‌وجوهای فیلترشده را به‌شدت افزایش داد.

گزینه‌های نمایه‌سازی (Indexing) شامل موارد زیر است:

• HNSW: نمایه‌سازی گراف‌محور با کارایی بالا برای جست‌وجوی سریع نزدیک‌ترین همسایه تقریبی (ANN).
• IVFFlat: نمایه‌ای لیست‌محور که ساختنش سریع‌تر اما پرس‌وجوی آن عموماً کندتر از HNSW است.
• B-tree: برای پیش‌فیلتر کردن متادیتا (مثلاً فیلتر بر اساس «سال») پیش از محاسبه فاصله بردارها.

مکانیسم‌های فیلترینگ

در ترکیب فیلترها با ANN، توسعه‌دهندگان سه ابزار اصلی در اختیار دارند:

• پیش‌فیلترینگ B-tree: این همان الگوی کلاسیک RAG است. با نمایه‌سازی ستون فیلتر، Postgres ابتدا ردیف‌های منطبق را پیدا کرده و سپس فواصل دقیق را محاسبه می‌کند. این روش بازخوانی (Recall) ۱۰۰ درصدی را تضمین می‌کند.
• اسکن‌های تکرار شونده (نسخه ۰.۷ به بعد): با تنظیم hnsw.iterative_scan = strict_order موتور دیتابیس روی گراف HNSW حرکت می‌کند تا زمانی که فیلتر ارضا شود. این روش زمانی که فیلترها با ردیف‌های زیادی مطابقت دارند، ایده‌آل است.
• Overfetching: در این روش، تعداد بیشتری از نتایج (مثلاً ۵ تا ۱۰ برابر LIMIT) گرفته شده و سپس در سطح اپلیکیشن فیلتر می‌شوند. این یک رویکرد سریع و غیردقیق است که فقط برای نمونه‌های اولیه (Prototype) مناسب است.

سقف مقیاس‌پذیری

با این حال، این ابزار یک سقف مقیاس‌پذیری عمودی واضح دارد. عملکرد آن تا ۱ میلیون بردار بسیار روان است و با تنظیماتی مثل پارتیشن‌بندی یا استفاده از pgvectorscale شرکت Timescale، تا ۱۰ میلیون بردار قابل مدیریت است. فراتر از این عدد، اشتهای RAM ابزار غیرمنطقی می‌شود؛ برای ۱ میلیون بردار با ۱۵۳۶ بُعد، حدود ۶ گیگابایت داده خام و ۶ گیگابایت دیگر برای نمایه‌ی HNSW نیاز است، زیرا گراف یک کپی از هر بردار را ذخیره می‌کند.

توسعه‌دهندگان باید برای یک میلیون بردار، حدود ۱۲ تا ۱۶ گیگابایت RAM در نظر بگیرند. علاوه بر این، بازسازی نمایه‌ها در این مقیاس به جای چند دقیقه، ساعت‌ها زمان می‌برد، بنابراین برای مجموعه‌داده‌هایی که به میلیاردها بردار می‌رسند، انتخاب مناسبی نیست. در مقابل، برخی از دیتابیس‌های تخصصی برای حل این چالش‌های مقیاس‌پذیری، رویکردهای متفاوتی را پیش گرفته‌اند؛ برای مثال Turbopuffer در نسخه سوم خود برای افزایش سرعت نوشتن داده‌ها، استراتژی حذف ایندکس برداری را به عنوان ذخیره‌ساز اصلی دنبال کرده است.

توازن‌های عملیاتی

یک نکته فنی مهم، محدودیت بُعد است. در حالی که یک ستون می‌تواند ۱۶,۰۰۰ بُعد را ذخیره کند، نمایه‌ها برای بردارهای استاندارد تا ۲,۰۰۰ و برای halfvec تا ۴,۰۰۰ بُعد محدود هستند. برای استفاده از مدل‌های ۳۰۷۲ بُعدی مثل text-embedding-3-large شرکت OpenAI، باید از halfvec (fp16) استفاده کنید یا بردارها را با استفاده از مدل‌های آموزش‌دیده Matryoshka کوتاه کنید.

عملکرد را می‌توان با افزایش hnsw.ef_search از مقدار پیش‌فرض و محافظه‌کارانه ۴۰ بهبود بخشید. با این حال، به‌روزرسانی‌های مکرر بردارها باعث تورم (bloat) دیتابیس می‌شود، زیرا هر ویرایش حدود ۶ کیلوبایت در هر ردیف را بازنویسی می‌کند. عملیات باز-برداری (re-embedding) انبوه باید با اجرای دستور VACUUM دنبال شود.

از نظر هزینه، این افزونه تحت لایسنس PostgreSQL رایگان است و در تمام سرویس‌های ابری بزرگ مثل AWS RDS، Aurora، Google Cloud SQL، AlloyDB، Azure، Supabase و Neon در دسترس است. این موضوع مانع مالی ورود استارتاپ‌ها را کاملاً از بین می‌برد.

این تغییر رویکرد نشان می‌دهد که بازار دیتابیس‌های برداری تخصصی، در واقع فقط برای ۱ درصد از داده‌های عظیم دنیاست. برای یک مهندس معمولی، هزینه عملیاتی مدیریت یک زیرساخت جدید، بسیار بیشتر از سود اندک عملکردی است که یک موتور تخصصی ارائه می‌دهد.

اگر امروز در حال ساخت یک سیستم RAG هستید، پیش از خرید یک دیتابیس جدید، فضای خالی RAM دیتابیس Postgres فعلی خود را بررسی کنید. احتمالاً تنها ابزاری که نیاز دارید، همین حالا در اختیار شماست.

گام بعدی شما

• اگر از Postgres استفاده می‌کنید، ابتدا میزان فضای خالی RAM سرور خود را بررسی کنید.
• برای مدل‌های با بُعد بالا (بیش از ۲۰۰۰)، حتماً از نوع داده halfvec برای بهینه‌سازی حافظه استفاده کنید.
• در صورت بروز کندی پس از به‌روزرسانی‌های انبوه بردارها، دستور VACUUM را برای پاک‌سازی فضای خالی اجرا کنید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره تراشه‌های Blackwell مراجعه کنید.