I'm building an app which uses Firestore for storing most data. The app has a chat functionality and I was considering using Realtime Database for that. What are the benefits of using Firebase Firestore vs Realtime Database for this chat functionality? If there is no difference, should I use Firestore for everything?
P.S. I have already read the firebase comparison of the two https://firebase.google.com/docs/database/rtdb-vs-firestore and I am still not sure which way to go about this.
FB RTDB was designed for a chat application but is not so great for more than simple querying. Firestore was developed to improve the querying requirements and is newer. Newer doesn't necessarily mean better, depends on the use case. Their pricing models are very different, so you need to understand how your use case will be charged.
You can use both of course. They can work well together but if a simple chat requirement is all you need, I would use RTDB.
PS. The unique keys generated in RTDB for each new record are automatically in chronological order, which relates back to it being designed for a chat app. There is a caveat though, the chat messages may still get out of order because the keys are generated on the device and if the device clocks are slightly out and messages are being exchanged rapidly then you may get a miss timing. The way round this is to write each record with a property of server time...and use that to sort the chat messages. Hope that helps your decision.
PPS. RTDB charges for data storage volumes and data download volumes. Firestore charges for storage and db reads and writes. There will be a lot of the latter in a chat app so I would recommend running some what-if scenarios in Excel.
So which one is more real-time?
I don't think one is more realtime than another.
But then Firestore came to existence, from there onwards we saw a lot of recommendations for Firestore
That's right, Firestore has some new features over Firebase realtime database, that why it is named "the new flagship". The query performance depends on the number of items you request and not of the number of items you request them from. So every time you think to get data, get it in such proportion to maintain the speed that you were talking about. As the guys from Firebase team say, Cloud Firestore has a performance guarantee, there are no slow query, so the time it takes your app to retrieve data depends only on the amount of data you retrieve and not on the amount of data you have on Firebase servers. With other words, it doesn't matter if you have one thousand, one million, or even one billion documents within a single collection, retrieving for instance 15 of them, will always take the same amount of time.
This performance comes with some constraints and for that, I recommend you take a look at all sections within official document regarding getting data in Cloud Firestore. That's the reason why Firestore uses those constraints, is due to the fact that is mandatory to maintain this performance guarantee. But from my experience, there is no "SQL" query that cannot be translated in a way or another in Cloud Firestore.
So remember, it really does not matter if you request a single document out of a 10 or one item out of 100.000 or 100.000.000.000, the result will come in the exact amount of time. Here I took as an example one document. So regarding speed, requesting one document out of 100 million will be faster than requesting 10 items out of the same 100 million. So the number of documents in the collection has no effect on the query performance.
This is about Cloud Firestore but there two main resources that I recommend you read before using one or another:
https://firebase.google.com/docs/database/rtdb-vs-firestore https://firebase.googleblog.com/2017/10/cloud-firestore-for-rtdb-developers.html So check the price models for each one of them. But IMHO, both Cloud Firestore and Firebase realtime database work extremely fine together.
