Realtime Database vs Firestore Latency
Which Firebase database is faster for your use case?
Select an operation type, connection state, and region. The visualiser shows median latency for both RTDB and Firestore side by side — so you can make an informed architecture decision before writing a line of code.
Get on Google Play
Configure benchmark scenario
Full operation breakdown — warm connection, same region
Median latency in milliseconds across all supported operation types
Get it on
Google Play
Why do RTDB and Firestore have different latency profiles?
The two databases use fundamentally different transport architectures. That choice shapes latency for every operation — not just reads.
Persistent WebSocket — fast on warm connections
RTDB opens a single persistent WebSocket to the database node. Once established (~150–300ms cold), all reads and writes travel over the open socket — typically 30–80ms round trip. The tradeoff: the socket must be maintained, consuming battery and data, and the database is a flat JSON tree with limited querying capability.
gRPC over HTTP/2 — slower first read, richer queries
Firestore uses gRPC streams over HTTP/2. Cold start requires TCP handshake + TLS + HTTP/2 SETTINGS frame + proto serialisation (~250–500ms). Warm connections reuse the stream (~80–150ms). The benefit: full query support (range, composite, collection group), multi-region replication, and a document model that scales without denormalisation.
Both databases: near-zero latency when cached
RTDB's offline persistence uses an in-memory cache + disk persistence. Firestore's is backed by IndexedDB (web) or SQLite (mobile). When data is cached, reads return in 2–15ms regardless of network state. The Firestore SDK's "cache-first" strategy means UI updates happen before the network round-trip completes.
Complex rules add latency to every operation
Both databases evaluate security rules on the server before returning data. Simple rules (auth != null) add ~5ms. Rules that read other documents (get() calls) can add 50–200ms per rule read. This is often the hidden cause of unexpectedly high Firestore latency in production apps.
Latency reference table
| Operation | RTDB warm | RTDB cold | Firestore warm | Firestore cold |
|---|---|---|---|---|
| Simple document read | ~50ms | ~220ms | ~100ms | ~380ms |
| Document write / update | ~90ms | ~280ms | ~180ms | ~480ms |
| Listener first sync | ~70ms | ~250ms | ~140ms | ~420ms |
| Structured query (filtered) | N/A | N/A | ~160ms | ~520ms |
| Cached / offline read | ~5ms | ~5ms | ~10ms | ~10ms |
Median values from community benchmarks and Firebase documentation. Same-continent client, stable mobile connection, simple security rules, no index warm-up required. Cross-continent adds 100–250ms to all figures. Individual results vary significantly by payload size, rule complexity, and network conditions.
When to choose RTDB vs Firestore
- • You need the lowest possible write latency for high-frequency updates (game state, cursor positions, live typing)
- • Your data model is simple and flat — no complex relational queries
- • You need connection presence detection (
.info/connectedis RTDB-only) - • You're building a chat system where message delivery speed matters more than query flexibility
- • Your app is already on the Spark (free) plan and you want to avoid Blaze pricing complexity
- • You need complex queries — range filters, composite indexes, collection group queries
- • Your data has a rich document structure with nested maps and arrays
- • You need automatic offline conflict resolution with pessimistic consistency
- • You need multi-region replication for global users (nam5, eur3)
- • Your data grows in structured collections and you will need to query across multiple fields
How to use this benchmark visualiser
Match the operation to your bottleneck
Choose the operation type that corresponds to your latency-sensitive code path. For a messaging app, "listener first sync" is most relevant. For a data dashboard, "structured query" shows the Firestore advantage.
Cold starts dominate real user experience
Most users open your app cold. Warm-connection benchmarks show steady-state performance, but cold-start numbers determine perceived first-load speed. For apps with high D1 retention concerns, prioritise cold-start latency.
Geography adds latency that no optimization removes
A client in Europe reading from a US Firebase region adds 80–150ms of irreducible RTT. Multi-region deployments reduce this variance but increase write costs. For a global audience, select your Firebase region closest to your largest user cluster.
Benchmark ≠ production — watch the real numbers
Benchmarks give you an architecture starting point. The Firepulse app shows actual Firestore and RTDB metrics across your Firebase projects in production — reads, writes, error rates, and p95 latency — without opening a browser tab.
FAQ
Is Firebase Realtime Database faster than Firestore?
For simple key-value reads and writes on a warm connection, RTDB is typically 20–50% faster because it uses a persistent WebSocket with no per-query serialisation. However, Firestore is faster for complex structured queries, has better offline conflict resolution, and scales more predictably. The right choice depends on access pattern, not just raw latency numbers.
What causes the cold-start latency difference?
RTDB cold starts require TCP + TLS + WebSocket upgrade + authentication (~150–300ms). Firestore cold starts require HTTP/2 connection + gRPC stream setup + proto deserialisation, typically adding 100–200ms more. Warm connections for both databases are much faster: RTDB reuses the WebSocket, Firestore reuses the HTTP/2 connection and local cache.
Does Firestore's offline cache eliminate latency?
Yes, for cached documents. Firestore returns cached documents in 2–15ms regardless of network state, then reconciles with the server when connected. RTDB's offline persistence works similarly. Both are effectively zero-network-latency for reads once data is cached locally.
How accurate are these benchmarks?
The figures shown are indicative median values from community testing and published Firebase documentation, representing a mobile client on a stable 4G connection in the same continent as the Firebase region, with simple security rules. Actual latency varies significantly by payload size, rule complexity, index state, and network conditions. Use these for architecture decisions, not SLA commitments.
Can I use both RTDB and Firestore in the same app?
Yes. Many production apps use both: RTDB for low-latency real-time features (presence, live cursors, typing indicators) and Firestore for structured data with complex querying (user profiles, order history). You are billed separately for each and they do not share quotas or free tier allowances.
Related Firepulse tools
Monitor Firebase latency live — on your phone
Firepulse shows real-time metrics across all your Firebase projects. No browser, no laptop — just a daily digest and live charts in your pocket.