Firebase o Supabase: il database conta più del piano gratis

Se un’app deve collegare spesso progetti, attività, partecipanti e commenti, Supabase offre il modello relazionale di PostgreSQL. Se le schermate leggono soprattutto record autonomi e devono riceverne gli aggiornamenti, Cloud Firestore può adattarsi meglio: il suo modello a documenti e raccolte organizza i dati intorno a questi accessi. In questo confronto, Firebase indica Cloud Firestore, non tutti i servizi dati della piattaforma.

La scelta economica deriva anche da quella struttura. Una schermata che apre molti documenti aumenta le letture conteggiate da Firestore; una risposta che trasferisce molti dati incide sul traffico in uscita di Supabase. Il piano gratuito aiuta a iniziare, ma per prevedere costi e continuità del servizio bisogna capire quale risorsa consuma la propria app.

Le relazioni cambiano il lavoro dell’app

Consideriamo un’app ipotetica di attività condivise. Un progetto contiene attività; ogni attività può avere più partecipanti e commenti. In PostgreSQL queste informazioni possono occupare tabelle collegate, così una richiesta può selezionare le attività di un progetto e includere i relativi partecipanti. Questa struttura è utile quando il prodotto richiede filtri trasversali, per esempio le attività assegnate a una persona in progetti diversi.

In Firestore il progetto si costruisce invece intorno ai documenti che una schermata deve leggere. Se la vista principale mostra sempre le attività recenti con pochi campi, conservarle in una raccolta adatta a quella lettura può rendere semplice il percorso del client. Quando servono nuove viste che attraversano più entità, l’app potrebbe dover mantenere dati duplicati o coordinare più letture e aggiornamenti. È un costo di progettazione possibile, non una caratteristica inevitabile di ogni app Firestore.

Il punto decisivo è la frequenza delle domande rivolte ai dati. Per un catalogo di record consultati singolarmente, progettare documenti in base alle schermate può essere naturale. Per un prodotto in cui cambiano spesso associazioni, filtri e rapporti fra entità, le tabelle relazionali riducono il lavoro necessario a ricostruire quelle risposte. Nessuna delle due strutture determina da sola la fattura: conta anche quante volte l’app chiede e trasferisce i dati.

Le soglie gratuite non sono crediti equivalenti

Le quote gratuite di Cloud Firestore comprendono 50.000 letture, 20.000 scritture e 20.000 eliminazioni di documenti al giorno, oltre a 1 GiB di dati archiviati e 10 GiB mensili di traffico in uscita. Le quote operative si azzerano intorno alla mezzanotte, ora del Pacifico. Un totale mensile contenuto può quindi convivere con una giornata che supera la soglia delle letture.

Nel piano Free di Supabase sono inclusi 500 MB di database, 5 GB di traffico in uscita, altri 5 GB di traffico dalla cache, 1 GB di file archiviati e 50.000 utenti attivi mensili. Il listino indica richieste API illimitate, ma il progetto gratuito dispone di CPU e memoria condivise; inoltre prevede limiti distinti per Realtime. I progetti Free vengono sospesi dopo una settimana di inattività. Pro parte da 25 dollari al mese con il primo progetto incluso: oltrepassare una soglia Free non equivale semplicemente a pagare pochi centesimi per la singola richiesta successiva.

Per Firebase, la distinzione fra Spark e Blaze è altrettanto concreta: su Spark, il prodotto che supera la quota gratuita applicabile può essere disattivato per il resto del mese; Blaze mantiene le quote gratuite previste e addebita l’uso aggiuntivo a consumo. Blaze richiede un account di fatturazione. Gli avvisi di budget segnalano la spesa, ma non impongono da soli un tetto ai consumi. Per un’app che deve restare disponibile durante un picco, la conseguenza del superamento della quota conta quanto la quota stessa.

Tre profili di traffico per la stessa app

Per confrontare le soglie, assumiamo che ogni visita all’app ipotetica comporti 20 letture e 2 scritture di documenti in Firestore. Nella versione Supabase supponiamo invece 100 KB di traffico in uscita non servito dalla cache per visita, con database e file sotto i rispettivi limiti Free. Sono ipotesi di calcolo, non misure delle piattaforme: una richiesta SQL non corrisponde a una lettura di documento, e la dimensione delle risposte dipende dai dati richiesti.

Uso leggero. Con 500 visite al giorno e 2.000 utenti attivi nel mese, l’ipotesi Firestore produce 10.000 letture e 1.000 scritture giornaliere. Su Supabase il traffico stimato è circa 1,5 GB in 30 giorni. Le soglie considerate restano sotto i limiti gratuiti, assumendo anche che il traffico Firestore e le altre risorse non superino le proprie quote.
Uso regolare. Con 3.000 visite al giorno e 12.000 utenti attivi mensili, Firestore arriva a 60.000 letture e 6.000 scritture al giorno: sono le letture a oltrepassare per prime la quota ipotizzata. Supabase trasferirebbe circa 9 GB in 30 giorni, superando la quota Free del traffico non servito dalla cache. Le due versioni incontrano dunque limiti diversi pur servendo la stessa app.
Uso intenso. Con 12.000 visite al giorno e 60.000 utenti attivi mensili, Firestore raggiunge 240.000 letture e 24.000 scritture giornaliere. Supabase arriverebbe a circa 36 GB di traffico in 30 giorni e supererebbe anche la quota Free degli utenti attivi. Questi risultati individuano le soglie coinvolte; non costituiscono un preventivo, perché mancano dimensione effettiva dei dati e consumo degli altri servizi.

Con le ipotesi adottate, Firestore raggiunge la soglia delle letture a 2.500 visite al giorno; la soglia delle scritture arriverebbe solo a 10.000. Per Supabase, 5 GB di traffico non servito dalla cache corrispondono a circa 50.000 visite nel mese, se ogni visita trasferisce davvero 100 KB. Una risposta più grande anticipa quel punto, mentre una più piccola lo sposta in avanti. La quota separata per il traffico dalla cache non va sommata automaticamente a quella delle altre risposte.

Quanto pesa il benchmark di latenza

In un confronto pubblicato da CloudBizStack, lo scenario dichiarato con 10.000 connessioni simultanee riporta una latenza mediana di 45 ms per gli aggiornamenti Firestore e di 38 ms per Supabase Realtime su un’istanza Pro. La stessa pubblicazione presenta mediane diverse in un altro scenario con una configurazione di calcolo differente. Quei valori riguardano la propagazione degli aggiornamenti nelle configurazioni descritte, non la durata delle query o delle schermate dell’app ipotetica.

Il confronto non fornisce abbastanza dettagli su collocazione dei client, dimensione dei messaggi e ripetizioni della prova per trasferire quei millisecondi a un prodotto specifico. Regione, carico e configurazione possono cambiare il risultato osservato. Per la scelta iniziale è più solido partire dal percorso dei dati e dalle soglie che quel percorso attiva: Supabase è coerente con relazioni e interrogazioni variabili; Firestore con accessi frequenti a documenti organizzati per le schermate. Il piano sostenibile è quello che regge anche il profilo di traffico previsto, non soltanto l’avvio gratuito.