[stickfigure]

This is not correct. You can filter on the same field twice. What you can't do is filter on different fields, eg:

I want records where record.score >= 10 and record.date <= 2022-01-01

The first form (single field) is a simple range query on a single index - that's what Firestore is optimized for. The second form (with different fields) potentially requires walking the near-entirety of both indexes looking for matches, and therefore has unbounded time and computational requirements.

Firestore is designed so that you can't do things that don't scale. Sometimes that sucks, especially when you know that the data volume for that query will always be "reasonable". But the limitations are not arbitrary.

[danielvaughn]

I never assumed they were arbitrary, it's more that they don't fit the product. This DB architecture fits some use cases, I'm sure, but the decision should be made by an experienced person. In the real world, what happens is that early stage startups get hooked on the whole "fast and scalable prototype" marketing copy, then hire some FE devs that build the entire app on Firestore because they don't know any better. 99 times out of 100, a startup's use case is not going to be a good fit for Firestore, but Firebase has no vested interest in informing the customer about this little detail. I've only worked with Firebase for 1 year and I've now seen this exact situation happen 3-5 times.