FlutterFlow's Firebase real-time sync works by setting a Backend Query's Single Time Query toggle to OFF. This creates a persistent Firestore WebSocket listener that pushes data changes to your app within 1-2 seconds across all connected devices. Use real-time queries only where live updates matter (chat messages, live scores, order status). For static content (product descriptions, FAQ), use Single Time Query ON to avoid unnecessary persistent connections that drain battery and bandwidth.
Understand and control Firestore real-time sync in FlutterFlow
Firebase Firestore's real-time capability is one of its most powerful features — changes made to a document or collection on one device appear on all other connected devices within 1-2 seconds without any manual refresh. In FlutterFlow, you control this behavior with a single toggle on each Backend Query: Single Time Query ON fetches data once when the page loads, Single Time Query OFF creates a persistent listener that pushes updates. Understanding when to use each mode, how offline persistence works, and how to avoid overusing real-time connections is essential for building fast, battery-efficient apps.
Prerequisites
- A FlutterFlow project connected to Firebase (Settings → Project Setup → Firebase)
- At least one Firestore collection with documents to query
- Basic understanding of Backend Queries in FlutterFlow
Step-by-step guide
Enable real-time sync by turning off Single Time Query
Enable real-time sync by turning off Single Time Query
Select any widget or page that has a Backend Query configured. In the Properties Panel → Backend Query tab, find the Single Time Query toggle. Toggle it OFF. This is the only configuration change needed to enable real-time sync. How it works: FlutterFlow subscribes to the Firestore query results. Firestore opens a WebSocket connection to its servers and maintains it while the page is visible. When any document matching the query changes (created, updated, or deleted), Firestore pushes only the changed fields (not the full document) to the app. FlutterFlow re-renders the bound widgets automatically. The update appears on the user's screen within 1-2 seconds of the change being written anywhere in the world. Test by opening the app on two devices, changing a document in Firebase Console or from the second device, and watching the first device update.
Expected result: When a Firestore document changes, the FlutterFlow app updates within 1-2 seconds without any user action or page refresh.
Understand which queries should be real-time versus one-time
Understand which queries should be real-time versus one-time
Each real-time listener holds a persistent WebSocket connection, consumes bandwidth, and uses phone battery. Real-time queries are appropriate for: chat messages (new messages must appear instantly), live order status (delivery tracking, order accepted/ready), live scores or prices (sports, stock market), collaborative editing (shared documents, whiteboards), notifications (unread badge count). Single Time Query (fetch once) is appropriate for: product catalog, user profile data (not others' profiles), FAQ and help content, app configuration, historical data that does not change. A page with 5 Backend Queries all set to real-time maintains 5 simultaneous WebSocket connections. If those pages are rarely visited, this is wasteful. Review every Backend Query in your app and confirm that real-time mode is only enabled where live updates genuinely improve the user experience.
Expected result: You have identified which of your app's queries genuinely need real-time updates and switched the rest to Single Time Query ON.
Configure offline persistence for a better user experience
Configure offline persistence for a better user experience
Firestore offline persistence is enabled by default for FlutterFlow mobile apps. When a user loses internet connection: (1) Backend Queries continue to return the last-cached data, (2) UI displays normally using cached data, (3) write operations (Create, Update, Delete Document) queue locally and sync to Firestore when connectivity returns. To indicate offline status to users: in FlutterFlow, check the App State for connectivity — add the connectivity_plus package as a Custom Action to detect network state and update an App State boolean isOnline. Show a banner ('You are offline — showing cached data') when isOnline is false. Test offline behavior: disable WiFi and cellular, navigate your app — it should show cached data rather than a blank screen or error. When connectivity returns, real-time listeners automatically re-sync any missed changes.
Expected result: The app shows cached data when offline with a clear indicator, and syncs automatically when connectivity is restored.
Handle multi-device sync conflicts and concurrent edits
Handle multi-device sync conflicts and concurrent edits
Firestore's default conflict resolution is last-write-wins: if two users edit the same document simultaneously, whichever write reaches Firestore last wins and overwrites the other. For most FlutterFlow apps, this is acceptable. For cases where you must avoid overwriting (collaborative editing, inventory counters, voting), use Firestore transactions or FieldValue.increment. In FlutterFlow, use the Update Document action and select specific fields to update — this sends only the changed fields, not the entire document, reducing the risk of overwriting concurrent changes. For atomic counters (likes, views, seats remaining), use a Custom Action with FieldValue.increment(1) or FieldValue.increment(-1) rather than reading the count, incrementing in the app, and writing back. FieldValue.increment is handled by Firestore atomically and cannot be overwritten by concurrent increments.
Expected result: Counter fields (likes, views, inventory quantities) update correctly even when multiple users modify them simultaneously.
Complete working example
1FIREBASE REAL-TIME SYNC IN FLUTTERFLOW23THE KEY TOGGLE:4├── Backend Query → Single Time Query5│ ├── ON = fetch once on page load (one-time read)6│ └── OFF = persistent listener (real-time updates)7└── Default: check your query settings — may vary89USE REAL-TIME (Single Time Query: OFF) for:10├── Chat messages (new messages appear instantly)11├── Order/delivery status updates12├── Live scores, prices, or availability13├── Collaborative document editing14├── Unread notification counts15└── Any data where delay > 5s frustrates the user1617USE ONE-TIME (Single Time Query: ON) for:18├── Product catalog, descriptions19├── FAQ and help articles20├── User's own profile (rarely changed by others)21├── App configuration settings22├── Historical reports and analytics23└── Any data where 30-second delay is fine2425HOW REAL-TIME SYNC WORKS:261. FlutterFlow subscribes to Firestore query272. Firestore: opens WebSocket (keeps it open)283. Data changes anywhere in world294. Firestore pushes delta (only changed fields)305. FlutterFlow re-renders bound widgets31└── Total time: 1-2 seconds from write to display3233OFFLINE PERSISTENCE:34├── Enabled by default on mobile35├── Offline: serves last-cached data36├── Writes: queue locally, sync on reconnect37└── On reconnect: auto-syncs all queued writes3839CONCURRENT EDIT PATTERNS:40├── Default: last write wins (usually fine)41├── Counters: use FieldValue.increment(1) — atomic42├── Arrays: use FieldValue.arrayUnion/arrayRemove43└── Complex: use Firestore transactions4445COST NOTE:46├── Each real-time listener = 1 persistent connection47├── Each document update pushes 1 document read48└── Minimize real-time queries on high-traffic pagesCommon mistakes
Why it's a problem: Leaving all Backend Queries as real-time (Single Time Query OFF) for every page in the app
How to avoid: Audit every Backend Query and ask: does this data need to update while the user is looking at it? Enable real-time (Single Time Query OFF) only for chat, live status, and collaborative data. Use Single Time Query ON for product listings, profiles, and anything that changes infrequently.
Why it's a problem: Using read-modify-write for counter fields instead of FieldValue.increment
How to avoid: Use a Custom Action with admin.firestore().doc(ref).update({likes: FieldValue.increment(1)}) or in FlutterFlow's Update Document action, set the field to Increment Value rather than a fixed value. Firestore handles the increment atomically, preventing concurrent increment collisions.
Why it's a problem: Not testing offline behavior, discovering problems only after app launch
How to avoid: Test offline mode before launch: toggle Airplane mode on your test device and navigate through all app screens. Firestore Backend Queries should show cached data. Add connectivity detection and show a clear offline banner. Handle non-Firestore API call failures with try-catch and show user-friendly error messages.
Best practices
- Enable real-time sync (Single Time Query OFF) only where live updates genuinely improve the experience — chat, order tracking, live scores
- Use Single Time Query ON for static content like product descriptions, FAQ articles, and user profile data that only the user changes
- Test offline behavior by enabling Airplane mode before launch — all screens should show cached data or a graceful error, never a blank screen
- Use FieldValue.increment for counter fields (likes, views, seats, inventory) to ensure correct values under concurrent writes
- Monitor Firestore read counts in Firebase Console → Firestore → Usage — real-time listeners on high-traffic collections can generate unexpectedly high read counts
- Scope real-time queries to the smallest practical document set — query a user's messages subcollection rather than the entire messages collection
- Avoid deep nested real-time queries where the outer query feeds documents IDs into inner real-time queries — this creates a multiplicative number of persistent connections
Still stuck?
Copy one of these prompts to get a personalized, step-by-step explanation.
I am building a FlutterFlow app with Firebase Firestore. Explain how real-time sync works in FlutterFlow using the Single Time Query toggle. I have these queries in my app: (1) a product catalog list, (2) a chat message list, (3) a user profile page, (4) an order status tracker, (5) an FAQ page. Which should be real-time and which should be one-time? What happens to these queries when the user goes offline?
Enable real-time sync for my chat messages page in FlutterFlow. The page has a Backend Query on the messages/{chatId}/msgs subcollection ordered by timestamp descending, limit 50. Set Single Time Query to OFF. Add a loading indicator that shows while the initial query runs. Add an empty state that shows when no messages exist. Make the ListView auto-scroll to the bottom when a new message arrives using a Custom Action.
Frequently asked questions
How do I enable real-time data sync with Firebase in FlutterFlow?
Select any widget or page with a Backend Query. In the Properties Panel → Backend Query tab, find the Single Time Query toggle and set it to OFF. That is the only change needed. FlutterFlow will maintain a persistent Firestore listener and automatically re-render all bound widgets whenever the queried data changes. Changes appear within 1-2 seconds across all connected devices.
What does Single Time Query mean in FlutterFlow?
Single Time Query controls whether a Backend Query fetches data once or continuously. When ON, data is fetched once when the page or widget loads — like reloading a webpage. When OFF, Firestore keeps a persistent connection and pushes updates to the app whenever data changes — like a live feed. Use ON for static content, OFF for live content like chat and order tracking.
How quickly does Firestore real-time sync update across devices?
Firestore real-time updates typically appear within 500 milliseconds to 2 seconds on the same network, and within 2-5 seconds across different networks. The latency depends on network quality and geographic distance to the Firestore data center. Firestore pushes only the changed fields (not full documents) to minimize bandwidth and speed up delivery.
Does FlutterFlow work offline with Firebase?
Yes. Firestore offline persistence is enabled by default for FlutterFlow mobile apps. When offline: Backend Queries return the last-cached data (data is stored locally on the device), UI displays normally using cached results, and any write operations (Create, Update, Delete Document) are queued locally. When connectivity returns, writes sync automatically and real-time listeners catch up on missed changes. You should add a connectivity indicator to your app to inform users they are viewing cached data.
Why is my FlutterFlow app showing stale data even though I changed a Firestore document?
The most common cause: the Backend Query for that page has Single Time Query set to ON — it fetched the data once on page load and will not update until the page is navigated away from and back. Set Single Time Query to OFF to enable real-time updates. Other causes: the user is offline and seeing cached data (check network connectivity), or the query has a filter that excludes the updated document (verify the Where clauses in your Backend Query).
How does Firestore handle concurrent edits from multiple users?
By default, Firestore uses last-write-wins: the most recent write overwrites any previous value. For most fields, this is fine. For counters (likes, views, inventory), use FieldValue.increment(1) in an Update Document action — this is handled atomically by Firestore and cannot be corrupted by concurrent updates. For more complex scenarios where you need to read then conditionally write, use a Firestore transaction via a Custom Action.
Talk to an Expert
Our team has built 600+ apps. Get personalized help with your project.
Book a free consultation