Firestore queries and indexes in GCP - Step-by-Step Execution

Process Flow - Firestore queries and indexes

Start Query

↓

Check Query Filters

↓

Determine Index Needed

↓

Is Index Available?

No→Create Index

↓

Wait for Index Build

↓

Execute Query Using Index

↓

Return Results

↓

End

This flow shows how Firestore processes a query by checking filters, determining if an index is needed, creating it if missing, then executing the query using the index to return results.

Execution Sample

GCP

db.collection('users')
  .where('age', '>=', 18)
  .where('city', '==', 'NYC')
  .orderBy('age')
  .get()

This query fetches users aged 18 or older living in NYC, ordered by age.

Process Table

Step	Action	Query Filters	Index Needed	Index Exists	Result
1	Start query execution	age >= 18, city == 'NYC', orderBy age	Composite index on age and city	Check index availability	Pending
2	Index check	age >= 18, city == 'NYC', orderBy age	Composite index on age and city	No	Trigger index creation
3	Create index	age >= 18, city == 'NYC', orderBy age	Composite index on age and city	Building	Wait for index build
4	Index build complete	age >= 18, city == 'NYC', orderBy age	Composite index on age and city	Yes	Proceed to query
5	Execute query	age >= 18, city == 'NYC', orderBy age	Composite index on age and city	Yes	Return matching documents
6	End				Query complete with results

💡 Query ends after index is available and results are returned.

Status Tracker

Variable	Start	After Step 2	After Step 4	Final
IndexExists	Unknown	No	Yes	Yes
QueryResult	Empty	Empty	Empty	Documents matching filters

Key Moments - 3 Insights

Why does Firestore sometimes ask to create a new index before running a query?

Because the query uses multiple filters or ordering that require a composite index not yet created, as shown in execution_table step 2 where index existence is checked and found missing.

What happens if the required index is still building when you run the query?

The query waits until the index build completes before returning results, as shown in execution_table step 3 where it waits for the index to build.

Can a query run without an index in Firestore?

Simple queries with single filters or no ordering can run without indexes, but complex queries with multiple filters or orderBy need indexes, as shown by the index check in execution_table.

Visual Quiz - 3 Questions

Look at the execution_table, at which step does Firestore decide to create a new index?

A Step 1

B Step 4

C Step 2

D Step 5

💡 Hint

Check the 'Index Exists' and 'Action' columns in execution_table row for step 2.

According to variable_tracker, what is the value of IndexExists after step 4?

A No

B Yes

C Unknown

D Building

💡 Hint

Look at the 'IndexExists' row under 'After Step 4' in variable_tracker.

If the query had only one filter without ordering, how would the execution_table change?

A It would skip index creation steps

B It would add more index creation steps

C It would wait longer for index build

D It would fail immediately

💡 Hint

Consider how simple queries behave regarding indexes as explained in key_moments.

Concept Snapshot

Firestore queries use filters and ordering.
Complex queries need composite indexes.
If index missing, Firestore creates it.
Query waits for index build before returning results.
Simple queries may not need indexes.

Full Transcript

This visual execution traces how Firestore handles queries and indexes. When a query with filters and ordering runs, Firestore checks if a composite index exists. If not, it triggers index creation and waits for it to build. Once ready, the query executes using the index and returns matching documents. Variables track index existence and query results. Key moments clarify why indexes are needed and what happens during index building. The quiz tests understanding of index creation steps and variable states.

Practice

1. What is the main purpose of indexes in Firestore queries?

easy

A. To make queries faster and more efficient

B. To store large files like images

C. To backup data automatically

D. To encrypt data for security

Solution

1. Step 1: Understand what indexes do in Firestore

   Indexes help Firestore find data quickly without scanning all documents.

2. Step 2: Relate indexes to query performance

   By using indexes, queries run faster and use less resources.

3. Final Answer:

   To make queries faster and more efficient -> Option A

4. Quick Check:

   Indexes speed up queries = D [OK]

Hint: Indexes speed up data search in Firestore queries [OK]

Common Mistakes:

• Thinking indexes store files
• Confusing indexes with backups
• Assuming indexes encrypt data

2. Which of the following is the correct syntax to create a simple Firestore query filtering by a field age equal to 30?

easy

A. db.collection('users').filter('age', '=', 30)

B. db.collection('users').where('age', '==', 30)

C. db.collection('users').query('age' == 30)

D. db.collection('users').find('age', 30)

Solution

1. Step 1: Recall Firestore query syntax

   Firestore uses where(field, operator, value) to filter data.

2. Step 2: Match syntax with options

   db.collection('users').where('age', '==', 30) uses where('age', '==', 30), which is correct syntax.

3. Final Answer:

   db.collection('users').where('age', '==', 30) -> Option B

4. Quick Check:

   Correct Firestore filter syntax = B [OK]

Hint: Use .where(field, '==', value) for filtering in Firestore [OK]

Common Mistakes:

• Using .filter instead of .where
• Using == inside query string
• Using .find which is not Firestore syntax

3. Given this Firestore query:

db.collection('orders').where('status', '==', 'shipped').orderBy('date', 'desc')

What must you do to avoid an error when running this query?

medium

A. Remove the orderBy clause

B. Create a single-field index on date only

C. No index needed, Firestore handles it automatically

D. Create a composite index on status and date

Solution

1. Step 1: Understand query with multiple filters and sorting

   This query filters by status and sorts by date.

2. Step 2: Know Firestore index requirements

   Firestore requires a composite index for queries with multiple filters or sorting on different fields.

3. Final Answer:

   Create a composite index on status and date -> Option D

4. Quick Check:

   Composite index needed for multiple filters + orderBy = A [OK]

Hint: Use composite indexes for queries with filters and sorting [OK]

Common Mistakes:

• Assuming single-field index is enough
• Thinking Firestore auto-creates all indexes
• Removing orderBy to fix error

4. You wrote this Firestore query:

db.collection('products').where('price', '>', 100).orderBy('name')

But it gives an error about missing index. What is the best fix?

medium

A. Change price filter to ==

B. Remove the orderBy clause

C. Create a composite index on price (ascending) and name (ascending)

D. Create a single-field index on name only

Solution

1. Step 1: Identify query components causing index error

   The query filters by price > 100 and orders by name.

2. Step 2: Understand Firestore index needs for range filter + orderBy

   Firestore requires a composite index on both fields with correct sort order.

3. Final Answer:

   Create a composite index on price (ascending) and name (ascending) -> Option C

4. Quick Check:

   Composite index needed for range filter + orderBy = C [OK]

Hint: Create composite index matching filter and orderBy fields [OK]

Common Mistakes:

• Removing orderBy instead of indexing
• Changing filter operator incorrectly
• Creating only single-field index

5. You want to query a Firestore collection events to find documents where type is 'conference' and attendees is greater than 100, sorted by date ascending. Which index should you create to support this query?

hard

A. Composite index on type (ascending), attendees (ascending), and date (ascending)

B. Single-field index on date only

C. Composite index on type (descending) and date (ascending)

D. No index needed, Firestore supports this query by default

Solution

1. Step 1: Analyze query filters and sorting

   The query filters by type == 'conference' and attendees > 100, and sorts by date ascending.

2. Step 2: Determine required index type

   Multiple filters plus sorting require a composite index including all these fields with correct order.

3. Final Answer:

   Composite index on type (ascending), attendees (ascending), and date (ascending) -> Option A

4. Quick Check:

   Composite index covers all filters and orderBy fields = A [OK]

Hint: Include all filter and orderBy fields in composite index [OK]

Common Mistakes:

• Creating only single-field index
• Using wrong sort order in index
• Assuming no index needed