Blog/Case Studies/Case Study: Scaling Clearpath from 8,000 to 400,000 Monthly Active Users

Case Study: Scaling Clearpath from 8,000 to 400,000 Monthly Active Users

S
Sarah Chen
June 10, 202510 min read

Background

Clearpath launched in late 2022 as a lightweight project management tool aimed at small construction and field service teams. They grew steadily to about 8,000 MAU by early 2024 on a single Heroku Postgres instance that worked fine until, suddenly, it didn't.

The inflection point came in March 2024 when they were featured in a popular productivity newsletter. Sign-ups tripled in 48 hours. Their database CPU pegged at 100% for 11 hours. Several enterprise trial customers churned immediately. The company nearly lost its largest deal — a 200-seat account they'd spent four months closing.

What we found

Clearpath's founder, Tom Bergström, brought us in for a database audit the week after the incident. What we found was a textbook case of a schema that was designed for simplicity and never revisited as the product grew:

  • A project_members table with no index on user_id — queried on every page load
  • A notifications table that was never archived — 18 million rows, mostly read, adding 300ms to every user session
  • N+1 query patterns in the activity feed that generated 40–200 queries per page load
  • No connection pooling — 800 connections from a Rails app directly to Postgres

The first set of changes — three indexes and a connection pooler in front of the database — cut average query time by 68% before we'd moved a single byte of data.

The migration plan

We moved Clearpath to a Cluster M on Aureus with a 30-day parallel run. During that window, we:

  1. Archived the notifications table: rows older than 90 days moved to a separate archive table, queries updated to use a view that unions both with appropriate filter pushdown
  2. Partitioned the activity_log table by month — 2.8TB of data reorganized with zero application downtime using declarative partitioning and a background migration script
  3. Added four composite indexes identified by analyzing pg_stat_statements on the live workload
  4. Switched to PgBouncer in transaction mode — connections dropped from 800 to 12

Results

"We went from 'the database is on fire' to genuinely not thinking about it. We're at 400K MAU now and our infrastructure costs are lower than when we were at 50K. That still doesn't make sense to me rationally, but I'll take it."

— Tom Bergström, Founder, Clearpath

At 400,000 MAU:

  • P99 query latency: 4ms (was 340ms at 50K users)
  • Database CPU utilization: 12% average (was 95%+ at 50K users)
  • Monthly infrastructure cost: down 41% from Heroku peak
  • Incidents in 12 months post-migration: zero

What the numbers don't show

Tom's team shipped three major features in the six months after migration that had been blocked for over a year — not because they couldn't code them, but because every engineering conversation kept getting pulled back to database performance. Removing that drag unblocked a product roadmap that's now a genuine competitive advantage.

The best infrastructure work makes itself invisible. By that measure, this was a success.