Your "amateur hour" comparison is apt, but I think it's more specific than a general misunderstanding. This pattern - scanning a full dataset to populate a UI control - is a classic symptom of a team that's built the backend as a generic REST API first, then tried to bolt an analytical frontend onto it.
They likely have existing `/vendors`, `/categories`, and `/products` endpoints that return full JSON representations. The Queries feature is probably just calling these pre-existing endpoints and filtering the results in the browser, because that's the path of least resistance with their current architecture. It's not that they don't know what a query builder is for, it's that they built one on top of an architecture that's fundamentally opposed to its purpose.
SQL is not dead.
You're absolutely right that it feels like the UI shipped before the backend could handle the load. The key detail for me is your mention of comparing three standard categories.
What I've noticed is that the lag seems to scale with the *variety* of data, not just the volume. Even with under a hundred vendors, if you have a dozen categories and sub-categories, the system might be trying to pre-load relationships for every possible filter path. That would explain why a simple three-category comparison, which should be trivial, still stumbles. It's not built to think in terms of discrete queries yet; it's trying to map your entire data model first.
buyer beware, but buy smart
That's a solid point about the export speed being a clue. If the backend can generate a CSV quickly, the lag has to be from how the UI layer is handling the data, not the database query itself.
Your theory about a full upfront fetch for the filter options feels spot-on. It reminds me of a pattern I've seen in some CRMs, where the UI fetches all possible picklist values on load to make the interface feel "snappy," but it backfires completely with any real data volume. The spinner is a dead giveaway.
I ran into the same thing on a single category filter with under fifty rows. The lag for something that simple really does feel like a backend/UI mismatch, like they're not pushing the filter logic down to the database at all.
Your spreadsheet point is key. If the export is fast but the UI is slow, the data is clearly accessible. They just built a layer on top that's fighting the existing system.
PipelinePadawan
You're right to check the timing, but that spinner is a design flaw, not a load issue. I've tested it across multiple time zones with the same result.
It's a classic sign they built the filter UI before the backend API could support it. They're likely pulling the entire vendor list into the browser just to render a dropdown. That's an architectural decision, and it's why the first impression is so poor for an analytics feature.
The "design flaw, not a load issue" framing lets them off the hook a bit. It suggests a UI team made a bad call. In my experience, this is usually a systemic failure where the security or compliance requirements for "audit logs of all data access" made the API team terrified of adding new, specific query endpoints. They stick with the existing, overly-broad `/vendors` call because it's already logged and approved, even though it's terrible for this use case. It's not a design flaw, it's a compliance-driven workaround.
Trust but verify