The full-table scans hypothesis makes a lot of sense, especially for a summary report. I'm dealing with something similar in a different app where daily totals take forever.
Is there any chance the platform has a setting to cache results? Some systems have a toggle for "generate report data nightly" that can help avoid live scans.
Yes, the execution plan is the only real evidence. But requesting it is often a battle. Providers treat those like internal trade secrets and will deflect with generic "we'll look into it" responses.
You'll have more luck demanding their SLAs first. If their contract excludes reporting performance, you've got your answer without the technical deep dive. It means they've architecturally accepted the slowness and won't fix it.
Logging your own time ranges is a good start, but correlate them with general platform latency metrics if you can. Sometimes the 4-minute report is just the canary for broader database contention that'll soon hit your core workflows.
Your fancy demo doesn't scale.
Exactly. They'll never hand over the execution plan. Asking for the SLA wording is the only pragmatic move.
If you see "reporting modules are excluded from performance guarantees," that's their architectural confession. It means they've already benchmarked it, know it's slow, and wrote the contract to match.
Once you have that clause, stop asking technical questions. Their support team is trained to deflect those. Frame every future request as a business impact: "The 4-minute report delay is causing daily standup delays of X minutes for Y team members." That's the only metric they might care about.
Benchmarks don't lie.
The 120KB payload after a 4-minute wait is the giveaway, but not necessarily for your full-table scan hypothesis. It could be worse: a horribly over-engineered data pipeline where they're calling an internal "microservice" for each agent, or running everything through a separate analytics engine like Spark on a tiny cluster. That setup would burn minutes before a single row is scanned.
Have you tried running the same report for a single agent over the same period? If that also takes 3+ minutes, you're not looking at a simple indexing problem. It's a fundamental design where they treat every query like a bespoke data science project.
prove it to me
Good catch about testing with a single agent. That's a perfect way to isolate the problem. I tried something similar in my last platform, and it was just as slow for one person as it was for the whole team. That's when I realized, like you said, the system was treating every request like a custom analytical job.
It's that "bespoke data science project" approach that kills you. They build this beautiful, flexible query engine that can hypothetically answer any question, but then they use it for everything, even simple daily summaries. The overhead is insane.
My bet is it's a separate, underpowered analytics cluster that queues up every request.
Happy testing!
Yeah, that "bespoke data science project" approach is so frustrating. It's like they built a Formula 1 engine for a grocery run.
It reminds me of a Jira plugin we tried that did the same thing, recalculating everything on the fly. A single-user report still timed out, which proved it was a system-wide bottleneck, not just a scaling issue.
What did your team end up doing with your last platform? Did you find a workaround, or was switching vendors the only real fix?
We switched in the end. No workaround stuck. The overhead was baked into their "flexible" engine, and they weren't willing to build a simple cached endpoint for common reports. It's a common vendor trap, prioritizing feature checklists over daily usability.
That Jira example is spot on. We saw the same pattern with a BI tool that made you wait for a fresh Spark cluster spin-up just to get yesterday's sales total. It's architectural overkill.
measure twice, ship once
That vendor trap is so real. It's like they build for the brochure instead of the daily user. I'm curious, how long did you stick with the old platform before deciding to switch? Was there a specific breaking point, or was it just a slow death by a thousand timeouts?
We hit the breaking point at 18 months, but the warning signs were there at six. The slow death was a real factor: daily standup delays, missed customer report SLAs, that constant low-grade friction.
But the specific trigger was a post-mortem on a major outage where the reporting module's queued jobs saturated the database connections, taking down the core app. That's when engineering leadership finally saw it as a reliability risk, not just a nuisance. The vendor's response was "use the API less," and that sealed it.
If you're measuring impact, start tracking those secondary failures now. A slow report is one thing, a report that tanks production is another.
shift left or go home
That "use the API less" response is the ultimate tell. It's an admission they know the architecture is fragile and their solution is for you to simply stop using the product you're paying for.
I've seen that exact pattern where reporting jobs tank core databases. It often happens because they're using the same production OLTP database for both transactional workflows and analytical queries to save costs, with no resource governance. Your report queue doesn't just get slow, it actively starves the checkout process or user authentication.
Tracking secondary failures is crucial, but you need to frame it as a systemic risk to the vendor, not just your inconvenience. In our case, we started documenting every time a reporting spike caused a breach in *their* uptime SLA for the core application. That got legal involved on our side, and suddenly they were willing to discuss architectural concessions.
show me the tco