Your arguments are definitely valid. Having faced similar barriers, i.e. N+1 problem, etc., my solution was to offset these issues by also storing and coordinating data in Firebase realtime db, specifically data with high i/o such as chats, or reference data such as username/profile pic look-ups. Essentially anything that would incur high doc reads/writes.
Not saying splitting into 2 distinct db's did not add complexity or is the right choice for all, and the verdict is still out for me, but it is one solution. Since the realtime db lacks the scaling of Firestore and would eventually require sharding to scale, guess time will tell.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Your arguments are definitely valid. Having faced similar barriers, i.e. N+1 problem, etc., my solution was to offset these issues by also storing and coordinating data in Firebase realtime db, specifically data with high i/o such as chats, or reference data such as username/profile pic look-ups. Essentially anything that would incur high doc reads/writes.
Not saying splitting into 2 distinct db's did not add complexity or is the right choice for all, and the verdict is still out for me, but it is one solution. Since the realtime db lacks the scaling of Firestore and would eventually require sharding to scale, guess time will tell.