Supabase vs Firebase nel 2026: quale backend scegliere per una web app?

Per la maggior parte delle web app con utenti, account e dati collegati tra loro (SaaS, strumenti interni, portali clienti), Supabase è la scelta di partenza migliore: il suo database PostgreSQL gestisce relazioni, filtri e report con il semplice SQL. Firebase è la scelta migliore quando l'app ruota attorno alla sincronizzazione in tempo reale, all'uso offline su mobile, oppure quando siete già dentro Google Cloud. Entrambi hanno un piano gratuito ed entrambi scalano; la differenza sta nel modello dei dati, ed è difficile da cambiare più avanti.

Questa guida li confronta sui punti che contano per un piccolo team o per un'app generata dall'IA: modello dei dati, query, autenticazione, regole di sicurezza, storage e funzioni, piani gratuiti, prezzi e lock-in. I dettagli dei piani sono stati verificati a novembre 2026 sulle pagine dei prezzi dei fornitori; cambiano, quindi controllate prima di impegnarvi.

La risposta breve, in una tabella

Supabase è un backend PostgreSQL con autenticazione, storage e funzioni; Firebase è un backend di Google costruito attorno al database a documenti Firestore. La tabella mette a confronto le differenze riga per riga.

Modello dei dati: tabelle o documenti

Supabase salva i dati in tabelle collegate; Firestore li salva come documenti raggruppati in collezioni. Questa scelta condiziona tutto il resto.

Un'app aziendale è piena di relazioni: un cliente ha dei progetti, un progetto ha delle attività, un'attività ha dei commenti, una fattura appartiene a un cliente. In PostgreSQL dichiarate questi legami con le chiavi esterne e il database li fa rispettare. In Firestore decidete, schermata per schermata, se annidare i dati dentro un documento o duplicarli, e le copie le mantenete allineate voi. La duplicazione rende le letture rapide e semplici, ma ogni modifica al nome di un cliente deve poi toccare molti documenti.

Oggi Firebase offre anche un'opzione relazionale: la sua documentazione descrive un database PostgreSQL gestito su Cloud SQL, esposto tramite gli SDK di Firebase. È un prodotto separato da Firestore, quindi verificate quale dei due usa davvero un tutorial o un progetto generato dall'IA.

Query e report

Se prima o poi vi chiederete «quanti ordini per cliente al mese», vi serve SQL. In Supabase lo scrivete come un'unica query con un join e un group by, oppure affidate la domanda a un foglio di calcolo o a uno strumento di BI che si collega direttamente a Postgres.

Firestore è pensato per recuperare documenti per percorso o con filtri semplici, operazione veloce ed economica a qualsiasi scala. Non è progettato per aggregazioni ad hoc tra collezioni. Di solito i team aggiungono contatori mantenuti da funzioni, oppure esportano i dati in un altro sistema per l'analisi. Per uno strumento interno ricco di dashboard questo lavoro extra è reale; per una chat o un feed raramente conta. La nostra guida su come creare strumenti interni mostra perché spesso i report finiscono per essere la funzione principale.

Autenticazione

Entrambi i servizi offrono un'autenticazione già pronta con email, provider OAuth e sessioni per utente, ed entrambi indicano 50.000 utenti attivi al mese nei piani gratuiti. Per una tipica web app, l'autenticazione non è il fattore decisivo.

Vale la pena conoscere due differenze. In Supabase gli utenti vivono nel vostro database Postgres, quindi potete collegarli con un join alle vostre tabelle. Su Firebase l'accesso con numero di telefono non è disponibile nel piano gratuito Spark e su Blaze viene fatturato per SMS. Se i vostri utenti accedono con il numero di telefono, controllate prima questa voce. Per approfondire il lato Supabase, leggete la nostra guida a Supabase Auth.

Sicurezza: RLS contro Security Rules

Entrambi i sistemi permettono al browser di parlare direttamente con il database, quindi entrambi dipendono da regole lato server per tenere un utente lontano dai dati di un altro. Le regole non sono facoltative.

Supabase usa la row level security di PostgreSQL. Una policy collegata a una tabella funziona come una clausola WHERE in più su ogni query, per esempio «un utente può leggere le righe in cui user_id è uguale al suo id». Secondo la documentazione di Supabase, la RLS non è attiva per impostazione predefinita: la abilitate tabella per tabella, e la chiave service role la aggira, quindi deve restare sul server. Una tabella senza RLS e con i permessi predefiniti può essere leggibile da chiunque abbia la chiave pubblica, ed è l'errore più comune nelle app generate.

