Prima di tutto: non sono competitor
Firebase offre entrambi perché servono a cose diverse. Google stessa consiglia di valutarli separatamente e, nei progetti complessi, di usarli insieme. Il Realtime Database è il prodotto originale di Firebase — semplice, veloce, pensato per dati che cambiano di continuo. Firestore è arrivato dopo per colmare i limiti del primo: query più potenti, struttura a documenti, scalabilità automatica.
First of all: they're not competitors
Firebase offers both because they serve different purposes. Google itself recommends evaluating them separately and, in complex projects, using them together. Realtime Database is Firebase's original product — simple, fast, built for constantly changing data. Firestore came later to fill in the gaps: more powerful queries, document structure, automatic scalability.
Struttura dati a confronto
Data structure comparison
🟡 Realtime Database
- 🌳 Un grande albero JSON
- 📍 Accesso per path:
ref('chats/room-42')
- ⚡ WebSocket sempre aperto — latenza ~50ms
- 🔢 Struttura piatta consigliata (no deep nesting)
- 🌍 Un'unica regione geografica per database
🟢 Cloud Firestore
- 📁 Collezioni → Documenti → Sotto-collezioni
- 🔍 Query per campo su qualsiasi documento
- ⏱️ Latenza ~100-200ms (più lenta ma scalabile)
- 📊 Struttura relazionale gerarchica
- 🌐 Multi-regione con replica automatica
Confronto dettagliato
Detailed comparison
| CaratteristicaFeature |
🟡 Realtime Database |
🟢 Firestore |
| StrutturaStructure |
JSON treeJSON tree |
Collezioni / DocumentiCollections / Documents |
| QueryQueries |
Filtro su un campo, order su unoFilter on one field, sort on one |
Query composte, indici multipli |
| Real-timeReal-time |
Nativo, WebSocket persistenteNative, persistent WebSocket |
Supportato, ma con overhead maggioreSupported, but with more overhead |
| LatenzaLatency |
~50ms |
~100-200ms |
| Free tier lettureFree tier reads |
1 GB trasferimento/mese1 GB transfer/month |
50.000 letture/giorno |
| Scritture freeFree writes |
incluse nel trasferimentoincluded in transfer |
20.000 scritture/giorno |
| ScalabilitàScalability |
Verticale (un server per DB)Vertical (one server per DB) |
Orizzontale automaticaAutomatic horizontal |
| Offline supportOffline support |
Sì (solo mobile SDK)Yes (mobile SDK only) |
Sì (mobile + web)Yes (mobile + web) |
| TransazioniTransactions |
Sì (su singolo path)Yes (single path) |
Sì (multi-documento)Yes (multi-document) |
| Dimensione documentoDocument size |
Nessun limite per nodoNo limit per node |
Max 1 MB per documentoMax 1 MB per document |
Il modello di costo che cambia tutto
Questa è la differenza più importante nella pratica. Il Realtime Database si paga per gigabyte trasferiti: scarichi un albero JSON enorme una volta sola e sei a posto. Firestore si paga per numero di operazioni — ogni documento letto è una lettura fatturabile. Questo cambia radicalmente come devi strutturare i dati.
Con Firestore, leggere 1.000 documenti per costruire una dashboard costa 1.000 letture. Con Realtime Database, scarichi l'intera sezione in un colpo solo e paghi in KB trasferiti. Viceversa, con un flusso di chat che genera 10.000 messaggi al giorno, Firestore accumula 10.000 scritture — mentre RTDB conta solo i byte inviati.
The pricing model that changes everything
This is the most important practical difference. Realtime Database is billed per gigabytes transferred: download a large JSON tree once and you're done. Firestore is billed per number of operations — every document read is a billable read. This radically changes how you structure your data.
With Firestore, reading 1,000 documents to build a dashboard costs 1,000 reads. With Realtime Database, you download the entire section in one shot and pay in KB transferred. Conversely, a chat generating 10,000 messages per day racks up 10,000 Firestore writes — while RTDB only counts bytes sent.
Regola empirica sui costi: se leggi pochi documenti grandi → RTDB. Se esegui molte query filtrate su collezioni strutturate → Firestore. Se non sei sicuro, usa il calcolatore Firebase su questo sito.
Cost rule of thumb: if you read a few large documents → RTDB. If you run many filtered queries on structured collections → Firestore. If unsure, use the Firebase cost calculator on this site.
Quando scegliere Realtime Database
- Chat e messaggistica — latenza bassissima, aggiornamenti in push istantanei
- Presenza utenti online/offline — supporto nativo a
.onDisconnect()
- Dati che cambiano molte volte al minuto — contatori, posizioni GPS, feed live
- Struttura semplice e piatta — se non hai bisogno di query complesse
- Prototipazione rapida — API minimalista, setup in cinque minuti
When to choose Realtime Database
- Chat and messaging — very low latency, instant push updates
- Online/offline user presence — native support for
.onDisconnect()
- Data that changes many times per minute — counters, GPS positions, live feeds
- Simple, flat structure — if you don't need complex queries
- Rapid prototyping — minimal API, setup in five minutes
Quando scegliere Firestore
- Log, storico, ricevute — documenti strutturati con query per data, utente, tipo
- Catalogo prodotti / e-commerce — filtri per categoria, prezzo, disponibilità
- Dati utente complessi — profili con sotto-collezioni (ordini, indirizzi, preferenze)
- App con molti utenti concorrenti — scalabilità automatica senza configurazione
- Offline-first mobile — cache locale più robusta e persistente
When to choose Firestore
- Logs, history, receipts — structured documents with queries by date, user, type
- Product catalogue / e-commerce — filters by category, price, availability
- Complex user data — profiles with sub-collections (orders, addresses, preferences)
- Apps with many concurrent users — automatic scalability with no configuration
- Offline-first mobile — more robust and persistent local cache
Come ho usato entrambi nello stesso progetto
In PanelControl ho due database Firebase nello stesso progetto, usati per scopi diversi. Il Realtime Database gestisce la chat tra operatori e le notifiche push live: messaggi che arrivano ogni pochi secondi, devono apparire istantaneamente, e non hanno bisogno di query complesse — solo leggere un path e ascoltare i cambiamenti.
Firestore gestisce invece il log delle attività — ferie, permessi, accessi, turni. Questi sono documenti con sei-sette campi, che devo filtrare per operatore, tipo e intervallo di date. Impossibile con RTDB, triviale con Firestore. Il fatto che arrivino con un ritardo di 100ms in più non ha nessuna importanza per dati storici.
How I used both in the same project
In PanelControl I have two Firebase databases in the same project, used for different purposes. Realtime Database handles operator chat and live push notifications: messages that arrive every few seconds, must appear instantly, and don't need complex queries — just read a path and listen for changes.
Firestore handles the activity log — leave, time off, access records, shifts. These are documents with six or seven fields that I need to filter by operator, type and date range. Impossible with RTDB, trivial with Firestore. The extra 100ms latency doesn't matter at all for historical data.
🧭 Guida rapida alla scelta
🧭 Quick decision guide
I dati cambiano più volte al minuto?Does the data change many times per minute?
→ RTDB
Hai bisogno di filtri su più campi?Do you need filters on multiple fields?
→ Firestore
Stai costruendo una chat o presenze online?Are you building a chat or online presence?
→ RTDB
Stai costruendo un catalogo, uno storico, un admin panel?Are you building a catalogue, history log, or admin panel?
→ Firestore
Hai >100k utenti concorrenti previsti?Are you expecting >100k concurrent users?
→ Firestore
Budget quasi zero, struttura semplice?Near-zero budget, simple structure?
→ RTDB
Non esiste la scelta universalmente corretta. Firebase stesso è progettato per usarli insieme: inizia con quello che si adatta meglio al tuo caso principale, aggiungi l'altro quando hai un caso d'uso specifico che lo richiede. Non è un'architettura strana — è esattamente quello che Google suggerisce nella documentazione ufficiale.
There is no universally correct choice. Firebase itself is designed for using them together: start with the one that best fits your primary use case, add the other when you have a specific use case that calls for it. It's not a strange architecture — it's exactly what Google recommends in the official documentation.