[stillkicking]

...and you will show your users stale data, which is a non-starter for a chat app. You will then need to implement some custom push/invalidate mechanism, based on a custom interpretation of the DB event log.

The entire point of the Fire* style of database is that these trade-offs are not worth it in the long run, that few development teams have the skill and time to implement this themselves, and that databases can and should solve this for you.

I have little love for Cloud Firestore, it's a trash fire riddled with poor decisions, but if you don't even understand what the problem is with that SQL query, you don't understand the expectations users have nowadays of front-end applications.

[folkrav]

You're on HN, where we still long for the "documents with links" days of yore.

[manigandham]

Why would a SQL query show stale data? Inserts and selects are fine, the only thing needed is signaling. You can use Firestore for that, or just a separate thin layer on a much more capable database backend.

> "that few development teams have the skill"

This is the fundamental problem. There's no magic answer to a lack of skill.

[mhoad]

Because the way that you will ultimately have to scale something like PostgreSQL for example is going to end up with eventual consistency which Firestore doesn’t have to deal with.

[manigandham]

There's no reason for eventual consistency. Firestore is backed by BigTable and Spanner (both strongly consistent just like Postgresql). There's nothing magic about this - it just provide a pub/sub channel on the watched keys and automatically does a SELECT loop in the background once an INSERT triggers that key.

You can do the same thing on a simple by selecting by a `chatid` in a table that'll get the latest messages/inserts. Again, the only thing needed is the pub/sub layer, not an entirely different database.