Exercise 2: Why No Composite Index Is Needed Here, and Why That's Not "SQL Is Better" — Possible Solution
====================================================================

WHY THIS QUERY NEEDS NO COMPOSITE INDEX
------------------------------
The alerts query both filters on one field (status = 'active') and orders by another (expiry_date) in the same query - Firestore specifically requires a composite index whenever a query does both of those together. SQLite has no such requirement at all; a query filtering and ordering on different columns runs correctly with no index declared, and at this app's own realistic scale (a single household's pantry, at most a few hundred rows), a full table scan on every request is fast enough to be genuinely unnoticeable.

WHY THIS ISN'T SIMPLY "SQL IS BETTER"
------------------------------
Firestore's own index requirement exists for good reasons at Firestore's actual intended scale - large, heavily-queried collections where an unindexed scan would be genuinely expensive. The requirement is a real cost at small scale specifically because Firestore is designed and optimized for a very different scale than this app operates at. Calling this "SQL being better" would ignore that Firestore's requirement is a reasonable tradeoff in the context it's actually built for - the honest framing is that SQL has a real, fair advantage specifically at this app's own small scale, not that one technology is unconditionally superior to the other.

WHY THIS WORKS AS AN ANSWER
------------------------------
It correctly explains why this specific query shape (filter + order on different fields) needs a composite index in Firestore but not in SQLite, and correctly explains why that's a scale-specific fair advantage rather than a blanket claim that SQL is the better technology in general.