[randomdata]

> I always assumed that an architectural decision had prevented relational queries in Firebase.

Seems the biggest problem is that Firebase doesn't have relations. How can you query that which does not exist?

I'm guessing what they really want is SQL? Once upon a time when I was stuck on a Firebase project I built a SQL (subset) engine for Firebase to gain that myself, so I expect that is it.

[unsupp0rted]

Building a logistics app, I wish I could query in Firebase for items that don’t have a “shipped” field.

But I can’t.

[randomdata]

Technically you can: Scan all of the documents. A "relational query language" would have to do the same thing.

[unsupp0rted]

That wouldn’t be querying though, right?

Grabbing all the docs in the db into my controller and filtering down that array is what Firebase makes me do instead of writing queries.

[randomdata]

> That wouldn’t be querying though, right?

Why not? You're asking a question, of sorts, and getting an answer from the result. That's the literal definition of querying.

> Grabbing all the docs in the db into my controller and filtering down that array is what Firebase makes me do instead of writing queries.

A query language is just an abstraction. One you can have in your code. At some point you still need to "grab all the docs into a controller and filter them down", though. You could push that step into the Firebase service, but it would still have to do the same thing you're doing. There is no magic.

Better would be to provide something indexable so that you don't have to go through all the docs, but you can't index that which does not exist.