Supabase تجمع 150 مليون دولار وتشتري Turso: وكل وكيل يحصل على قاعدة

أعلنت Supabase في 2 أكتوبر 2026 جمع 150 مليون دولار بقيادة GIC، بمشاركة CapitalG وIronArc وSquarePeg، واتفاقها على شراء Turso، وفق تغطية SiliconANGLE التي أوضحت أن سعر الاستحواذ لم يُكشف. الجولة تمويل جديد للشركة، وليست المبلغ الذي دفعته لقاء Turso؛ وما أُعلن عن الصفقة هو قرار الشراء، من دون تفاصيل عن موعد إتمامه.

وفي بيان Supabase الصادر من سان فرانسيسكو، قالت الشركة إنها تضيف أربعة ملايين قاعدة بيانات شهرياً، تنشئ أدوات الذكاء الاصطناعي والوكلاء 70% من القواعد الجديدة، ووصف رئيسها التنفيذي بول كوبلستون اتجاهها بقوله «The future is agents». لذلك تريد الشركة بنية تستطيع إنشاء قواعد كثيرة وصغيرة عند الطلب، مع بقاء Postgres مساراً للتطبيقات التي يتسع نطاقها. هذا رهان على طريقة إنتاج البرمجيات، ولم يُعلن بعد منتج موحد جديد لكل مستخدم.

لماذا تريد Supabase قاعدة مستقلة لكل وكيل؟

عندما ينشئ وكيل برمجي نموذجاً أولياً أو لوحة بيانات أو تجربة قصيرة، قد يحتاج إلى مكان يحتفظ فيه بحالة المهمة وبياناتها، ولو لفترة محدودة. إذا تكرر ذلك عبر عدد كبير من الوكلاء، تصبح سرعة إنشاء القاعدة وكلفة بقائها خاملة عاملين مؤثرين في جدوى الخدمة. تخصيص آلة كاملة لكل مهمة صغيرة يرفع الموارد المطلوبة قبل معرفة أي التجارب ستتحول إلى تطبيقات دائمة.

الهدف المعماري هو أن يحصل الوكيل على قاعدة منفصلة عند الحاجة، بحيث تبقى بيانات مهمته معزولة عن أعمال الوكلاء الآخرين. هذا الفصل يمنح المطور حدوداً أوضح للبيانات والتشغيل: يمكن إنهاء تجربة أو إيقاف قاعدتها من دون أن يكون ذلك قراراً يخص قاعدة إنتاج مشتركة. لكنه يضيف سؤالاً اقتصادياً جديداً: كم يكلف إنشاء أعداد هائلة من القواعد وإيقاظها وتخزينها، حتى لو كانت كل واحدة صغيرة؟

وتيرة إنشاء القواعد بواسطة أدوات الذكاء الاصطناعي على Supabase تشرح سبب استعجالها بناء هذه الطبقة، لكنها تصف ما يحدث على منصتها، ولا تمثل تقديراً لحصة الوكلاء في سوق قواعد البيانات كله. كما أن ارتفاع عدد القواعد لا يعني بالضرورة ارتفاع عدد التطبيقات الناجحة بالمعدل نفسه؛ كثير من التجارب قد يبقى محدود العمر. هنا تظهر جاذبية قاعدة منخفضة الكلفة تُنشأ سريعاً وتستهلك موارد أقل حين لا تعمل.

ما الذي تضيفه Turso إلى الصفقة؟

يوضح إعلان Supabase للاستحواذ أنها تُطلق أكثر من مليون قاعدة أسبوعياً، وأن Turso أعادت بناء SQLite بلغة Rust لتتيح لخادم واحد إدارة ملايين القواعد؛ كما سينضم مؤسس Turso غلاوبر كوستا وشريكه بيكا إنبرغ مع الفريق إلى Supabase، وسيتولى كوستا قيادة العمل على بنية الوكلاء. تقوم الفكرة على تحميل القاعدة عند استخدامها وتعليقها حين تخمل، بدلاً من تشغيل موارد مخصصة لكل قاعدة طوال الوقت.

الفارق مهم لطبيعة العمل المقصود. فقد يطلب وكيل قاعدة يحتفظ فيها بنتائج البحث أو خطوات بناء نموذج أولي، ثم تنتهي المهمة سريعاً؛ وفي مثال افتراضي آخر، قد ينشئ تطبيق قواعد مستقلة لمستخدمين كثيرين. يتيح هذا التصميم إدارة كل قاعدة بوصفها وحدة منفصلة، مع تجنب تحويل كل حالة صغيرة إلى مشروع Postgres كامل منذ لحظة إنشائها. قدرة البنية على إدارة أعداد كبيرة لا تعني أن كل استخدام سيكون رخيصاً بالقدر نفسه؛ يتوقف ذلك على حجم البيانات ومعدل الطلبات وشروط الخدمة.

