Great question—this confusion is really common because Firestore's query performance doesn't depend on the total number of documents in your collection alone. Let's break down why those two sources seem contradictory, and clarify what actually limits Firestore query performance.

The Core Truth About Firestore Query Performance #

Firestore is an index-first database. When you run a properly indexed query:

• The performance depends only on the number of documents returned, not the total size of the collection.
• That's exactly what the Firebase video is referring to: if your query uses a valid index and returns, say, 100 documents, it will run just as fast against a collection with 10 billion docs as it does against one with 10 docs. The database doesn't scan every document—it jumps straight to the matching results via the index.

Why the GitHub Issue Comment Seems to Contradict This #

The Firebase team member's comment about a 35k-document collection being "outside performance bounds" is almost certainly referring to one of these scenarios:

• No proper index was used: If the query required a composite index that didn't exist, Firestore falls back to a full collection scan. Scanning 35k documents (or more) directly is slow, inefficient, and eats up read quota quickly.
• The query returned all 35k documents: Even with a valid index, transferring and processing 35k documents on the client will cause performance issues. Firestore allows up to 1000 docs per query, but returning tens of thousands (even via pagination) becomes a client-side bottleneck, not a Firestore engine issue.
• Unsupported query patterns: Using operations like !=, not-in (with many values), or unindexed array-contains can force full collection scans, regardless of collection size.

Key Firestore Query Limits & Best Practices to Follow #

To avoid hitting performance issues, stick to these guidelines:

• Always use indexes for your queries: Firestore auto-creates single-field indexes, but you'll need to manually create composite indexes for multi-condition queries (check the Firebase console for index creation prompts when your query fails).
• Limit the number of documents returned: Use limit() to cap results, and use startAfter()/startAt() for pagination if you need more than 1000 docs. This keeps query latency low and reduces client load.
• Avoid full collection scans: Never run a query without a where clause or order-by that uses an index unless you absolutely need every document (and even then, paginate heavily).
• Watch for quota limits: While performance is tied to result count, each document read counts against your quota. Returning 35k docs in one go will burn through quota quickly, even if it "works".

Final Takeaway #

The video's claim holds true for well-indexed queries that return a small, targeted set of results—collection size doesn't matter here. The GitHub issue comment applies to scenarios where queries are unoptimized, return massive result sets, or rely on inefficient patterns. As long as you structure your queries to use proper indexes and limit result counts, you can safely query collections with billions of documents without performance hits.

内容的提问来源于stack exchange，提问作者Isaac Sanchez