Query limitations and workarounds in Firebase - Time & Space Complexity
When using Firebase queries, some limits affect how many operations run as data grows.
We want to see how query limits impact the number of calls as data size increases.
Analyze the time complexity of paginated queries with limits.
const pageSize = 10;
let lastVisible = null;
async function getNextPage() {
let query = firestore.collection('items').orderBy('timestamp').limit(pageSize);
if (lastVisible) {
query = query.startAfter(lastVisible);
}
const snapshot = await query.get();
lastVisible = snapshot.docs[snapshot.docs.length - 1];
return snapshot.docs.map(doc => doc.data());
}
This code fetches data in pages of 10 items, using the last item as a cursor for the next page.
Identify the API calls, resource provisioning, data transfers that repeat.
- Primary operation: Querying a page of data with a limit and cursor.
- How many times: Once per page requested by the user.
Each page fetch makes one query call returning a fixed number of items.
| Input Size (n) | Approx. Api Calls/Operations |
|---|---|
| 10 | 1 query call |
| 100 | 10 query calls (10 pages) |
| 1000 | 100 query calls (100 pages) |
Pattern observation: The number of query calls grows linearly with the number of pages requested.
Time Complexity: O(n)
This means the total number of queries grows directly with how many items you want to fetch.
[X] Wrong: "Fetching more data pages will still be just one query call."
[OK] Correct: Each page requires a separate query call, so more pages mean more calls.
Understanding how query limits affect calls helps you design efficient data fetching in real apps.
"What if we removed the limit and tried to fetch all data at once? How would the time complexity change?"