The RTDB is able to do this because each database is local to a single region. In order to provide a serialized view, when you call remove()
, the database stops all other work until the removal is complete.
This behavior has been the cause of several apparent outages: if a remove()
call has to delete huge swaths of data, all other activity is effectively locked out until it completes. As a result even for RTDB users that want to delete large quantities of data we have recommended recursively finding and deleting documents in groups (CLI, node.js).
Firestore on the other hand is based on more traditional Google-style storage infrastructure where different ranges of keys are assigned dynamically to different servers (storage isn't actually backed by BigTable, but the same principles apply). This means that deleting data is no longer a necessarily a single region action and it becomes very expensive to effectively make the deletion appear transactional. Firestore transactions are currently limited to 100 participants and this means that any non-trivial transactional bulk deletion is impossible.
We're investigating how best to surface an API that does a bulk deletion without promising transactional behavior. It's straightforward to imagine how to do this from a mobile client, but as you've observed this wouldn't be efficient if all we did is embedded the loop and batch delete for you. We also don't want to make REST clients second-class citizens either.
Firestore is a new product and there are ton of things still to do. Unfortunately this just hasn't made the cut. While this is something we hope to address eventually I can't provide any timeline on when that would be.
In the meantime the console and the firebase command-line both provide a non-transactional means of doing this, e.g. for test automation.
Thanks for your understanding and thanks for trying Firestore!