Why isn't there a hosted, easy to use relational version of Firestore? I'm using Firestore right now and it's absolutely frustrating in the lack of relations, the lack of accumulation queries (COUNT, MAX, MIN) and in general the limitations of storing what's essentially arbitrary JSON. How is it that to count the number of entries you either need to build in a counter on your own (which can cause race conditions because counters are hard) or manually go through the entire collection and count?
Another option would be a typed JSON db, essentially you could store JSON that corresponds to typed structs a la serde. Would't solve a lot of my problems, but at least I'd have some built in validation.
An earlier commenter noted that one of the features of Firestore is user-level security, i.e. clients can only access their own data.
This makes sense for many apps in a document-based/NoSQL model, and may let you avoid any need for your own back end.
But it makes less sense when you start introducing relations and data models become more complex.
e.g. pretty soon we'll need to join to a lookup table. That presumably means that that lookup table needs to somehow be opened up to all users, while for other tables the user can only access their own data. Starts getting complex real fast.
At what level? Because I know StackExchange runs off of relational databases and they get a solid amount of traffic (with some Redis, but the foundation is relational). Even if relational doesn't scale for Facebook or whatever, if I'm making a piddly little chrome extension or a small website, a simple relational database will scale just fine.
Firebase is designed around syncing, and I imagine that has something to do with it.
If you want a relational database for just one user's data, you could read a SQLite data file over the network when your user opens the app, perform SQL queries over the data in memory, then write the entire database file back across the network when the user hits a "save" button.
But you probably don't want a "save" button, you just want the user's state to be constantly updating back to the server.
And you probably don't want to write back the entire data file every time you save, just the parts that have changed.
So Firebase is optimized to solve these problems, and I bet the data structures they use are not also optimized for supporting all kinds of relational queries.
While the move seems to be towards NewSQL databases (Spanner/CockroachDB), the answer to relations in NoSQL is to model the data differently. This can generally resolve a lot of the problems inherent in the need for relations.
If Cloud Spanner is too big, then you'll almost certainly be well served by Cloud SQL (fully managed MySQL and PostgreSQL): http://cloud.google.com/sql/
Firestore is literally built on top of spanner. So yeah, that's the answer. It's definitely pricey at first glance but it's a fixed cost based on nodes, compared to say datastore where you pay for storage+reads+writes. Different use cases.
Another option would be a typed JSON db, essentially you could store JSON that corresponds to typed structs a la serde. Would't solve a lot of my problems, but at least I'd have some built in validation.