Enable true parallel executions for concurrent Firestore queries #7442
Description
What feature would you like to see?
Per guidance from @wu-hui, I'm filing a feature request here.
We kindly request an update to the Firestore Android SDK to enable true parallel network execution for concurrent read operations.
Currently, the SDK appears to serialize all network operations via a single internal queue. This prevents true parallelism, even when using concurrent patterns like Futures.allAsList at the application level. As a result, the total latency for fetching multiple documents is the sum of individual request times, not the maximum time of the slowest request.
We propose allowing multiple, independent get() operations to be in-flight simultaneously. This underlying parallelism would be a fundamental performance improvement for data aggregation.
To mitigate potential cache consistency issues, this behavior could be restricted to server-only reads (i.e., when Source is SERVER). Our use case, like many data-aggregation tasks, only requires server data.
How would you use it?
Our use case is building GenAI features with client side sdks like Firebase AI Logic or things alike. Constructing a single prompt often requires aggregating data from multiple, unrelated Firestore documents (e.g., user profile, content, and metadata).
The SDK's serialization of requests leads to high latency and a poor user experience. This is especially severe for our international users, as Firestore's lack of cross-continent replication makes each sequential round-trip slow.
addSnapshotListener is not a suitable workaround, as we require a one-time, batch-read, not a persistent real-time subscription.