Hacker News Reader

Comment by _hardwaregeek | Hacker News Reader

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.

View on HN

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.

Check FaunaDB https://fauna.com/

Because relational databases are much harder to scale. There are many people working on solving this problem.

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.

It's important to note that StackExchange is one of very few examples of successful vertical scaling, at least in the post-mainframe world.

If you want a relational DB as a cloud service, it sounds like you want Cloud SQL (as far as GCP is concerned).

(Disclaimer: I work on GCP.)

Cloud Spanner is also relational. :)

(Fellow GCPer.)

I only know of FaunaDB which is not really relational.

Do you have any other suggestions?

If you want a scalable relational database, that's Cloud Spanner.

Well, I'm actually more interested in serverless databases.

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.

This might not be useful advice for everyone, but I can highly recommend this youtube video on DynamoDB data modelling: https://www.youtube.com/watch?v=HaEPXoXVf2k

... Spanner? It's by the same company.

Looking at pricing, it's a little out of my budget. But thanks for the suggestion!

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.

> Firestore is literally built on top of spanner.

Do you have a source for this? Thanks in advance.

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/

Reply on news.ycombinator.com