The 'Quota exceeded for Firestore reads' error means your Firebase project has consumed all its daily Firestore read operations. On the free Spark plan, the limit is 50,000 reads per day. Fix by optimizing queries to read fewer documents, adding composite indexes, implementing caching, or upgrading to the Blaze plan for pay-as-you-go pricing.
What does "Quota exceeded for Firestore reads" mean?
When Firebase shows this error, your project has used all its allocated Firestore read operations for the current day. On the free Spark plan, the limit is 50,000 document reads per day. Once exhausted, all read operations fail until the quota resets at midnight Pacific Time.
What counts as a read may surprise you. Every document returned by a query counts as one read. A query that matches 500 documents uses 500 reads. Listening to a collection with onSnapshot counts reads for every document in the initial snapshot AND every document that changes. The Firestore console itself also uses reads when you browse your data.
AI-generated code is particularly prone to triggering quota issues because AI tools frequently generate queries without pagination, fetch entire collections instead of filtered subsets, and create onSnapshot listeners without proper cleanup. A single page load in an AI-generated app can consume hundreds of reads if it loads multiple collections without limits.
Common causes
Queries fetch entire collections without limit() or
pagination, consuming one read per document in the collection
Real-time listeners (onSnapshot) on large or
frequently changing collections generate reads for every document update
The Firestore Console is being
browsed while the app is running, consuming additional reads from the dashboard itself
Multiple onSnapshot listeners are created without cleanup, causing
duplicate reads from stale listeners
AI-generated code creates compound queries that
require reading more documents than necessary to filter results
A recursive or looping operation in
Cloud Functions reads documents repeatedly without caching results
How to fix "Quota exceeded for Firestore reads"
Start by identifying which queries consume the most reads. Go to Firebase Console > Firestore > Usage tab to see read counts. If you are on the Blaze plan, check the detailed billing breakdown.
Add limit() to all queries. Instead of fetching an entire collection, fetch only what you need: .limit(20) for a page of results. Implement cursor-based pagination using startAfter() for subsequent pages.
Replace onSnapshot listeners with getDoc/getDocs for data that does not need real-time updates. Every onSnapshot listener re-reads documents whenever they change. For data that changes infrequently (user profiles, settings), fetch once and cache locally.
Clean up onSnapshot listeners when components unmount. In React, return the unsubscribe function from useEffect. Stale listeners continue consuming reads even when the component is no longer visible.
Add composite indexes for queries that use multiple where() clauses or where() with orderBy(). Without proper indexes, Firestore may need to read more documents internally to resolve the query. AI tools frequently generate queries that need indexes but do not create them.
For high-traffic apps, upgrade to the Blaze plan. Pricing is $0.06 per 100,000 reads — much cheaper than the limitations of the free plan. Consider adding a caching layer (local storage, Redis, or CDN) for frequently accessed data.
// Reads ALL documents in the collection - no limitconst snapshot = await getDocs(collection(db, 'posts'));// Listener never cleaned up - leaks readsuseEffect(() => { onSnapshot(collection(db, 'notifications'), (snap) => { setNotifications(snap.docs.map(d => d.data())); });}, []);// Limited query with paginationconst q = query( collection(db, 'posts'), orderBy('createdAt', 'desc'), limit(20));const snapshot = await getDocs(q);// Properly cleaned up listeneruseEffect(() => { const unsubscribe = onSnapshot( query(collection(db, 'notifications'), where('userId', '==', currentUser.uid), limit(50) ), (snap) => { setNotifications(snap.docs.map(d => d.data())); } ); return () => unsubscribe(); // Cleanup on unmount}, [currentUser.uid]);Prevention tips
- Add limit() to every Firestore query — never fetch an entire collection without a limit, even during development
- Always clean up onSnapshot listeners by returning the unsubscribe function from useEffect to prevent stale listeners from consuming reads
- Use getDoc/getDocs instead of onSnapshot for data that does not need real-time updates (profiles, settings, static content)
- Check the Firebase Console Usage tab to identify which collections and queries consume the most reads before optimizing
Still stuck?
Copy one of these prompts to get a personalized, step-by-step explanation.
My Firebase app shows 'Quota exceeded for Firestore reads' daily. I have several onSnapshot listeners and no pagination. How do I optimize my Firestore queries to stay within the free tier quota?
My Firebase project exceeds the Firestore read quota every day. Here are my queries: [paste code]. Optimize them to use fewer reads with proper pagination, caching, and listener cleanup.
Frequently asked questions
What is the Firestore read quota on the free Spark plan?
The free Spark plan allows 50,000 document reads per day. The quota resets at midnight Pacific Time. Each document returned by a query counts as one read. The Blaze plan charges $0.06 per 100,000 reads with no daily cap.
Why does my app hit the "Quota exceeded for Firestore reads" limit so quickly?
Common causes include queries without limit() that fetch entire collections, onSnapshot listeners on large or frequently changing collections, multiple stale listeners that were never cleaned up, and the Firebase Console itself consuming reads when you browse your data.
Does browsing the Firebase Console use Firestore reads?
Yes. Every time you view documents in the Firestore Console, it counts as reads against your quota. Avoid browsing large collections in the Console while your app is running near the quota limit.
How do I reduce Firestore reads from onSnapshot listeners?
Add limit() to listener queries, filter with where() to only listen to relevant documents, use getDoc/getDocs for data that does not need real-time updates, and always return the unsubscribe function from useEffect to clean up listeners when components unmount.
Can AI-generated code cause excessive Firestore reads?
Yes. AI code generators frequently create queries without pagination, fetch entire collections, create onSnapshot listeners without cleanup, and generate compound queries without proper indexes. Always add limit() and proper listener cleanup to AI-generated Firestore code.
Can RapidDev help optimize my Firestore usage to reduce read costs?
Yes. RapidDev can audit your Firestore queries, implement pagination and caching strategies, set up proper composite indexes, and optimize real-time listeners to minimize read consumption. This is especially valuable for apps approaching or exceeding quota limits.
Talk to an Expert
Our team has built 600+ apps. Get personalized help with your issue.
Book a free consultation