يمكن توفير القواعد عند الطلب عبر Turso Cloud أو داخل سحابة العميل، وهو فرق له أثر عملي على مكان تشغيل الخدمة وكيفية إدارتها. فالشركة التي تحتاج إلى إبقاء البنية في بيئتها ستنظر إلى خيار التشغيل داخل سحابتها، فيما قد يفضل مطور النموذج الأولي خدمة جاهزة. يجمع الاستحواذ بين تقنية إدارة قواعد كثيرة وخبرة الفريق الذي شغّلها.

أين ينتهي دور SQLite ويبدأ Postgres؟

ترسم الصفقة مساراً محتملاً من قاعدة صغيرة لمهمة أو نموذج أولي إلى تطبيق يحتاج بنية أوسع. SQLite يناسب القواعد الخفيفة التي تنشأ عند الطلب، بينما يبقى Postgres أساس تطبيقات Supabase التي تنمو وتحتاج إمكانات تشغيل أكثر اتساعاً. يتيح الجمع بينهما اختياراً مختلفاً في مرحلة يكون فيها حجم العمل صغيراً وعدد القواعد المحتمل كبيراً.

بالنسبة إلى المطور، المسألة ليست مجرد تغيير اسم المحرك عند نجاح الفكرة. قد يتطلب الانتقال مراجعة مخطط الجداول، وطريقة تنفيذ الاستعلامات، والتعامل مع التزامن، ونقل البيانات، وأجزاء الشيفرة المرتبطة بسلوك قاعدة بعينها. هذه فروق معمارية بين محركين مختلفين؛ لذلك فإن المسار المعلن إلى الإنتاج يصف الوجهة التي تعمل الشركتان نحوها، ولا يثبت وجود أداة ترحيل عامة أو تحويل بضغطة واحدة.

وتبرز هنا قيمة بقاء المنصتين قائمتين أثناء تطوير الربط بينهما. يستطيع مستخدم Supabase مواصلة تشغيل مشروعه على Postgres، ويستطيع مستخدم Turso مواصلة استخدام SQLite وخدمتها الحالية، بينما تُبنى تجربة تسمح بانتقال التطبيقات المتوسعة إلى منظومة أوسع. التفاصيل التي ستحدد سهولة ذلك الانتقال هي أدوات نقل البيانات، وحدود التوافق في الشيفرة، وطريقة إدارة القواعد والفوترة عبر المرحلتين.

ماذا يتغير للمستخدمين والمستثمرين الآن؟

التغيير الفوري هو اتجاه الملكية والتطوير، ولا يتطلب نقل المشروعات القائمة إلى محرك آخر. تستمر Supabase في بناء خدماتها حول Postgres، وتواصل Turso العمل على SQLite وتشغيل منصتها. بذلك يبقى للمستخدمين الحاليين مسار العمل المعتاد، فيما تتجه جهود الفريقين إلى جعل القواعد الصغيرة جزءاً من تجربة أوسع تخدم التطبيقات التي تنشئها أدوات الذكاء الاصطناعي.

مالياً، اقتران الجولة بالاستحواذ يوضح أين تريد Supabase توجيه قدرتها على الاستثمار: بنية تتحمل إنشاء قواعد كثيرة للأعمال الصغيرة، مع استمرار تطوير منصة التطبيقات الأكبر. عدم إعلان سعر شراء Turso يمنع تقدير كلفة الصفقة أو مقارنة ثمنها بالعائد المتوقع منها. ولم يُعلن أيضاً سعر موحد لهذه القواعد الجديدة أو جدول زمني لدمجها في تجربة Supabase.

سيكون الأثر الأوضح للمطور حين تُعلن أدوات الربط بين قواعد الوكلاء الصغيرة ومشروعات Postgres، وشروط تشغيلها وتسعيرها. عندئذ يمكن الحكم على الفكرة من زمن إنشاء القاعدة، وكلفة القواعد الخاملة، والعمل المطلوب لنقل تطبيق نما خارج حدود التجربة الأولى. إلى أن تتضح هذه التفاصيل، تظل الخدمة الحالية لكل منصة هي المرجع العملي لمستخدميها.

اقرأ أيضًا:

• Socure تجمع 156 مليون دولار وتشتري Fravity لملاحقة الاحتيال
• FNZ تجمع 450 مليون دولار: التمويل يأتي بعد بيع أصول غير أساسية
• Numeral تجمع 100 مليون دولار: ضرائب البرمجيات تدفع التوسع