Supabase ha acquistato Turso perché gli agenti hanno bisogno di un database per ogni attività

Supabase ha annunciato il 2 ottobre di aver raccolto 150 milioni di dollari e di aver acquisito Turso, un'azienda di database basata su SQLite. Il round è stato guidato da GIC di Singapore, con la partecipazione di CapitalG, il fondo di crescita di Alphabet, IronArc e SquarePeg. Il prezzo dell'acquisizione non è stato reso noto, e l'annuncio del finanziamento non va letto come prezzo di acquisto.

La scommessa architetturale che sta sotto l'operazione è la parte interessante. Supabase ha costruito il proprio business attorno a Postgres, un sistema relazionale progettato per applicazioni che condividono un unico archivio coerente. Turso ha riscritto SQLite da zero ed eliminato il vincolo del singolo writer, per poi distribuirlo attraverso un'architettura diskless con il write-ahead log conservato su S3. Il risultato è un database che può essere provisionato su richiesta, per ogni agente, a una frazione del costo di avviare una macchina per ciascuno.

I numeri citati da Supabase

Supabase afferma di aggiungere ora più di un milione di utenti e circa quattro milioni di database ogni mese. Riferisce che circa il 70 percento dei nuovi database sulla piattaforma è creato da agenti o da strumenti guidati dall'IA. A giugno ha riportato un aumento del 600 percento anno su anno nel numero di database, e ha dichiarato che gli agenti erano già responsabili della maggior parte dei nuovi deployment. L'azienda afferma che più di 13 milioni di sviluppatori usano la piattaforma.

Questi sono dati di adozione dichiarati dall'azienda, e la creazione di database non è la stessa misura dei ricavi o della retention. Un database che un agente avvia per un'attività e abbandona un'ora dopo conta comunque in quel totale mensile. Ciò che i numeri mostrano è la forma della curva della domanda: il volume dei database creati cresce più rapidamente del numero di esseri umani che li creano, ed è esattamente il segnale che un modello con un database per applicazione è sotto pressione.

Perché un database per agente manda in crisi la vecchia aritmetica

L'unità di infrastruttura sta cambiando. Quando uno sviluppatore umano costruisce un'applicazione, un solo database serve molti utenti, e il costo di provisionarlo è ammortizzato su un progetto di lunga durata. Quando un agente esegue un'attività, può aver bisogno di un proprio archivio temporaneo per stato, memoria o risultati intermedi, e può averne bisogno per pochi minuti.

Provisionare un'istanza per ogni agente secondo un modello di database gestito convenzionale non funziona a quella scala. L'overhead di allocare un server, configurarlo e fatturarlo è enormemente superiore al valore del piccolo workload che vi gira dentro. La proposta di Turso è che un database dovrebbe costare quasi nulla da creare e quasi nulla da mantenere inattivo, così che lanciarne un milione sia un'operazione normale anziché un evento contabile.

L'elenco di clienti che Supabase cita per Turso include Superhuman, CTO.new, Sauna.ai e Mastra. Il fondatore di Turso Glauber Costa entra in Supabase come Head of Agentic Services, insieme al co-fondatore Pekka Enberg e al resto del team.

Un dettaglio vale la pena di essere segnalato a chi usa già Turso. Il precedente fork libSQL dell'azienda e il suo più recente motore in Rust sono implementazioni diverse, e le due non hanno lo stesso set di funzionalità. Turso ha spiegato la transizione in un annuncio di riscrittura di gennaio 2025. Un team dovrebbe verificare su quale motore gira il proprio deployment prima di dare per scontato che una funzionalità elencata nella pagina di marketing sia disponibile in produzione.

La concorrenza a cui è mirata

L'acquisizione chiarisce anche con chi è in concorrenza Supabase. La sua offerta a pagamento include autenticazione, storage, edge functions, sottoscrizioni realtime e ricerca vettoriale, il che la colloca contro Firebase, MongoDB Atlas e AWS Aurora nel mercato del backend gestito, più che contro un singolo fornitore di database.

