3 ms·
So: firebase <-- presence, real-time editing, chat, in-memory things firestore <-- things that have a save/submit button, transactional database quick quest
by jopsen 9y ago
So:
firebase <-- presence, real-time editing, chat, in-memory things
firestore <-- things that have a save/submit button, transactional database
quick question:
So the real-time features in firestore are not ideal for real-time text editors and chats. But saving documents from firebase after to user has left is perhaps a good middle ground.
Would firestore charge read for each reader that's listening in real-time when a document is updated?
- habosa 9y agoI wouldn't say the difference is exactly that clear cut. Presence is a clear example of a situation where you want to use Realtime Database over Cloud Firestore. And you're right, for something that you would otherwise do "in memory" or use memcached/redis/etc Cloud Firestore may not be the right fit. In my experience both databases are totally appropriate for a chat app. Even though in Cloud Firestore you will pay a document write for each new chat message, that's only $1.80 for a million chat messages and you get all the rich querying from the Cloud Firestore API. Regarding your pricing question: https://firebase.google.com/docs/firestore/pricing#operations https://firebase.google.com/docs/firestore/pricing#operation... > When you listen to the results of a query, you are charged for a read each time a document in the result set is added or updated. You are also charged for a read when a document is removed from the result set because the document has changed. (In constrast, when a document is deleted, you are not charged for a read.)