Supabase o Firebase: quale scegliere

È la domanda che arriva puntuale quando hai deciso di non costruirti il backend da zero: Supabase o Firebase? In giro trovi soprattutto articoli schierati, che dipingono uno come il futuro e l'altro come una trappola. La realtà è più noiosa e più utile: vincono in situazioni diverse. Qui li confronto punto per punto, con tabella e verdetto per caso d'uso, senza tifoseria.

La differenza di fondo, da cui discende tutto il resto

Firebase mette al centro Firestore, un database NoSQL a documenti proprietario; Supabase mette al centro PostgreSQL, un database relazionale open source e standard. Tutto il resto del confronto è una conseguenza di questa scelta.

Non è un dettaglio da specialisti: è la decisione che determina come modelli i dati, come scrivi le query, quanto paghi e quanto ti costa cambiare idea più avanti.

Con Firestore i dati sono documenti in stile JSON. Non ci sono join: se una schermata deve mostrare l'ordine insieme al nome del cliente, quel nome lo copi dentro l'ordine. Modelli a partire dalle viste, non dalla struttura logica. Funziona — a patto di accettare che la coerenza dei dati duplicati è responsabilità del tuo codice.

Con Postgres dichiari tabelle e relazioni, e il database garantisce che tornino. Un join è una riga di SQL, e un report complesso è una query, non una funzione da scrivere.

-- su Postgres: una query
SELECT c.nome, COUNT(o.id) AS ordini, SUM(o.totale) AS speso
FROM clienti c
JOIN ordini o ON o.cliente_id = c.id
GROUP BY c.nome
ORDER BY speso DESC;

Su Firestore la stessa cosa non si esprime: si legge tutto e si aggrega nel codice, oppure si mantiene un contatore aggiornato a ogni scrittura.

Se il terreno non ti è familiare, SQL vs NoSQL spiega la differenza per esteso, e quale database scegliere aiuta a capire dove ricadono i tuoi dati. Il criterio pratico: se dal tuo modello escono tante entità collegate, Postgres ti farà risparmiare mesi. Se escono documenti autosufficienti, Firestore non ti darà fastidio.

Maturità dell'ecosistema

Va detto chiaramente, senza girarci intorno: Firebase è più maturo. Non di poco.

È in circolazione da oltre dieci anni, ha librerie curate per iOS, Android, Flutter e web, una documentazione vastissima e — cosa che conta più di quanto sembri — un decennio di domande già risposte. Quando incontri un problema strano alle undici di sera, la probabilità che qualcuno l'abbia già risolto è più alta.

Supabase è più giovane. Cresce in fretta e la comunità è attiva, ma i servizi attorno al database hanno meno anni di produzione alle spalle, e capita più spesso di trovare funzionalità in evoluzione. Il vantaggio compensativo è che il pezzo centrale non è giovane affatto: Postgres esiste da trent'anni, e tutto ciò che sai su Postgres vale qui.

Verdetto onesto: punto a Firebase, con l'avvertenza che si applica soprattutto ai contorni.

Portabilità e lock-in

Qui la situazione si ribalta, ed è il punto più forte di Supabase.

Supabase è open source e sotto c'è Postgres standard. Fai un dump, lo importi altrove, e tabelle e query continuano a funzionare. Puoi anche ospitarti tutto da solo con Docker su un VPS. Resta legata alla piattaforma la parte di contorno, ma il cuore — i dati e il loro modello — è portabile.

Firestore è proprietario. Non c'è una versione che puoi installare, non c'è un altro fornitore. E il problema non sono i dati, che si esportano: è che il tuo codice si è modellato attorno a Firestore. Documenti denormalizzati, query con le sue API, sicurezza nelle Security Rules. Migrare significa riprogettare il modello e riscrivere il livello di accesso.

Quanto pesa dipende dal progetto: su un prototipo, zero; su un prodotto che deve durare dieci anni, molto.

Autenticazione

Entrambi la fanno bene, e coprono email e password, link via email e i provider esterni.

Firebase Authentication è più completo, in particolare sul mobile: accesso via SMS, accesso anonimo poi convertito in account reale, integrazione nativa con Apple e Google. È il servizio di Firebase con il miglior rapporto tra utilità e vincolo, tanto che molti lo usano da solo.

Supabase Auth ha un vantaggio strutturale: gli utenti stanno in una tabella dello stesso database dei tuoi dati, quindi colleghi un profilo con una normale chiave esterna (REFERENCES auth.users(id)) e il database garantisce che il riferimento sia valido. Con Firebase, utenti e dati vivono in due sistemi separati e la coerenza la tieni tu, di solito con una Cloud Function che crea il profilo alla registrazione.

Sicurezza: due modi di dire la stessa cosa

Entrambi adottano lo stesso modello: il client parla direttamente al backend, quindi le regole di accesso stanno lato server. La chiave nel frontend è pubblica in tutti e due i casi.

Supabase usa Row Level Security, una funzionalità di Postgres: policy scritte in SQL.

ALTER TABLE ordini ENABLE ROW LEVEL SECURITY;

CREATE POLICY "solo i miei ordini"
ON ordini FOR SELECT
USING (auth.uid() = utente_id);

Firebase usa le Security Rules, un linguaggio dedicato:

match /ordini/{id} {
  allow read: if request.auth.uid == resource.data.utenteId;
}

Il rischio è identico: una regola permissiva lasciata da quando stavi provando espone i dati a chiunque. Su Supabase è una tabella senza RLS attiva, su Firebase una regola aperta. Nessuno dei due è più sicuro per costruzione: sono sicuri quanto le regole che scrivi. Provale con due utenti diversi. Vedi rendere sicuro un sito.

