Guida completa a Firebase:
RTDB, Firestore, Auth, Storage e prezzi spiegati con esempi reali
Firebase copre la maggior parte delle esigenze di backend per un'app web senza scrivere un server dedicato — ma scegliere tra i suoi servizi non è sempre ovvio. Questa guida mappa le decisioni principali (quale database, come autenticare, come proteggere i dati, quanto costa) e collega ogni argomento a un esempio reale, tratto da progetti in produzione su questo sito.
The complete guide to Firebase:
RTDB, Firestore, Auth, Storage and pricing explained with real examples
Firebase covers most of a web app's backend needs without writing a dedicated server — but choosing between its services isn't always obvious. This guide maps the main decisions (which database, how to authenticate, how to protect data, what it costs) and links each topic to a real example, taken from projects in production on this site.
In questa guida
- Cos'è Firebase e quando ha senso usarlo
- RTDB vs Firestore: quale database scegliere
- Autenticazione: dal login base ai ruoli custom
- Security Rules: la parte che nessuno legge finché non è tardi
- Cloud Storage: file, immagini e documenti
- Cloud Functions e l'alternativa Netlify Functions
- Prezzi: Spark, Blaze e come evitare sorprese
- Come si combinano i pezzi: un'architettura tipo
- Quando Firebase NON è la scelta giusta
- Errori comuni da evitare
- Checklist prima del lancio
- Domande frequenti
In this guide
- What Firebase is and when it makes sense
- RTDB vs Firestore: which database to choose
- Authentication: from basic login to custom roles
- Security Rules: the part nobody reads until it's too late
- Cloud Storage: files, images and documents
- Cloud Functions and the Netlify Functions alternative
- Pricing: Spark, Blaze and avoiding surprises
- How the pieces combine: a typical architecture
- When Firebase is NOT the right choice
- Common mistakes to avoid
- Pre-launch checklist
- Frequently asked questions
Cos'è Firebase e quando ha senso usarlo
Firebase è la piattaforma Backend-as-a-Service di Google: un insieme di servizi gestiti (database, autenticazione, storage, funzioni serverless, notifiche push) pensati per far girare un'app senza dover costruire e mantenere un'infrastruttura server tradizionale. Per chi sviluppa da solo o in piccoli team, questo significa concentrarsi sul frontend e sulla logica di prodotto, delegando a Firebase la parte infrastrutturale.
Ha senso usarlo quando: l'app ha bisogno di dati sincronizzati in tempo reale tra più client, l'autenticazione utente è un requisito standard (email/password, Google, telefono), il volume di traffico è variabile e non giustifica un server sempre acceso, e il team preferisce velocità di sviluppo a controllo infrastrutturale granulare. Tutti i progetti descritti in questa guida — dai gestionali interni ai giochi multiplayer, dalle chat alle PWA con notifiche push — condividono questo profilo.
Questa guida non sostituisce la documentazione ufficiale Firebase, che resta la fonte più aggiornata per API e limiti tecnici. È una mappa delle decisioni pratiche, con link a implementazioni reali per ogni argomento.
What Firebase is and when it makes sense
Firebase is Google's Backend-as-a-Service platform: a set of managed services (database, authentication, storage, serverless functions, push notifications) designed to run an app without building and maintaining traditional server infrastructure. For solo developers or small teams, this means focusing on the frontend and product logic, delegating the infrastructure part to Firebase.
It makes sense when: the app needs data synced in real time across multiple clients, user authentication is a standard requirement (email/password, Google, phone), traffic volume is variable and doesn't justify an always-on server, and the team prefers development speed over granular infrastructure control. Every project described in this guide — from internal management panels to multiplayer games, from chats to PWAs with push notifications — shares this profile.
This guide doesn't replace the official Firebase documentation, which remains the most up-to-date source for APIs and technical limits. It's a map of practical decisions, with links to real implementations for each topic.
RTDB vs Firestore: quale database scegliere
È la prima decisione, e quella con più conseguenze a lungo termine. Firebase offre due database NoSQL distinti — Realtime Database (RTDB) e Firestore — che sembrano simili ma hanno modelli dati e casi d'uso ideali diversi.
RTDB vs Firestore: which database to choose
This is the first decision, and the one with the most long-term consequences. Firebase offers two distinct NoSQL databases — Realtime Database (RTDB) and Firestore — which look similar but have different data models and ideal use cases.
| Realtime Database (RTDB) | Firestore | |
|---|---|---|
| Modello dati | Un unico grande albero JSON | Documenti raggruppati in collezioni |
| Query | Semplici, limitate | Composte, con più filtri e indici |
| Latenza aggiornamenti live | Molto bassa | Bassa, leggermente superiore a RTDB |
| Prezzo | A banda (GB trasferiti) | A operazione (letture/scritture/eliminazioni) |
| Caso d'uso ideale | Presenza online, chat, contatori live | Cataloghi, dati relazionali, ricerche filtrate |
Nella pratica, molti progetti reali usano entrambi insieme: RTDB per lo stato live che deve propagarsi istantaneamente (presenza, notifiche in arrivo), Firestore per dati strutturati che richiedono query più ricche (storico, cataloghi). Non è un compromesso — è sfruttare i punti di forza distinti di ciascun servizio.
C'è anche una differenza pratica nel modo in cui si leggono i dati che vale la pena capire prima di scegliere. RTDB offre due modalità di lettura fondamentalmente diverse: once() legge il dato una sola volta e chiude la connessione, adatto a letture puntuali dove non serve seguire i cambiamenti; on() apre invece un listener permanente che notifica ogni modifica in tempo reale, indispensabile per interfacce che devono aggiornarsi da sole senza refresh manuale. Usare on() quando basterebbe once() è uno spreco di connessioni aperte; il contrario, usare once() per dati che invece cambiano di continuo, produce un'interfaccia che sembra bloccata o non aggiornata.
Firestore ha un pattern simile con get() per letture singole e onSnapshot() per listener in tempo reale, ma aggiunge la possibilità di query composte con più condizioni where() concatenate — qualcosa che in RTDB richiede di ristrutturare i dati con indici manuali o filtrare lato client dopo aver scaricato più dati del necessario.
Un caso reale che usa entrambi i database nello stesso progetto, ciascuno dove rende meglio: sistema di tracciamento visitatori con RTDB per la presenza live e Firestore per lo storico persistente.
| Realtime Database (RTDB) | Firestore | |
|---|---|---|
| Data model | A single large JSON tree | Documents grouped into collections |
| Queries | Simple, limited | Composite, with multiple filters and indexes |
| Live update latency | Very low | Low, slightly higher than RTDB |
| Pricing | By bandwidth (GB transferred) | By operation (reads/writes/deletes) |
| Ideal use case | Online presence, chat, live counters | Catalogs, relational data, filtered search |
In practice, many real projects use both together: RTDB for live state that needs to propagate instantly (presence, incoming notifications), Firestore for structured data requiring richer queries (history, catalogs). It's not a compromise — it's leveraging each service's distinct strengths.
There's also a practical difference in how data is read worth understanding before choosing. RTDB offers two fundamentally different read modes: once() reads the data a single time and closes the connection, suited to one-off reads where following changes isn't needed; on() instead opens a persistent listener that notifies every change in real time, essential for interfaces that need to update themselves with no manual refresh. Using on() when once() would do is a waste of open connections; the opposite, using once() for data that changes continuously, produces an interface that looks stuck or stale.
Firestore has a similar pattern with get() for single reads and onSnapshot() for real-time listeners, but adds the ability to run composite queries with multiple chained where() conditions — something that in RTDB requires restructuring data with manual indexes or filtering client-side after downloading more data than needed.
A real case using both databases in the same project, each where it performs best: a visitor tracking system with RTDB for live presence and Firestore for persistent history.
Autenticazione: dal login base ai ruoli custom
Firebase Authentication gestisce login con email/password, provider social (Google, Facebook) e telefono via SMS, con sessioni persistenti gestite automaticamente. Per la maggior parte delle app questo basta: nessuna gestione manuale di password, hashing o sessioni.
Il limite emerge quando servono ruoli e permessi granulari — ad esempio distinguere un amministratore da un utente standard, o dare a ciascun utente accesso solo ai propri dati in modo verificabile lato server. La soluzione è un Custom Token: un token firmato lato server (tipicamente con una Cloud Function o una Netlify Function) che include claim personalizzati, verificabili poi nelle security rules del database.
Un errore comune nei progetti che partono come prototipo interno: condividere le stesse credenziali tra più persone invece di dare a ciascuno un account individuale. Funziona finché il team è una persona sola, ma appena si aggiunge qualcuno diventa un problema di sicurezza e di audit trail.
- Migrazione da credenziali condivise a Custom Token con claim per ruolo — il percorso completo, incluso il rollout in fasi per non bloccare fuori nessuno
- Token HMAC firmato client-side — un'alternativa più leggera per passare l'identità utente tra due app dello stesso ecosistema, quando un Custom Token è eccessivo
Authentication: from basic login to custom roles
Firebase Authentication handles email/password login, social providers (Google, Facebook) and phone via SMS, with persistent sessions managed automatically. For most apps this is enough: no manual password handling, hashing, or session management.
The limit shows up when you need granular roles and permissions — for example distinguishing an admin from a standard user, or giving each user access only to their own data in a server-verifiable way. The solution is a Custom Token: a server-signed token (typically via a Cloud Function or a Netlify Function) that includes custom claims, later verifiable in the database's security rules.
A common mistake in projects that start as an internal prototype: sharing the same credentials across multiple people instead of giving each an individual account. It works as long as the team is one person, but as soon as someone joins it becomes a security and audit trail problem.
- Migrating from shared credentials to Custom Tokens with role claims — the full path, including the phased rollout to avoid locking anyone out
- Client-signed HMAC token — a lighter alternative for passing user identity between two apps in the same ecosystem, when a Custom Token is overkill
Security Rules: la parte che nessuno legge finché non è tardi
Le Security Rules sono il meccanismo con cui RTDB e Firestore decidono chi può leggere o scrivere cosa. Sono l'unica vera barriera di sicurezza lato server, perché tutto il resto (validazione JavaScript nel client, controlli nell'interfaccia) può essere bypassato da chiunque apra i DevTools.
Il default di Firebase in modalità test è accesso completamente libero per 30 giorni — pensato per prototipare velocemente, ma pericoloso se dimenticato in produzione. La pratica corretta è passare a regole deny-by-default: tutto negato salvo esplicita autorizzazione, verificata tramite l'autenticazione dell'utente o i claim del suo token.
Le security rules vanno aggiornate durante una migrazione di autenticazione, non solo alla fine: un aggiornamento posticipato lascia una finestra in cui il vecchio e il nuovo sistema convivono senza essere entrambi coperti correttamente dalle regole.
- Passaggio a regole deny-by-default durante una migrazione in 5 fasi, inclusi due bug che hanno temporaneamente bloccato l'app
- Security audit completo su un'app esistente: XSS, credenziali esposte nel client e permessi IAM mancanti
Security Rules: the part nobody reads until it's too late
Security Rules are the mechanism RTDB and Firestore use to decide who can read or write what. They're the only real server-side security barrier, because everything else (client-side JavaScript validation, UI checks) can be bypassed by anyone who opens DevTools.
Firebase's default in test mode is fully open access for 30 days — designed for fast prototyping, but dangerous if forgotten in production. The correct practice is switching to deny-by-default rules: everything denied unless explicitly authorized, verified through the user's authentication or their token's claims.
Security rules need to be updated during an authentication migration, not just at the end: a delayed update leaves a window where old and new systems coexist without both being correctly covered by the rules.
- Switching to deny-by-default rules during a 5-phase migration, including two bugs that temporarily broke the app
- A full security audit on an existing app: XSS, exposed client credentials, and missing IAM permissions
Cloud Storage: file, immagini e documenti
Firebase Storage gestisce l'upload di file binari (immagini, PDF, documenti) separatamente dal database, che dovrebbe contenere solo metadati (nome file, dimensione, URL) e non i blob veri e propri. È la scelta naturale per chi è già nell'ecosistema Firebase, con security rules coerenti con quelle del database.
Un dettaglio importante dal 2026: Cloud Storage richiede sempre il piano Blaze, anche con utilizzo minimo — non è più disponibile sul piano gratuito Spark. Chi vuole restare a costo zero senza questo vincolo può appoggiarsi a un servizio esterno con tier gratuito, mantenendo il resto dell'app su Firebase Spark.
- Catalogo con Storage per i file e RTDB per i metadati, incluse tre race condition risolte
- Upload documenti con Cloudinary invece di Firebase Storage — un'alternativa gratuita quando si vuole evitare il vincolo Blaze
Cloud Storage: files, images and documents
Firebase Storage handles binary file uploads (images, PDFs, documents) separately from the database, which should only hold metadata (file name, size, URL) rather than the actual blobs. It's the natural choice for those already in the Firebase ecosystem, with security rules consistent with the database's.
An important detail as of 2026: Cloud Storage always requires the Blaze plan, even with minimal usage — it's no longer available on the free Spark plan. Those wanting to stay at zero cost without this constraint can rely on an external service with a free tier, keeping the rest of the app on Firebase Spark.
- A catalog with Storage for files and RTDB for metadata, including three race conditions resolved
- Document upload with Cloudinary instead of Firebase Storage — a free alternative when avoiding the Blaze constraint
Cloud Functions e l'alternativa Netlify Functions
Alcune operazioni non possono avvenire lato client per motivi di sicurezza: chiamate ad API di terze parti che richiedono una chiave privata, generazione di Custom Token, invio di email o SMS. Firebase offre Cloud Functions per questo, ma chi già ospita il frontend su Netlify può usare Netlify Functions come alternativa equivalente, evitando di aggiungere un secondo provider cloud solo per la logica server-side.
La scelta tra le due dipende più dall'hosting esistente che da differenze tecniche sostanziali: se il sito è già su Netlify, le Netlify Functions riducono la superficie di configurazione; se il progetto è interamente su Google Cloud/Firebase, le Cloud Functions restano più coerenti con il resto dello stack.
Ci sono comunque differenze pratiche che pesano nella scelta. Le Netlify Functions hanno un limite di durata di esecuzione più stretto (10 secondi sul piano gratuito, contro i minuti disponibili su Cloud Functions), quindi operazioni lunghe come l'elaborazione di file di grandi dimensioni possono richiedere Cloud Functions o un'architettura diversa. Le Cloud Functions, dall'altro lato, richiedono di gestire un secondo progetto Google Cloud con la propria configurazione IAM — un livello di complessità in più se il resto del progetto vive già interamente su Netlify. Per la maggior parte delle integrazioni descritte in questa guida (proxy verso API esterne, generazione di Custom Token, invio di notifiche), il tempo di esecuzione richiesto è nell'ordine di pochi secondi, quindi entrambe le opzioni funzionano bene.
- Netlify Functions per gestire OAuth2 con Gmail API senza esporre credenziali lato client
- Netlify Function come proxy verso l'API Gemini, con rate limiting via Firestore
- Quando nemmeno le Netlify Functions bastano: un caso che ha richiesto un VPS per un vincolo di IP fisso
Cloud Functions and the Netlify Functions alternative
Some operations can't happen client-side for security reasons: calls to third-party APIs requiring a private key, Custom Token generation, sending email or SMS. Firebase offers Cloud Functions for this, but those already hosting the frontend on Netlify can use Netlify Functions as an equivalent alternative, avoiding adding a second cloud provider just for server-side logic.
The choice between the two depends more on existing hosting than substantial technical differences: if the site is already on Netlify, Netlify Functions reduce the configuration surface; if the project is entirely on Google Cloud/Firebase, Cloud Functions remain more consistent with the rest of the stack.
There are still practical differences that weigh on the choice. Netlify Functions have a tighter execution time limit (10 seconds on the free plan, versus minutes available on Cloud Functions), so longer operations like processing large files may require Cloud Functions or a different architecture. Cloud Functions, on the other hand, require managing a second Google Cloud project with its own IAM configuration — an extra layer of complexity if the rest of the project already lives entirely on Netlify. For most integrations described in this guide (proxying external APIs, generating Custom Tokens, sending notifications), the required execution time is in the order of a few seconds, so both options work fine.
- Netlify Functions handling OAuth2 with Gmail API without exposing client-side credentials
- A Netlify Function as a proxy to the Gemini API, with rate limiting via Firestore
- When even Netlify Functions aren't enough: a case that required a VPS for a fixed-IP constraint
Prezzi: Spark, Blaze e come evitare sorprese
Firebase ha due piani: Spark (gratuito, con limiti generosi) e Blaze (pay-as-you-go). Un equivoco comune è pensare che Blaze significhi automaticamente "a pagamento" — in realtà è una tariffazione a consumo, e con traffico contenuto la fattura reale può restare a zero euro anche su questo piano.
Pricing: Spark, Blaze and avoiding surprises
Firebase has two plans: Spark (free, with generous limits) and Blaze (pay-as-you-go). A common misconception is thinking Blaze automatically means "paid" — it's actually usage-based billing, and with modest traffic the actual bill can stay at zero euros even on this plan.
| Spark (gratuito) | Blaze (pay-as-you-go) | |
|---|---|---|
| Costo base | €0 | €0 + consumo oltre le soglie gratuite |
| Cloud Storage | Non disponibile (dal 2026) | Disponibile |
| Cloud Functions outbound | Limitato | Completo |
| Adatto a | Prototipi, MVP, app interne piccole | Progetti con Storage o traffico in crescita |
Il consiglio pratico più utile: impostare un budget alert su Google Cloud prima ancora di passare a Blaze. Un avviso configurato per tempo evita che un picco di traffico imprevisto (bot, bug con loop di richieste) generi una spesa inattesa prima di accorgersene.
Vale la pena capire anche come vengono addebitati i singoli servizi, perché il modello di costo cambia il modo in cui conviene progettare l'app. RTDB fattura principalmente in base alla banda trasferita (GB scaricati dai client), quindi un'app che invia payload grandi a ogni lettura costa di più anche con poche richieste. Firestore invece fattura per operazione — ogni lettura, scrittura ed eliminazione di documento ha un costo fisso indipendente dalla dimensione — quindi un pattern che fa molte piccole letture ripetute (ad esempio, rileggere lo stesso documento a ogni interazione utente invece di tenerlo in cache locale) può costare più del previsto anche con payload minuscoli. Cloud Functions fattura per invocazioni, tempo di calcolo e banda in uscita, con un tier gratuito mensile che copre comodamente un uso leggero.
Guida dedicata a Spark vs Blaze, con tabella prezzi per servizio e istruzioni passo passo per configurare un budget alert.
| Spark (free) | Blaze (pay-as-you-go) | |
|---|---|---|
| Base cost | €0 | €0 + usage beyond free thresholds |
| Cloud Storage | Not available (as of 2026) | Available |
| Cloud Functions outbound | Limited | Full |
| Suited for | Prototypes, MVPs, small internal apps | Projects needing Storage or growing traffic |
The most useful practical advice: set up a budget alert on Google Cloud before even switching to Blaze. A timely configured alert prevents an unexpected traffic spike (bots, a bug causing a request loop) from generating unexpected costs before you notice.
It's also worth understanding how individual services get billed, because the cost model changes how it's worth designing the app. RTDB bills mainly based on bandwidth transferred (GB downloaded by clients), so an app sending large payloads on every read costs more even with few requests. Firestore instead bills per operation — every document read, write and delete has a fixed cost regardless of size — so a pattern doing many small repeated reads (for example, re-reading the same document on every user interaction instead of caching it locally) can cost more than expected even with tiny payloads. Cloud Functions bills for invocations, compute time, and outbound bandwidth, with a monthly free tier that comfortably covers light usage.
A dedicated guide to Spark vs Blaze, with a per-service pricing table and step-by-step instructions to set up a budget alert.
Come si combinano i pezzi: un'architettura tipo
Vista la mappa dei singoli servizi, aiuta vedere come si compongono in un'app reale. Un pattern ricorrente nei progetti di questa guida, applicabile alla maggior parte delle app CRUD con più utenti: Firebase Authentication gestisce il login e genera un token di sessione; una Cloud Function o Netlify Function, invocata al login, crea un Custom Token con claim per ruolo (es. role: 'admin' o role: 'user'); le security rules di RTDB o Firestore leggono quel claim per decidere cosa l'utente può leggere o scrivere; Storage gestisce i file allegati, con security rules coerenti; e un ultimo layer di Cloud/Netlify Functions gestisce le operazioni che richiedono un segreto protetto, come l'invio di notifiche push o chiamate ad API esterne.
Questo schema non è un requisito rigido — molti progetti più semplici funzionano bene solo con Authentication base e security rules che verificano request.auth.uid senza claim custom. Il livello di complessità va introdotto solo quando serve davvero: aggiungere Custom Token e ruoli granulari a un'app con un solo tipo di utente è complessità inutile che rallenta lo sviluppo senza benefici reali.
La domanda utile prima di aggiungere un pezzo dell'architettura non è "Firebase lo supporta?" ma "il mio progetto ha davvero bisogno di questa distinzione oggi?". Molti dei pattern più complessi descritti in questa guida sono nati da un problema reale incontrato in produzione, non da una scelta preventiva.
How the pieces combine: a typical architecture
Having mapped the individual services, it helps to see how they compose in a real app. A recurring pattern across the projects in this guide, applicable to most multi-user CRUD apps: Firebase Authentication handles login and generates a session token; a Cloud Function or Netlify Function, invoked at login, creates a Custom Token with role claims (e.g. role: 'admin' or role: 'user'); RTDB or Firestore security rules read that claim to decide what the user can read or write; Storage handles attached files, with consistent security rules; and a final layer of Cloud/Netlify Functions handles operations requiring a protected secret, like sending push notifications or calling external APIs.
This scheme isn't a rigid requirement — many simpler projects work fine with just base Authentication and security rules checking request.auth.uid with no custom claims. The complexity level should only be introduced when actually needed: adding Custom Tokens and granular roles to an app with a single user type is unnecessary complexity that slows development with no real benefit.
The useful question before adding an architecture piece isn't "does Firebase support it?" but "does my project actually need this distinction today?". Many of the more complex patterns described in this guide came from a real problem encountered in production, not from a preemptive choice.
Quando Firebase NON è la scelta giusta
Firebase non è la scelta universale. Vale la pena considerare alternative quando: servono query relazionali complesse con join tra più entità (un database relazionale tradizionale come PostgreSQL è più adatto); il progetto ha requisiti di compliance specifici che richiedono controllo completo su dove risiedono i dati (alcuni settori regolamentati impongono hosting on-premise o in giurisdizioni specifiche); il team ha già investito in un'infrastruttura diversa (AWS, Azure) e cambiare stack non porterebbe benefici sufficienti a giustificare la migrazione; oppure il volume di dati e traffico è talmente grande da rendere i costi Firebase meno prevedibili di un'infrastruttura dimensionata su misura.
Per la maggior parte dei progetti personali, MVP, app interne e strumenti con traffico moderato — il profilo di tutti gli esempi in questa guida — Firebase resta comunque la scelta più rapida da implementare e più economica da mantenere.
When Firebase is NOT the right choice
Firebase isn't a universal choice. It's worth considering alternatives when: you need complex relational queries with joins across multiple entities (a traditional relational database like PostgreSQL fits better); the project has specific compliance requirements demanding full control over where data resides (some regulated industries mandate on-premise hosting or specific jurisdictions); the team has already invested in different infrastructure (AWS, Azure) and switching stacks wouldn't bring enough benefit to justify the migration; or data and traffic volume is so large that Firebase costs become less predictable than custom-sized infrastructure.
For most personal projects, MVPs, internal apps, and tools with moderate traffic — the profile of every example in this guide — Firebase remains the fastest to implement and most cost-effective to maintain.
Errori comuni da evitare
- Lasciare le security rules in modalità test dopo il lancio in produzione — è il singolo errore più pericoloso e più comune tra chi inizia con Firebase.
- Condividere credenziali tra più utenti invece di dare a ciascuno un account individuale con Custom Token e claim per ruolo.
- Mettere blob di file nel database invece che in Storage — RTDB e Firestore vanno usati per metadati, non per i file veri e propri.
- Non impostare un budget alert prima di passare al piano Blaze, rischiando spese impreviste in caso di traffico anomalo.
- Aggiornare le security rules solo alla fine di una migrazione di autenticazione, invece che durante, lasciando una finestra di vulnerabilità.
- Ignorare il limite di 4KB sulle variabili d'ambiente di provider come Netlify quando si maneggiano credenziali corpose come una service account key Firebase.
Common mistakes to avoid
- Leaving security rules in test mode after launching in production — the single most dangerous and common mistake among those starting with Firebase.
- Sharing credentials across multiple users instead of giving each an individual account with Custom Tokens and role claims.
- Putting file blobs in the database instead of Storage — RTDB and Firestore should hold metadata, not the actual files.
- Not setting a budget alert before switching to the Blaze plan, risking unexpected costs from anomalous traffic.
- Updating security rules only at the end of an authentication migration, instead of during it, leaving a vulnerability window.
- Ignoring the 4KB limit on environment variables from providers like Netlify when handling bulky credentials like a Firebase service account key.
Checklist prima del lancio
- ☐ Security rules impostate come deny-by-default, non lasciate in modalità test
- ☐ Nessuna credenziale hardcoded o condivisa tra più utenti nel codice client
- ☐ File binari (immagini, PDF) su Storage, non salvati come blob nel database
- ☐ Budget alert configurato su Google Cloud se si usa il piano Blaze
- ☐ Scelto RTDB, Firestore, o entrambi in base al tipo di dato — non per abitudine
- ☐ Segreti API (Gemini, servizi terzi) dietro una Cloud/Netlify Function, mai esposti lato client
Pre-launch checklist
- ☐ Security rules set to deny-by-default, not left in test mode
- ☐ No hardcoded or shared-across-users credentials in client code
- ☐ Binary files (images, PDFs) in Storage, not saved as blobs in the database
- ☐ Budget alert configured on Google Cloud if using the Blaze plan
- ☐ RTDB, Firestore, or both chosen based on data type — not out of habit
- ☐ API secrets (Gemini, third-party services) behind a Cloud/Netlify Function, never exposed client-side
Domande frequenti
Devo usare RTDB o Firestore per il mio progetto?
Dipende dal tipo di dati: RTDB è più adatto a dati semplici con aggiornamenti frequenti e bassa latenza (presenza online, chat, contatori live); Firestore è migliore per query complesse con più filtri, paginazione e strutture dati più articolate. Molti progetti reali usano entrambi insieme, ciascuno dove rende meglio.
Firebase è gratuito?
Il piano Spark è gratuito con limiti generosi per prototipi e app a basso traffico. Il piano Blaze è pay-as-you-go: diventa obbligatorio per usare Cloud Storage (dal 2026) o funzionalità avanzate di Cloud Functions, ma con traffico contenuto la fattura reale può restare a zero euro anche su Blaze.
Serve un backend separato se uso Firebase?
Per la maggior parte dei casi d'uso, no: Firebase Authentication, RTDB/Firestore con security rules, e Storage coprono le esigenze di un'app tipica senza un server dedicato. Un backend leggero (Cloud Functions o Netlify Functions) resta utile per operazioni che richiedono un segreto protetto, come chiamate ad API di terze parti con una chiave privata.
Le security rules di Firebase sono sufficienti per proteggere i dati?
Sono la base indispensabile, ma vanno progettate con attenzione: regole troppo permissive lasciano i dati esposti a chiunque conosca la struttura del database, mentre regole scritte a metà migrazione (senza toccare tutto il set in un colpo solo) possono creare finestre di vulnerabilità temporanee.
Conviene usare Firebase per un'app con molti utenti?
Sì, Firebase scala bene per la maggior parte dei casi d'uso web/mobile, ma vale la pena monitorare i costi mano a mano che il traffico cresce, soprattutto per RTDB (che addebita per banda) e Firestore (che addebita per operazione di lettura/scrittura). Un budget alert su Google Cloud evita sorprese.
Qual è l'errore più comune di chi inizia con Firebase?
Lasciare le security rules nella modalità di test predefinita (accesso libero a chiunque) anche dopo il lancio in produzione. È pensata per lo sviluppo iniziale, ma va sempre sostituita con regole deny-by-default esplicite prima che l'app sia pubblica.
Frequently asked questions
Should I use RTDB or Firestore for my project?
It depends on the data type: RTDB fits simple data with frequent updates and low latency (online presence, chat, live counters); Firestore is better for complex queries with multiple filters, pagination, and more articulated data structures. Many real projects use both together, each where it performs best.
Is Firebase free?
The Spark plan is free with generous limits for prototypes and low-traffic apps. The Blaze plan is pay-as-you-go: it becomes mandatory to use Cloud Storage (as of 2026) or advanced Cloud Functions features, but with modest traffic the actual bill can stay at zero euros even on Blaze.
Do I need a separate backend if I use Firebase?
For most use cases, no: Firebase Authentication, RTDB/Firestore with security rules, and Storage cover a typical app's needs without a dedicated server. A lightweight backend (Cloud Functions or Netlify Functions) remains useful for operations requiring a protected secret, like calls to third-party APIs with a private key.
Are Firebase security rules enough to protect data?
They're the essential foundation, but need careful design: overly permissive rules leave data exposed to anyone who knows the database structure, while rules written mid-migration (without touching the whole set at once) can create temporary vulnerability windows.
Is Firebase worth using for an app with many users?
Yes, Firebase scales well for most web/mobile use cases, but it's worth monitoring costs as traffic grows, especially for RTDB (which bills by bandwidth) and Firestore (which bills per read/write operation). A Google Cloud budget alert avoids surprises.
What's the most common mistake beginners make with Firebase?
Leaving security rules in the default test mode (open access to anyone) even after launching in production. It's designed for initial development, but should always be replaced with explicit deny-by-default rules before the app goes public.