Firebase Realtime Database Integration for Mobile Apps
Firebase Realtime Database (RTDB) is a JSON tree with WebSocket synchronization. It's not a relational database nor a classic document database. Its key features are offline persistence and real-time synchronization out of the box. But improper data structure in RTDB turns these advantages into problems: subscribing to a deeply nested node pulls the entire subtree into device memory. We've seen projects where a flat structure caused the app to download 50 MB of data on every update. For real-time chats, RTDB is 2-3 times faster than Firestore in message delivery latency. How to avoid this? Let's break it down.
Why Improper Data Structure Kills Performance
RTDB doesn't support JOINs and can't select a subset of a node. If you nest posts inside a user profile, reading users/$uid retrieves all posts entirely. With offline persistence, they get cached, consuming space. The solution is denormalization and reverse indexes. Example of correct structure:
{ "users": { "uid123": { "name": "Ivan", "email": "ivan@..." } }, "posts": { "postId1": { "userId": "uid123", "text": "...", "createdAt": 1700000000 } }, "userPosts": { "uid123": { "postId1": true, "postId2": true } } } userPosts is a reverse index to get a specific user's posts without scanning the entire posts node. This is a standard RTDB pattern. We guarantee the structure will be designed with Firebase patterns in mind — over 10 integration projects.
How We Integrate Firebase RTDB
Our work process includes stages, each accompanied by code review and testing on real devices. Our team has experience with over 20 Firebase projects.
| Stage | Description | Estimated Timeline |
|---|---|---|
| Scenario Analysis | Determine which data requires real-time | from 2 days |
| Data Structure Design | Denormalization, reverse indexes, sharding | from 3 days |
| Security Rules Setup | Validation, authentication, access control | from 1 day |
| Subscription Implementation | Offline persistence, choosing on('value') vs on('child_added') |
from 4 days |
| Cache Optimization | keepSynced, cache size |
from 1 day |
| Load Testing | Check up to 10k concurrent users | from 2 days |
| Documentation and Handover | Architectural diagram, rules description, deployment | from 1 day |
Cost is calculated individually after analysis of your project. Contact us for a consultation.
More on Transactions
Likes, counters, balances — any concurrent increment requires transactions:
const likeRef = database().ref(`/posts/${postId}/likes`); await likeRef.transaction(currentLikes => (currentLikes ?? 0) + 1); transaction() atomically reads and writes. If another client changes the value between read and write, the transaction retries automatically (up to 25 times). For likes, this is the only correct approach — set(currentLikes + 1) causes race conditions on simultaneous clicks.
How to Avoid Memory Leaks with Subscriptions
import database from '@react-native-firebase/database'; useEffect(() => { const ref = database().ref(`/userPosts/${userId}`); const onValue = ref.on('value', snapshot => { const postIds = Object.keys(snapshot.val() ?? {}); setPostIds(postIds); }); const onChildAdded = ref.on('child_added', snapshot => { setPostIds(prev => [...prev, snapshot.key!]); }); return () => { ref.off('value', onValue); ref.off('child_added', onChildAdded); }; }, [userId]); Critical: always call ref.off() on unmount. on() without off() is a memory leak: the listener lives forever, re-renders a component that no longer exists. In production, this causes a crash: Can't perform a React state update on an unmounted component. Alternatively, abstract listeners into a custom hook with automatic cleanup.
Offline Persistence
import database from '@react-native-firebase/database'; database().setPersistenceEnabled(true); database().setPersistenceCacheSizeBytes(10 * 1024 * 1024); // 10 MB setPersistenceEnabled(true) enables an SQLite cache on the device. When offline, the app reads from cache. When network is restored, it syncs changes. Call only once at initialization, before any database connection.
keepSynced(true) on a specific node preloads data and keeps it in cache even without active listeners. Caution: don't apply to large nodes — RTDB will download the entire tree.
Security Rules Configuration
According to the Firebase Realtime Database Security Rules Guide, default RTDB rules allow either read/write for everyone or no one. We always configure them before production:
{ "rules": { "users": { "$uid": { ".read": "$uid === auth.uid", ".write": "$uid === auth.uid" } }, "posts": { "$postId": { ".read": "auth != null", ".write": "auth != null && newData.child('userId').val() === auth.uid", ".validate": "newData.hasChildren(['userId', 'text', 'createdAt'])" } } } } .validate checks data structure before writing. Without validation, the client can write arbitrary JSON.
Choosing Between RTDB and Firestore
| Criterion | RTDB | Firestore |
|---|---|---|
| Data Type | Hierarchical (JSON) | Document-oriented |
| Queries | Only by keys and filtering | Complex queries, composite indexes |
| Scaling | Up to 1M concurrent | Higher, auto-scaling |
| Real-time | Low latency (WebSocket) | Higher latency, but richer features |
| Offline | Persistence always enabled | Optional |
| Price | $5/GB storage + $1/GB traffic | $0.06/100K operations |
Conclusion: RTDB is for chats, presence, games. Firestore is for complex queries and large numbers of users. Our team helps choose the optimal option.
What's Included in Firebase RTDB Integration
- Data architecture diagram: denormalization, reverse indexes, sharding.
- Subscription implementation with offline persistence: code for React Native / Flutter / iOS / Android.
- Security rules configuration: validation, authentication, optimization.
- Load testing: verification up to 10k concurrent users.
- Documentation: API description, rules, deployment guide.
- Post-launch support: 3-month warranty.
We'll assess your project for free. Order Firebase RTDB integration today.