Setting with merge option in Firebase - Time & Space Complexity
When we update data in Firebase using the merge option, it changes only parts of the data instead of replacing everything.
We want to know how the time it takes grows as the data size grows.
Analyze the time complexity of this Firebase update with merge.
const docRef = firestore.collection('users').doc('user123');
const updateData = { age: 30, city: 'New York' };
await docRef.set(updateData, { merge: true });
This updates only the fields given, keeping other fields unchanged in the document.
Look at what happens when we run this update.
- Primary operation: One network call to update the document with merge.
- How many times: Exactly once per update call.
As the number of fields in updateData grows, the update sends more data but still only one call.
| Input Size (fields to update) | Approx. API Calls/Operations |
|---|---|
| 10 | 1 network call with 10 fields |
| 100 | 1 network call with 100 fields |
| 1000 | 1 network call with 1000 fields |
Pattern observation: The number of calls stays the same, but the data size sent grows with the number of fields.
Time Complexity: O(n)
This means the time grows linearly with the number of fields you update in the merge.
[X] Wrong: "Using merge means the update time is always constant no matter how many fields I update."
[OK] Correct: Even though there is only one update call, the amount of data sent grows with the number of fields, so time grows too.
Understanding how partial updates scale helps you design efficient data updates and shows you know how cloud calls behave as data grows.
"What if we replaced the merge option with a full set without merge? How would the time complexity change?"