Firestore配额误解及数据库结构规划中的技术疑问

Hey Vlad, let's unpack those two Firestore quota questions you're grappling with—they're easy to mix up when mapping out your database structure!

Question 1: Is this referring to the total memory size of composite index fields in a collection? #

Great question. The quota you're looking at is not tied to the memory size of composite index fields. Instead, it's almost certainly the default limit on the number of composite indexes you can create per collection (which is 200 by default, and you can request an increase via Firebase support if needed).

Composite indexes do take up storage space, but that usage counts towards your overall Firestore storage quota—there's no separate, dedicated memory limit just for composite index fields. If you're worried about index storage bloat, keep in mind that unused composite indexes can be deleted to free up space, and you can use the Firestore console to audit which indexes are actually being used by your queries.

Question 3: Does the 20000 limit relate to maximum document fields (since each field gets an auto-index) or a query with 20000 where clauses? #

Neither! That 20000 number is the default project-wide limit for total composite indexes across all your collections. Let's break down the key distinctions to avoid confusion:

• Maximum document fields: Firestore caps each document at 1000 fields, and this has no connection to the 20000 quota. Auto-indexes for these fields are created automatically and don't count against your composite index limits.
• Query where clauses: You can only include up to 10 where clauses in a single Firestore query—way lower than 20000. This limit is about query complexity, not index counts.

The 20000 limit is simply the total number of composite indexes you can create across your entire Firebase project. Like the per-collection composite index limit, you can request an increase if you outgrow this number.

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