Firebase usa le Security Rules, un linguaggio separato di istruzioni match e allow verificate a ogni richiesta del client. Le librerie lato server le aggirano e sono governate da Google Cloud IAM. Firebase documenta una semplice regola «consenti tutto» e avverte di non usarla mai in produzione; lasciarla al suo posto è la versione Firebase dello stesso errore.

Un vantaggio pratico per Supabase: le policy sono semplice SQL, e i modelli di IA scrivono bene SQL. Il linguaggio delle regole di Firebase è più piccolo e meno rappresentato nei dati di addestramento. È un'osservazione sugli strumenti, non una garanzia in nessuna delle due direzioni.

Storage e funzioni lato server

Entrambi offrono storage di file e funzioni lato server; la differenza principale è ciò che include il piano gratuito. Supabase Storage fa parte del piano Free (1 GB). Su Firebase, il piano Spark segna Cloud Storage e Cloud Functions come non disponibili, quindi una web app che ha bisogno di upload o di un segreto lato server deve passare a Blaze.

Le funzioni lato server vi servono non appena chiamate un servizio con una chiave segreta: pagamenti, email, un modello di IA. Supabase le chiama Edge Functions, con 500.000 invocazioni su Free e 2 milioni su Pro. Le Cloud Functions per Firebase eseguono JavaScript, TypeScript o Python e possono essere attivate da eventi di Firestore, Auth o Storage, da chiamate HTTPS o da una pianificazione, con 2 milioni di invocazioni al mese gratuite su Blaze. Firebase ha l'insieme più ricco di trigger a eventi; Supabase ha il modello mentale più semplice.

Piani gratuiti e costo dei piani a pagamento

Supabase addebita un piano mensile prevedibile; Firebase addebita il consumo, quindi la fattura segue il traffico. Le cifre qui sotto sono state verificate a novembre 2026 su supabase.com/pricing e firebase.google.com/pricing.

Due conseguenze. Primo, Supabase Free mette in pausa un progetto dopo una settimana senza attività: va bene per un prototipo e non va bene per un prodotto in produzione, quindi le app vere passano a Pro. Secondo, Firestore fattura ogni lettura e scrittura di documento: una schermata che carica 200 documenti costa 200 letture a ogni apertura, e un bug che manda in loop una query può produrre una fattura salata su Blaze. Il modello di Supabase è più vicino a una tariffa fissa con limiti d'uso. Pro include dei limiti (per esempio 250 GB di egress) oltre i quali l'uso extra viene addebitato; consultate la pagina dei prezzi per le tariffe attuali.

Lock-in e self-hosting

Supabase si può ospitare in autonomia ed è costruito su PostgreSQL standard, quindi uscirne costa un dump del database; lasciare Firebase significa riscrivere il livello dei dati. Supabase documenta un percorso di self-hosting basato su Docker. Anche se non lo farete mai, i vostri dati stanno in un database Postgres che qualsiasi host può far girare.

Firebase è un servizio di Google con i propri SDK, il proprio modello di query e il proprio linguaggio di regole. Lasciare Firestore significa riprogettare lo schema in tabelle e riscrivere ogni query. È un prezzo normale per un prodotto gestito, e l'infrastruttura di Google è un vero punto di forza, ma va messo in conto. Il lock-in dipende anche da chi possiede il progetto: il nostro articolo su Supabase come backend per i builder con IA spiega la differenza tra progetto vostro e progetto gestito dalla piattaforma.

Perché i creatori di app con IA scelgono quasi sempre Supabase

I builder con IA preferiscono Supabase perché un modello linguistico sa scrivere schemi e policy SQL, e uno sviluppatore può aprire il risultato più tardi in uno strumento standard. È un'ipotesi ragionata sugli incentivi, non una dichiarazione di un fornitore. Ciò che è documentato: il backend integrato di Lovable si basa sul fondamento open source di Supabase, e Lovable permette anche di collegare un progetto Supabase di vostra proprietà.

Anche Cadrant, il nostro builder, usa Supabase: genera web app React su un progetto Supabase nel vostro account, con l'IA che scrive le migrazioni e le policy RLS. L'abbiamo scelto per i motivi visti sopra, e ha un costo che accettiamo: lavorate con concetti SQL e con una fattura Supabase separata dalla nostra. Se il vostro team è già a fondo su Firebase, o vi serve la sincronizzazione mobile offline-first, un builder con IA su Supabase non vi servirà meglio. Confrontate gli strumenti nella nostra guida alle migliori AI app builder e consultate la nostra documentazione sulla connessione a Supabase per capire come funziona il collegamento.

Quale scegliere in quale caso

Scegliete in base alla forma dei vostri dati e al vostro piano di uscita, non in base al logo.

Se state ancora scegliendo lo strumento con cui costruire l'app, la pagina del creatore di web app Cadrant mostra cosa genera l'IA su un backend Supabase.