Cutting Load Time by 65% on a Multi-Tenant SaaS Platform

A multi-tenant SaaS platform came to us with a familiar complaint: support tickets about “the app feels slow,” a churn rate creeping upward, and no idea where the time was actually going. Median load time looked fine on the internal dashboard. The real story was in P95 — the tenants with the largest datasets and the busiest teams, exactly the accounts most worth keeping.

The challenge

The platform served hundreds of tenant workspaces from a shared Postgres database, with dashboard routes that had grown organically for two years. Every new feature had added a query, a join, or a client-side fetch, and nobody had gone back to remove what was no longer needed. P95 page load sat at 4.2 seconds on the busiest routes — well past the point where users start bouncing mid-session.

The business risk was concentrated exactly where it hurt most: large tenants generating the most revenue were the ones hitting the worst-case query plans, because their datasets were the ones cold caches and missing indexes punished hardest.

The audit

Before changing anything, we instrumented the request path with server-timing headers reporting database time, cache time, and render time per route, sampled to a dashboard. This turned “the app feels slow” into a ranked list of exactly which routes, which queries, and which percentiles were the problem — no guessing, no rewriting code that wasn’t actually slow.

Three queries accounted for roughly 60% of P95 time platform-wide. Two were missing indexes an EXPLAIN ANALYZE pass caught in minutes. The third was a hot-path query that scanned full tenant history instead of the recent window the UI actually displayed.

The fixes

• Targeted indexing. Partial indexes scoped to the access pattern that mattered (recent, active records) instead of blanket indexes that bloat write time.
• Read replicas for reporting queries. Heavy aggregate queries were moved off the primary, so dashboard analytics no longer competed with transactional writes during peak hours.
• Rebuilt rendering pipeline. Sequential await chains that fetched data one step at a time were parallelized, and routes that didn’t need server-side personalization were made cacheable.
• Edge caching with explicit invalidation. Only routes that were deterministic functions of their URL were cached at the edge, tagged, and revalidated on the exact writes that changed them — avoiding stale data without giving up the win.

Every change shipped behind a feature flag with gradual rollout by tenant, so regressions were caught on a small slice of traffic before reaching every workspace.

The results

Six weeks in, P95 load time dropped from 4.2s to under 1.5s on the platform’s worst routes — a 65% reduction. Retention among the largest tenants improved 18% over the following quarter, and support tickets referencing slowness dropped to near zero. None of it required a rewrite; it required measuring honestly and fixing the handful of things that were actually slow.

If your SaaS platform has the same shape — fine on the median user, painful for your biggest accounts — I run this same audit and typically find the first 30% of the gain in week one. For the deeper technical playbook behind this kind of work, see cutting P95 latency on a Next.js + Postgres stack.