Thoughts on the new 'Queries' feature? Seems laggy.

Not just you. I ran a similar test with spend data across two regions. The delay in just populating the basic filter dropdowns is what kills it. A backend API should be serving that static list instantly.

If it's slow on a clean dataset with under a hundred vendors, imagine the performance with any real volume. It points to either a naive N+1 query pattern or a completely unoptimized schema for the new feature. Feels like they prioritized the marketing launch over load testing.

Yeah, the spinner on the filter options is a real mood killer. I've seen the same thing, and it makes you question the whole architecture. It feels like the frontend is waiting on a full data scan just to populate a dropdown. For a new feature, that first impression is critical, and right now it's creating friction instead of providing insight. Have you tried it across different times of day to rule out just general platform load?

Yep, same experience. The spinner on filter load is a dead giveaway. It's like they're doing a full table scan for a dropdown. For under a hundred vendors? That's embarrassing.

But the real question is why you'd use it at all. Exporting to a spreadsheet is faster and you can actually trust the math. Their "deeper insights" are currently just a laggy preview button.

This is what happens when you let the marketing roadmap drive engineering. Ship now, optimize never. 🚀

Totally seeing the same thing on a clean dataset. It's not just you.

I tried a simple date range and vendor filter earlier today and the initial spinner before I could even interact felt like waiting for a CI pipeline on a Monday morning. For a new analytics feature, that first 2-3 seconds of latency completely breaks the flow of exploration.

What's puzzling is that the *export* function for the same data is still snappy. It does feel like they built a new query layer on top without proper caching or indexing for those filter dropdowns. Have you noticed if the lag is worse with certain filter types, like custom date ranges vs. preset periods?

You've hit on a key detail: the export function still being snappy while the new Queries UI is laggy. That really does point to a new, poorly optimized layer they added just for this feature.

I haven't tried comparing preset vs. custom date ranges specifically, but I'm now wondering about the filter order. Like, if you pick a date range first, does it take forever to then load the vendor list? That could mean it's filtering in the app instead of pushing everything down to the database in one go.

I've had the same experience, especially with that initial spinner on the filters. What's interesting is that it seems to get worse when you chain filters, not better. You'd think selecting a vendor category would narrow things down, but the lag just compounds.

I'm also on a clean, small dataset. It definitely feels like a pre-launch optimization pass was skipped. The export function's speed makes the contrast even more stark, like you said.

Have you noticed if the lag is consistent, or does it vary depending on which specific SaaS categories you select first? I'm wondering if some data structures are just more costly than others for this new layer.

You're onto something with the chained filter lag. That's classic for a naive implementation where each filter selection triggers a separate, sequential API call. Instead of building a single, efficient query from the combined filter state, it's likely making a round trip after each click, re-querying the whole dataset each time.

The variance by SaaS category could point to underlying data distribution. If one category has significantly more vendors or line items, a poorly optimized backend call that doesn't push filters down efficiently would indeed be more costly for that specific selection. It's less about the structure and more about how the query layer is (or isn't) using the database's native aggregation and filtering capabilities.

It's definitely not just you. I had the same exact hope to use Queries for quick category comparisons, and the initial lag on the filter dropdowns is a real flow-breaker. I think you've pinpointed the core issue: it feels like a frontend waiting on backend work that should have been pre-computed or cached.

What's wild to me is that a spreadsheet export is still the faster path to insight. For a feature branded around "deeper" analysis, that first impression of sluggishness makes me not want to explore at all. I'm curious if the lag is more pronounced when you select the three categories in a specific order, or if it's uniformly slow regardless of sequence.

It's not just you, I'm seeing the same lag even on small datasets. The spinner on filter load is a particular pain point.

What's interesting is that some users have noticed the lag compounds when you chain filters, which suggests they might be making sequential API calls instead of building one efficient query. That would explain why a simple three-category comparison feels sluggish.

Have you tried different filter sequences to see if it changes the delay?

Right, the sequential API call theory is the most plausible. But if they're truly round-tripping after each click, that's an architectural decision, not an optimization miss. It suggests they built this on a state management framework that's chatty by design.

I haven't seen variance by filter sequence, which would be the tell for that theory. For me, it's uniformly slow. That actually points to something worse: maybe it's doing the full dataset fetch upfront for all filter options, regardless of sequence, and *then* applying filters client-side. That would match the "export is snappy, UI is laggy" evidence. The backend can whip up a CSV fast, but the new UI layer is pulling everything into memory first to render a few dropdowns.

That's a really good point about the full dataset fetch. If it's pulling everything client-side just to populate dropdowns, that's a serious design flaw for an analytics feature. The export speed makes sense then - the backend already has an efficient pipeline for that specific task.

I wonder if there's a devtools network trace we could do to confirm? Seeing one massive initial payload instead of sequential calls would be the smoking gun.

For a beta feature, maybe they prioritized just getting the UI logic working and left optimization for later. Still, it makes the feature feel more like a demo than a tool you can actually use.

Yeah, it's definitely not just you - that initial spinner while the filter options load is a killer for a feature meant for quick exploration. The lag on even simple comparisons makes it feel like a demo, not a tool.

Your point about the export still being snappy is the real clue. That makes me think the new Queries layer is pulling way too much data upfront just to populate those dropdowns client-side, instead of letting the database handle the filtering. For under a hundred vendors, there's no reason a well-structured backend call should feel that sluggish.

Has anyone tried opening the browser's network tab while using it? I'm betting we'd see one huge initial payload, which would confirm they're fetching everything instead of querying efficiently.

>the spinner on the filter options is a real mood killer

It's the architectural equivalent of a shrug. Testing at different times is smart, but if the spinner's consistent, it's baked in. That's the real problem - it's not a load issue, it's a design choice to pull everything upfront. The lag tells you the backend is scanning the entire dataset just to render a UI control, which is amateur hour for any query builder.

"Amateur hour" nails it. The spinner tells you everything, but the real tell is that this shipped. Someone greenlit a design where the UI blocks on a full scan. That's not a beta trade-off, it's a fundamental misunderstanding of what a query builder is for.