Supabase blen Turso: Postgres dhe SQLite bashkohen për agjentët AI

Më 2 tetor 2026, Supabase njoftoi se po blen Turso-n; drejtuesi Paul Copplestone e përshkroi shkallën e kërkesës me fjalët “agents are spinning up millions of databases” dhe tha se platforma hap mbi një milion baza në javë. Marrëveshja afron platformën e ndërtuar rreth Postgres me ekspertizën e Turso-s në SQLite. Shërbimet ekzistuese vazhdojnë, ndërsa infrastruktura e përbashkët për agjentët AI mbetet për t’u ndërtuar.

Një raportim i SiliconANGLE e lidh njoftimin e blerjes me një raund financimi prej 150 milionë dollarësh për Supabase, të udhëhequr nga GIC me pjesëmarrjen e CapitalG, IronArc dhe SquarePeg; çmimi i blerjes së Turso-s nuk u bë publik. Raundi është financim për Supabase, jo vlera e deklaruar e marrëveshjes. Për përdoruesit, lajmi i menjëhershëm është vazhdimësia e produkteve që kanë sot, së bashku me drejtimin e ri të zhvillimit të tyre.

Çfarë vazhdon për klientët e dy platformave

Në njoftimin e Turso-s, kompania thotë se bazat, API-të dhe rrjedhat e punës së klientëve vazhdojnë si më parë, Turso Database mbetet me kod të hapur dhe Glauber Costa merr rolin Head of Agentic Services në Supabase, ku bashkohet edhe bashkëthemeluesi Pekka Enberg. Integrim më i thellë mes platformave pritet në muajt në vijim. Ky është një plan zhvillimi, jo një funksion që klientët mund ta përdorin tashmë.

Një aplikacion i ndërtuar mbi Supabase vazhdon të mbështetet te Postgres; një bazë në Turso Cloud vazhdon të përdorë teknologjinë e Turso-s të bazuar në SQLite. Marrëveshja nuk sjell një kalim të detyrueshëm të të dhënave nga njëri motor te tjetri. Kjo ka rëndësi për ekipet që kanë skema, kërkesa SQL dhe lidhje me shërbime të tjera të ndërtuara rreth njërës platformë: njoftimi nuk u kërkon ta ndryshojnë arkitekturën e aplikacionit tani.

Edhe vazhdimësia e shërbimit ka një kufi të qartë kuptimor. Ajo përshkruan funksionimin e bazave dhe API-ve ekzistuese, ndërsa produkti i synuar për agjentët do të ketë sjelljen dhe kushtet e veta. Prania e të dy motorëve nën të njëjtën kompani nuk e bën automatikisht një aplikacion SQLite të përputhshëm me Postgres, sepse mënyra si ruhen të dhënat është vetëm një pjesë e varësive të tij.

Pse Turso i duhet planit për bazat e agjentëve

Problemi që synon blerja është shumimi i bazave të vogla. Një agjent që ndërton një prototip ose kryen një detyrë të veçuar mund të ketë nevojë për një bazë të izoluar, edhe kur vetë puna zgjat pak. Në një mjedis të tillë, kostoja e krijimit dhe mbajtjes së çdo baze bëhet po aq e rëndësishme sa kapaciteti i saj. Rezervimi i një makine të dedikuar për çdo ngarkesë të vogël do ta rëndonte modelin që kompanitë duan të mbështesin.

Turso e ka rindërtuar motorin e bazës së vet në Rust dhe e ka projektuar platformën cloud që bazat të ngarkohen kur duhen e të pezullohen kur nuk përdoren. Kjo u jep ekipeve një mënyrë për të furnizuar baza të veçuara sipas kërkesës, në Turso Cloud ose në mjedisin e tyre cloud. Pezullimi i një baze pa aktivitet nuk do të thotë fshirje e saj: qëllimi është të shmanget mbajtja vazhdimisht aktive e burimeve për një detyrë që nuk po punon.

Arkitektura e Turso-s përdor një model pa disk lokal, me regjistrin e shkrimeve të ruajtur në S3, dhe synon të lehtësojë kufizimet e SQLite për shkrime të njëkohshme në përdorim serveri. Këto veçori shpjegojnë interesin e Supabase-s për ekipin dhe teknologjinë e saj, përtej emrit SQLite. Për një bazë të veçuar të një agjenti, rëndësi ka të krijohet shpejt dhe të mos mbajë burime të panevojshme; për bazën qendrore të një aplikacioni që rritet, kërkesat mund të jenë të tjera.

Rruga drejt Postgres mbetet pjesa vendimtare

Synimi i përbashkët është që një projekt të nisë me një bazë të lehtë për agjentin dhe të ketë rrugë drejt Postgres në ekosistemin Supabase kur të rritet. Për ekipet e softuerit, vlera e kësaj rruge do të varet nga mënyra konkrete e kalimit, jo vetëm nga fakti që dy motorët ofrohen nga i njëjti furnizues. Një prototip i vogël mund të ketë pak varësi; një aplikacion që tashmë përdor autentikim, API dhe kërkesa të veçanta SQL ka më shumë për të përshtatur.

Kalimi mes SQLite dhe Postgres kërkon vëmendje te skema, tipat e të dhënave, sintaksa e kërkesave dhe funksionet që aplikacioni pret nga baza. Njoftimi i blerjes shpreh drejtimin e produktit, por nuk përcakton ende një proces automatik migrimi ose kufijtë e përputhshmërisë. Prandaj premtimi për një rrugë më të qartë drejt Postgres nuk mund të kthehet sot në një afat apo kosto të besueshme migrimi për një aplikacion të caktuar.

Për ekipet që përdorin të dy shërbimet, bashkimi mund të zvogëlojë punën e lidhjes mes platformave nëse integrimi realizohet siç synohet. Ai mund të përqendrojë gjithashtu më shumë pjesë të infrastrukturës te një furnizues. Kodi i hapur i motorit të bazës ndihmon në lëvizshmërinë e teknologjisë, por nuk garanton që API-të cloud, mënyra e vendosjes dhe veçoritë e aplikacionit të zhvendosen pa ndryshime.

Hapi që do ta bëjë të matshme vlerën e marrëveshjes është paraqitja e integrimit të premtuar: si krijohet baza për një agjent, çfarë ndodh kur projekti rritet dhe cilat pjesë të tij kalojnë në Postgres. Deri atëherë, ekipet kanë vazhdimësinë e shërbimeve aktuale dhe një drejtim të shpallur për produktin e ardhshëm, por ende jo kushtet teknike të një kalimi të përfunduar.

Lexoni gjithashtu:

• AMD blen World Labs për 8,2 miliardë dollarë: basti kalon te bota 3D
• Schneider blen PTC për 22,6 miliardë dollarë: premiumi arrin 42,3%
• JSON-i mund të jetë i vlefshëm dhe prapë i gabuar: përdor skemën