Monitor FlutterFlow's Firestore database performance using Firebase Console → Firestore → Usage tab for read/write/delete counts, Google Cloud Monitoring for latency alerts and cost spikes, and a custom performance log Cloud Function for app-level metrics. Set up billing budget alerts in Google Cloud Console immediately — Firestore on the Blaze plan has no spending cap by default, and an unoptimized query loop can generate millions of reads in hours.
Monitor Firestore database health and cost in your FlutterFlow app
Firestore charges per read, write, and delete operation — and there is no spending cap by default. A single bug (infinite loop calling a Backend Query, for example) can generate millions of reads overnight. Monitoring has three layers: Firebase Console for built-in usage dashboards, Google Cloud Monitoring for threshold-based alerts (email you when reads exceed X per hour), and a custom Cloud Function that logs query execution times to Firestore for app-level visibility. All three complement each other — Firebase Console shows what happened, Cloud Monitoring alerts you when something is wrong, and custom logging shows which specific queries in your FlutterFlow app are the culprits.
Prerequisites
- A FlutterFlow project connected to Firebase on the Blaze billing plan (pay-as-you-go required for budget alerts)
- Owner or Editor access to the Firebase project's Google Cloud Console
- A basic understanding of Firestore reads, writes, and the Firebase pricing structure
- At least one week of app usage data in the Firebase Console for meaningful baselines
Step-by-step guide
Read Firestore usage metrics in Firebase Console
Read Firestore usage metrics in Firebase Console
In Firebase Console, select your project → Firestore Database → Usage tab. The Usage dashboard shows: daily reads, writes, and deletes for the current billing period; storage size in GB; bandwidth (network egress) in GB. Click on any metric to see the trend over time. Key numbers to monitor: reads per day (Firestore Spark free tier limit is 50K reads/day; Blaze charges $0.06 per 100K reads beyond the free tier), writes per day (20K free, then $0.18 per 100K), storage (1GB free, then $0.18/GB/month). Identify which days have unusual spikes — correlate with app deployments or user growth events. Export usage data via the Firebase Console → Project Settings → Usage and billing for detailed CSVs.
Expected result: You can see daily read/write/delete counts and identify the baseline usage level for your app.
Set up billing budget alerts in Google Cloud Console
Set up billing budget alerts in Google Cloud Console
Navigate to Google Cloud Console (console.cloud.google.com) → Billing → Budgets & alerts → Create Budget. Select your Firebase project. Set the budget scope to All services or just Firebase to filter out other Cloud charges. Set a monthly budget amount — start at your expected monthly cost × 1.5 as a safety net (e.g., if you expect $20/month, set $30 budget). Add alert thresholds at 50%, 90%, and 100% — each triggers an email to your billing account admins. Check the 'Actions' option and connect a Pub/Sub topic to trigger a Cloud Function that can automatically disable certain operations when budget is exceeded. Setting budget alerts at $10, $25, and $50 for new apps catches runaway queries before they cause significant charges. These alerts do NOT automatically cap spending — they only send notifications.
Expected result: Budget alerts are configured and you receive a test email confirmation. Cost spikes will trigger email notifications to your team.
Create query latency alerts with Google Cloud Monitoring
Create query latency alerts with Google Cloud Monitoring
In Google Cloud Monitoring (monitoring.cloud.google.com), navigate to Alerting → Create Policy. Select a Metric: search for 'firestore' and choose cloud.google.com/firestore/document_read_count or firestore request_latencies. For latency: set Condition Type to Threshold, metric to firestore.googleapis.com/api/request_latencies, 99th percentile, and alert when the value exceeds 1000ms (1 second) for more than 5 minutes. For read spikes: alert when document_read_count per minute exceeds 5x your daily average per minute. Click Next, add a notification channel (email or Slack webhook for your team). Name the alert 'Firestore High Read Count' or 'Firestore Slow Queries'. These alerts tell you that something is wrong in real time, not after you see the bill.
Expected result: Google Cloud Monitoring shows your Firestore metrics and you have at least one alert configured for abnormal read counts.
Build a custom performance log with a Cloud Function
Build a custom performance log with a Cloud Function
Firebase Console shows aggregate counts but not which specific query in your FlutterFlow app is expensive. Add timing instrumentation: create a Cloud Function logQueryPerformance that wraps a Firestore query and logs execution time. In your Cloud Function, record: const start = Date.now(); const results = await db.collection('posts').where('userId','==',uid).get(); const duration = Date.now() - start; await db.collection('perf_log').add({ queryName: 'getUserPosts', duration, resultCount: results.size, userId: uid, timestamp: admin.firestore.FieldValue.serverTimestamp() }). Add similar logging to your most critical App-impacting Firestore operations. In FlutterFlow, create an admin-only PerfDashboard page with a Backend Query on perf_log ordered by duration descending — this shows your slowest queries. Display average duration, max duration, and call count per queryName using aggregation in a Cloud Function.
Expected result: The perf_log Firestore collection accumulates query timing data and the PerfDashboard page shows your slowest queries ranked by average execution time.
Monitor Supabase database performance (alternative backend)
Monitor Supabase database performance (alternative backend)
If your FlutterFlow app uses Supabase instead of Firestore, monitoring tools differ. In Supabase Dashboard → Database → Query Performance: pg_stat_statements shows the top 100 queries by execution time, call count, and total time. Look for queries with high total_time that run frequently. Slow query threshold: Supabase flags queries taking over 1 second. In Supabase Dashboard → Reports → Database: see connection counts (watch for connection exhaustion), cache hit rate (should be above 99% for well-indexed queries), disk I/O, and rows read vs rows returned (a high ratio indicates missing indexes). Set up Supabase alerts (Dashboard → Settings → Alerts) for high CPU, low cache hit rate, and connection pool exhaustion — these are sent to your email or Slack.
Expected result: Supabase Query Performance shows your slowest queries with execution times, allowing you to identify which need indexes or query rewrites.
Complete working example
1// Cloud Function: loggedQuery2// Wraps a Firestore query with timing and logs to perf_log collection3// Call this instead of direct Firestore queries for monitored operations4const functions = require('firebase-functions');5const admin = require('firebase-admin');67const db = admin.firestore();89async function timedQuery(queryName, queryFn, userId) {10 const start = Date.now();11 let resultCount = 0;12 let error = null;1314 try {15 const result = await queryFn();16 resultCount = result.size || result.docs?.length || 1;17 return result;18 } catch (err) {19 error = err.message;20 throw err;21 } finally {22 const duration = Date.now() - start;23 // Sample: only log 10% of calls for high-frequency queries to control volume24 if (Math.random() < 0.1 || duration > 500) {25 db.collection('perf_log').add({26 queryName,27 duration,28 resultCount,29 error,30 userId: userId || 'anonymous',31 timestamp: admin.firestore.FieldValue.serverTimestamp(),32 }).catch(() => {}); // don't await, don't fail on log error33 }34 }35}3637exports.getUserData = functions.https.onRequest(async (req, res) => {38 const { userId } = req.body;39 try {40 const snap = await timedQuery(41 'getUserPosts',42 () => db.collection('posts')43 .where('userId', '==', userId)44 .orderBy('createdAt', 'desc')45 .limit(20)46 .get(),47 userId48 );49 return res.json({ posts: snap.docs.map(d => ({ id: d.id, ...d.data() })) });50 } catch (err) {51 return res.status(500).json({ error: err.message });52 }53});Common mistakes when monitoring Your FlutterFlow Database Performance
Why it's a problem: Not setting up billing alerts before going live with a Firestore-backed app
How to avoid: Set up Google Cloud budget alerts at $10, $25, and $100 as the very first step after enabling Blaze billing — before writing any FlutterFlow queries. This takes 5 minutes and can save hundreds of dollars.
Why it's a problem: Monitoring only current usage without establishing a baseline
How to avoid: Use Cloud Monitoring to look at the past 30 days of Firestore read counts and calculate your average daily and average per-minute baseline. Set alert thresholds at 3x the average — this catches real anomalies while avoiding false alarms from normal daily variation.
Why it's a problem: Assuming slow app performance is a Firestore problem without checking other factors
How to avoid: Use Firebase Performance Monitoring (automatically integrates with FlutterFlow Firebase projects) to get a breakdown of time per screen including network request timing vs rendering time. This narrows down whether the bottleneck is data fetching, processing, or UI rendering.
Best practices
- Set billing alerts before enabling Blaze plan — do not wait until after your first production deployment
- Check the Firebase Console Usage dashboard weekly, not just when you notice a problem — proactive monitoring catches gradual degradation before it becomes a crisis
- Add the Firestore read count to your app's internal admin dashboard so non-technical stakeholders can see database health without needing Firebase Console access
- Track which FlutterFlow pages trigger the most Firestore reads by adding page-level analytics events — high-read pages are candidates for caching optimizations
- Keep the Firestore Spark free tier limits in mind during development: 50K reads, 20K writes, 20K deletes per day — if you hit these limits in dev, you will definitely hit them in production with real users
- Review new Backend Queries added by the team before each production release — a well-intentioned query without a limit clause on a large collection can double your read costs
- For Supabase apps, check the pg_stat_statements view after every major feature release to identify slow queries introduced by new schema or query patterns
Still stuck?
Copy one of these prompts to get a personalized, step-by-step explanation.
I have a FlutterFlow app backed by Firestore and I want to monitor database performance. Explain: (1) where to find Firestore read/write counts in the Firebase Console, (2) how to set up a Google Cloud budget alert that sends an email when monthly spending exceeds $50, (3) how to create a Cloud Monitoring alert for when Firestore reads exceed 10,000 per hour. Give me the exact navigation steps for each.
Add a performance monitoring dashboard to my FlutterFlow admin app. Create a page that shows a list of recent query performance logs from my Firestore perf_log collection. Each row should show the queryName, average duration in milliseconds, call count, and whether any calls had errors. Sort by average duration descending to show slowest queries first.
Frequently asked questions
How do I find out which Firestore queries in my FlutterFlow app are the most expensive?
Firebase Console shows aggregate counts but not per-query breakdown. For per-query visibility, add timing instrumentation in Cloud Functions (as shown in Step 4) or use Firebase Performance Monitoring which tracks HTTP request timing including Firestore calls. In FlutterFlow's Test Mode, the browser developer tools Network tab shows Firestore REST calls with timing — look for calls taking over 500ms. The Firestore Profiler CLI tool (requires code export) provides the most detailed per-operation breakdown.
Why did my Firestore reads spike suddenly without any code changes?
Common causes: (1) a new user with an unusual usage pattern (e.g., leaving the app open on a real-time-queried page for hours), (2) a bot or crawler if your app has web components, (3) a marketing campaign that brought a surge of new users, (4) a real-time Backend Query on a page that multiple users now visit simultaneously, and (5) a Firestore rule test that someone ran against production. Check the Firebase Console → Authentication → Usage to see if the user count increased in parallel with the read spike.
Does Firebase Performance Monitoring work automatically with FlutterFlow?
Firebase Performance Monitoring is included in the Firebase SDK that FlutterFlow automatically integrates when you connect to Firebase. It tracks HTTP request timing, screen rendering times, and custom traces. In Firebase Console → Performance, you can see the slowest network requests (which include Firestore calls) and screen load times. Enable it explicitly in FlutterFlow Settings → Firebase → Performance Monitoring toggle if it is not already on.
How do Firestore costs scale with user growth?
Firestore costs scale linearly with reads and writes. If your app performs 10 reads per user session and you have 1,000 daily active users, that is 10,000 reads/day — within the free tier. At 10,000 DAUs it is 100,000 reads/day, costing approximately $0.03/day beyond the free tier. At 100,000 DAUs with 10 reads per session = 1M reads/day ≈ $0.57/day or $17/month just for reads. The real cost driver is inefficient queries — an unlimited real-time query on a collection that gets updated frequently multiplies reads dramatically.
Can I monitor Supabase database performance in a similar way?
Yes — Supabase has built-in monitoring at Dashboard → Reports. The Database report shows connections, cache hit rate, and disk I/O. The Query Performance report (powered by pg_stat_statements) lists the slowest queries by total execution time. For alerting, Supabase Pro and above supports email alerts for high CPU, low cache hit rate, and connection pool exhaustion. For custom monitoring, Supabase supports the Prometheus metrics endpoint which can feed into Grafana dashboards.
What if I need help analyzing and reducing my Firestore costs?
Unexpected Firestore bills are often caused by a small number of inefficient queries or missing index configurations that cause full collection scans. RapidDev can audit your FlutterFlow Backend Query configurations, identify the highest-cost queries, and implement optimizations including pagination, caching strategies, and index creation. For apps spending over $100/month on Firestore, a performance audit typically pays for itself within the first billing cycle.
Talk to an Expert
Our team has built 600+ apps. Get personalized help with your project.
Book a free consultation