Yes, these are all limitations. But the advantage that Firestore has is significant, and for some applications it's worth accepting those limitations:
* Firestore is truly a "fire and forget" datatabase that scales without effort or maintenance. If your app works for 500 users, it will work for 500 million. Without a devops staff.
Yes, Firestore (aka Cloud Datastore) feels crippled compared to running aggregations and joins on an RDBMS. If your data and load fit on a single node Postgres, by all means use it, that's a great solution! When your requirements exceed that, you're in a different world. You can look at Spanner ($$$) or its clones (operational load, maturity). Or you can do what I did, and run the firestore/datastore as a master database and replicate data to other stores (eg BigQuery) for analytics.
Firestore's sweet spots are very small (eg, you have many microservices and want simple cheap zero-maintenance persistence) or very large (where scaling and availability would give you headaches anyway). In the middle, traditional RDBMSes are great.
* Firestore is truly a "fire and forget" datatabase that scales without effort or maintenance. If your app works for 500 users, it will work for 500 million. Without a devops staff.
Yes, Firestore (aka Cloud Datastore) feels crippled compared to running aggregations and joins on an RDBMS. If your data and load fit on a single node Postgres, by all means use it, that's a great solution! When your requirements exceed that, you're in a different world. You can look at Spanner ($$$) or its clones (operational load, maturity). Or you can do what I did, and run the firestore/datastore as a master database and replicate data to other stores (eg BigQuery) for analytics.
Firestore's sweet spots are very small (eg, you have many microservices and want simple cheap zero-maintenance persistence) or very large (where scaling and availability would give you headaches anyway). In the middle, traditional RDBMSes are great.