turbopuffer تعيد بناء محركها حتى لا يكون الـ vector أساس التخزين
المغزى: مفهوم vector database كمنتج مستقل يتفكك، ويعود إلى قاعدة بيانات عادية فيها index إضافي. والسبب في طريقة التخزين لا في البحث.
نشرت شركة turbopuffer مقالًا هندسيًا تشرح فيه لماذا تعيد بناء محركها من الأساس، ووصل المقال إلى الصفحة الأولى في Hacker News في 1 أكتوبر 2026 بـ 255 نقطة.
كانت النسخة القديمة من المحرك تخزّن كل شيء مرتبًا حسب عنوان الـ vector. والـ vector تمثيل رقمي لمعنى النص يُستخدم في البحث الدلالي وفي أنظمة RAG. أي أن الـ vector كان الأساس، وبقية بيانات المستند معلّقة به. وقد نجح ذلك في البحث بالـ vector، لكنه خلق ثلاث مشكلات.
الأولى أن المستند الذي يحتوي على أكثر من vector تتكرر بياناته مع كل واحد منها. والثانية، وهي الأصعب، أن الـ index حين يعيد ترتيب الـ vectors لتحسين تجميعها، ينقل معها المستند كله بكل خصائصه. فتغيير vector واحد قد يحرّك مئات الخصائص.
والثالثة تتعلق بمحركات الاستعلام الحديثة، التي تعمل على دفعات كبيرة من الصفوف: DuckDB على 2,048 صفًا في الدفعة، وClickHouse على نحو 65 ألفًا. أما turbopuffer فكانت محصورة في حجم الـ cluster، أي من 100 إلى 200 مستند.
والحل الذي تتبناه الشركة أن يصبح الـ vector index واحدًا من عدة indexes، لا أساس التخزين. ولديها دليل من تجربة سابقة: حين طبقت الفكرة نفسها على البحث النصي، وتحولت إلى كتل ثابتة من 256 مستندًا، صار الـ index أصغر 10 مرات والاستعلام أسرع حتى 20 مرة.
لكن النسخة الجديدة لم تصل إلى production بعد، وما زالت في مرحلة ضبط الأداء، بحسب المقال نفسه. ويطرح ذلك سؤالًا على الفرق التي تبني أنظمة بحث أو RAG اليوم: هل تحتاج قاعدة بيانات منفصلة للـ vectors، أم يكفيها امتداد داخل قاعدتها الأساسية مثل pgvector في Postgres.