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.
Data structure comparison
- 🌳 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
- 📁 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
Detailed comparison
| Feature | 🟡 Realtime Database | 🟢 Firestore |
|---|---|---|
| Structure | JSON tree | Collections / Documents |
| Queries | Filter on one field, sort on one | Query composte, indici multipli |
| Real-time | Native, persistent WebSocket | Supported, but with more overhead |
| Latency | ~50ms | ~100-200ms |
| Free tier reads | 1 GB transfer/month | 50.000 letture/giorno |
| Free writes | included in transfer | 20.000 scritture/giorno |
| Scalability | Vertical (one server per DB) | Automatic horizontal |
| Offline support | Yes (mobile SDK only) | Yes (mobile + web) |
| Transactions | Yes (single path) | Yes (multi-document) |
| Document size | No limit per node | Max 1 MB per document |
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.
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.
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
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
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.
🧭 Quick decision guide
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.