3,026 Queries to 16: What We Checked Before Calling a Dashboard Faster

Our internal operations dashboard had become slow. Before buying more server capacity, we looked at what one list request was doing.

The September 11 engineering report from our project recorded 3,026 database queries in an isolated test using a copy of real data. Related records were being fetched one row at a time, and the initial response carried roughly 1.5 MB before anyone opened a detail view.

Change what the page asks for

The changes were straightforward to describe, but not trivial to validate:

1. Return paginated summaries, not complete records, in the list.
2. Batch related-record lookups instead of repeating them for each row.
3. Fetch details when a user opens them.
4. Keep ordering deterministic and measure both response size and latency.

Under the reported test conditions, the main list query count fell to 16, plus two read-only transaction-control statements. Median request time fell from 343 ms to 13 ms; at ten concurrent requests, p95 fell from 3,303 ms to 230 ms. The response fell to roughly 60 KB before compression, or 10.6 KB compressed.

These are figures from our isolated comparison, not a promise of the same improvement on every dataset or a measurement of long-term production reliability.

A faster response can still be the wrong response

For our team, speed was only half the acceptance question. The other half was whether the same people could still see and act on the same records.

The comparison needed to cover permissions, filters, recent-activity rules, pagination, cross-page selection, bulk assignment, and login behavior. A changed sort order or a missing permission check would make a fast dashboard worse, not better.

That is the part I would bring to another team: write down the behavior that must remain unchanged before asking an AI coding agent to optimize the implementation. Then compare the old and new versions against that checklist, alongside the timing results.

A benchmark supports a performance claim within its test conditions. Production operation needs its own checks. Keeping those two conclusions separate makes the result much more useful than a single impressive speedup number.