Realtime

Firebase è nato come database in tempo reale, e si sente: la sincronizzazione è solidissima e, sul mobile, funziona anche offline — l'app legge e scrive senza rete e si riallinea quando torna, gestendo i conflitti. È la funzionalità più difficile da replicare, e su Supabase non hai un equivalente altrettanto rodato.

Supabase offre sottoscrizioni ai cambiamenti delle tabelle, più canali di presenza e messaggi: copre bene chat, dashboard che si aggiornano e notifiche. Punto a Firebase, e ampiamente se il requisito è l'offline.

Prezzi: due modelli diversi

Niente cifre, che cambiano. Quello che conta è il modello, e sono davvero diversi.

Firebase è a consumo. Firestore fattura le operazioni: documenti letti, scritti, cancellati, più il traffico. Il costo dipende da come scrivi le query, non da quanti utenti hai. Una collezione scaricata per filtrarla nel client, un problema N+1 o un listener lasciato aperto possono moltiplicare la bolletta a traffico invariato. Il vantaggio è che se non usi nulla non paghi quasi nulla.

Supabase è a fasce. Un piano gratuito, poi un canone mensile con supplementi oltre certe soglie. Sai in anticipo cosa spendi, ed è più difficile che un errore nel codice si traduca in denaro. Il rovescio: paghi anche nei mesi vuoti.

In una riga: Firebase premia il traffico irregolare e punisce il codice distratto; Supabase è prevedibile e più indulgente con gli errori. Se stai facendo i conti sul budget complessivo, quanto costa un sito web nel 2026 allarga il quadro.

Mobile o web

Mobile: Firebase, senza discussione. SDK nativi curati, integrazione con Flutter di prima qualità, notifiche push, Crashlytics, persistenza offline. È un ecosistema pensato lì.

Web: Supabase gioca alla pari e spesso davanti. Le API generate sopra Postgres si sposano bene con i framework moderni, e se hai già SQL in testa lavori più in fretta. Vedi scegliere lo stack per una web app.

Tabella comparativa

Aspetto	Supabase	Firebase
Database	PostgreSQL relazionale	Firestore, NoSQL a documenti
Query complesse e join	Native, in SQL	Non supportate: si denormalizza
Modellazione dati	Per struttura logica	Per schermate dell'app
Maturità ecosistema	Più giovane, in crescita	Più maturo, oltre 10 anni
Portabilità	Alta: dump SQL, self-hosting	Bassa: proprietario
Autenticazione	Buona, integrata col database	Più completa, ottima su mobile
Regole di sicurezza	RLS in SQL	Security Rules, linguaggio dedicato
Realtime	Buono	Ottimo, con supporto offline
Modello di prezzo	A fasce, prevedibile	A consumo, variabile
Rischio bolletta	Basso	Reale se le query sono scritte male
Mobile nativo	Discreto	Il migliore
Web	Molto forte	Buono
Open source	Sì	No

Il verdetto, per caso d'uso

Scegli Supabase se:

• I dati sono relazionali — utenti, ordini, contenuti collegati — cioè la forma più comune.
• Stai facendo un'applicazione web o un SaaS. Vedi lanciare un micro SaaS.
• Conosci SQL, o vuoi impararlo: è competenza che non scade.
• La portabilità conta, per strategia o per conformità.
• Vuoi costi prevedibili, o ti servono report e query analitiche sui tuoi dati.

Scegli Firebase se:

• Stai facendo un'app mobile, nativa o Flutter.
• Ti serve il funzionamento offline con sincronizzazione automatica.
• Stai facendo un MVP o un prototipo e conta solo la velocità.
• Il progetto è collaborativo e in tempo reale.
• Vuoi l'ecosistema con più risposte già scritte.
• I dati sono naturalmente a documenti, con poche relazioni.

Vanno bene entrambi se stai imparando, se il progetto è piccolo, o se ti serve solo l'autenticazione — in quest'ultimo caso Firebase Auth è difficile da criticare anche col resto costruito altrove.

Nessuno dei due, se ti serve controllo totale sull'infrastruttura, hai vincoli che impongono di tenere i dati in casa, o la logica di backend è talmente specifica che un'API generata sarebbe solo un intralcio. In quel caso il percorso è un backend tuo, un Postgres gestito e un servizio di hosting adeguato.

L'errore da evitare in entrambi i casi

Non è scegliere quello sbagliato. È scegliere senza aver disegnato prima il modello dei dati.

Prendi mezz'ora e metti giù le entità del tuo progetto e come si collegano. Se ti trovi con otto entità e relazioni ovunque, e ti accorgi che con Firestore dovresti duplicare la stessa informazione in cinque posti, hai la risposta. Se invece i tuoi dati sono blocchi indipendenti che leggi sempre per intero, l'altra risposta è altrettanto valida. Mezz'ora spesa lì vale più di dieci articoli di confronto — questo incluso.

In sintesi

La differenza vera è una sola: relazionale contro documenti. Postgres da un lato, Firestore dall'altro. Tutto il resto discende da lì.

Firebase è più maturo, imbattibile sul mobile e nel realtime offline — al prezzo di un lock-in serio e di un modello di costo che punisce le query scritte male.

Supabase è più portabile e prevedibile, forte sul web e su tutto ciò che è relazionale, e poggia su una tecnologia che esiste da decenni — al prezzo di un ecosistema più giovane e di un po' di SQL da imparare.

Non c'è un vincitore assoluto, e chi te lo presenta sta semplificando: guarda la forma dei tuoi dati e la piattaforma su cui pubblichi, e la scelta si fa quasi da sola.

Per i dettagli di ciascuno: cos'è Supabase e cos'è Firebase.