Ciascuno di questi ha una debolezza diversa a livello di agenti. Firebase lega gli sviluppatori a un modello a documenti e al cloud di Google. MongoDB Atlas modella i dati in modo flessibile ma fattura per cluster anziché per unità di lavoro di un agente. Aurora è potente e costoso su piccola scala, con un provisioning che non si adatta a un'attività che vive per pochi minuti.

Il contributo di Turso è la più piccola unità di storage possibile. Offre scritture concorrenti, ricerca vettoriale nativa ed esecuzione nel browser, insieme alla replica embedded tra dispositivi e cloud. Quest'ultima capacità conta per una classe di applicazioni che gira in parte sulla macchina dell'utente, dove un round trip verso un database cloud ha la forma sbagliata per il problema.

Il percorso di graduazione è il meccanismo commerciale. Un progetto che nasce come un singolo database SQLite e cresce fino a diventare un'applicazione vera migra verso Postgres, e con esso verso un piano a pagamento. L'argomento di Supabase è che conquistare il progetto nel momento in cui un agente lo crea costa meno che acquisire lo sviluppatore più tardi.

La storia dei finanziamenti è di per sé un segnale

Il round arriva quattro mesi dopo che Supabase ha chiuso un round Serie F da 500 milioni di dollari a giugno 2026, che valutava l'azienda 10,5 miliardi di dollari post-money ed era anch'esso guidato da GIC. Quel round seguiva un round Serie E da 100 milioni di dollari a ottobre 2025, con una valutazione di 5 miliardi. Il capitale totale raccolto supera ora il miliardo di dollari.

Raccogliere di nuovo così presto suggerisce che l'azienda volesse capitali o un titolo sui giornali, e il comunicato dice che parte del round fornisce liquidità ai dipendenti. Una componente secondaria per il personale è normale a questo stadio, e va tenuta distinta dalla liquidità operativa che un'azienda effettivamente impiega.

La logica strategica è più chiara di quella finanziaria. Supabase vuole essere il primo posto a cui uno sviluppatore o un agente si rivolge quando un progetto ha bisogno di un backend. Se la versione più embrionale di quel progetto è un minuscolo database SQLite creato da un agente, allora possedere il momento della creazione significa possedere la relazione prima che un concorrente veda il progetto. Da lì, Supabase offre un percorso di graduazione verso Postgres standard quando un'applicazione supera il livello leggero. Turso continua a funzionare come piattaforma, e il suo codebase resta open source.

Il pattern di consolidamento

Supabase non è sola in questa mossa. Restate ha raccolto questo mese un round Serie A da 20 milioni di dollari guidato da Singular per un'infrastruttura durevole che evita che i workflow degli agenti di lunga durata falliscano a metà attività. LlamaIndex ha rilasciato uno strumento di estrazione documentale basato su schema, pensato per le pipeline dati degli agenti. Il tema comune a queste operazioni è che l'impiantistica sotto gli agenti sta diventando una categoria, e le sue parti che prima erano un ripensamento ora sono finanziate.

Per chi costruisce, la domanda pratica è cosa cambia. Agli utenti attuali di Supabase viene detto che non vedranno alcuna differenza, che è la risposta giusta per una piattaforma che ora fa girare due motori sotto lo stesso tetto. Il cambiamento più significativo è nei default. Se Postgres e SQLite vivono entrambi nello stesso ecosistema, scegliere tra i due diventa una decisione sulla forma del workload anziché sul fornitore, e l'opzione economica diventa disponibile nel momento in cui un agente ne ha bisogno, anziché dopo un ciclo di procurement.

Ciò che resta aperto è se l'economia regga. Un modello con un database per agente è sostenibile solo se i costi di storage, provisioning e supporto restano al di sotto del prezzo che un cliente è disposto a pagare, e se un numero sufficiente di quei database cresce fino a diventare workload di produzione a pagamento. Supabase ha scommesso che la risposta sia sì, e che i progetti che vale la pena tenere inizieranno in piccolo.