Performance Tuning Before Launch

In and has followed one app from an empty folder toward production. Performance tuning is the second-to-last stop before the readiness checklist that closes out this module.

I want to be upfront about the angle here. Most SaaS products at launch have a handful of genuinely slow paths and a long tail of things that don't matter yet. The job before launch is finding that handful, fixing it, and resisting the urge to optimize the tail on a guess. Squeezing out every millisecond can wait.

Measure before you touch anything

The single biggest performance mistake I see before a launch is optimizing from intuition instead of data. An engineer decides the ORM is slow, or the frontend bundle is too big, or Redis needs to cache everything, and spends a week on it. Sometimes they're right. Often the actual bottleneck was a missing index on a table nobody thought to check.

Before touching code, get three numbers for your key user flows: server response time, database query time, and time to first meaningful paint on the frontend. You don't need a fancy APM for this at launch. Structured request logging with a duration field, combined with PostgreSQL's pg_stat_statements, tells you almost everything.

-- Enable once, then query anytime to find your slowest queries

CREATE EXTENSION IF NOT EXISTS pg_stat_statements;



SELECT

  calls,

  round(mean_exec_time::numeric, 2) AS avg_ms,

  round(total_exec_time::numeric, 2) AS total_ms,

  query

FROM pg_stat_statements

ORDER BY total_exec_time DESC

LIMIT 10;

This one view does more for pre-launch performance than any amount of speculative tuning. It ranks queries by total time spent, which surfaces both the genuinely slow query and the moderately fast one that runs ten thousand times per hour. Fix in that order.

The database is almost always the first bottleneck

For a typical SaaS backed by Postgres, the database is where response time actually goes. Two patterns account for most of it: N+1 queries and missing indexes on foreign keys or filter columns.

N+1 queries sneak in through ORMs more than raw SQL, because the abstraction hides the loop. Here's the shape that shows up constantly in a multi-tenant NestJS app with TypeORM or Prisma:

// Bad: one query per organization to fetch its owner

async function getOrganizationsWithOwners(orgIds: string[]) {

  const orgs = await this.orgRepository.findByIds(orgIds);



  return Promise.all(

    orgs.map(async (org) => {

      const owner = await this.userRepository.findOne({ where: { id: org.ownerId } });

      return { ...org, owner };

    }),

  );

}

// Better: one query, using a join or relation load

async function getOrganizationsWithOwners(orgIds: string[]) {

  return this.orgRepository.find({

    where: { id: In(orgIds) },

    relations: { owner: true },

  });

}

The fix is rarely clever. It's usually "load the relation you already know you need instead of fetching it in a loop." What makes this worth checking before launch specifically is that N+1 patterns are invisible at ten rows and painful at ten thousand. Your staging data almost never has enough rows to expose it, which is why this bites teams right after their first real customer imports their existing data.

Indexes are the second lever, and the rule of thumb is straightforward: index every foreign key you filter or join on, and every column you filter by in a WHERE clause on a table that will grow past a few thousand rows. For a multi-tenant schema, that almost always includes tenant_id or organization_id, since nearly every query in the app filters by it.

-- Composite index for the most common query shape in a multi-tenant table

CREATE INDEX idx_invoices_org_created_at

  ON invoices (organization_id, created_at DESC);

Run EXPLAIN ANALYZE on your top five queries from the pg_stat_statements list before launch. A sequential scan on a table that will hold real production volume is the clearest signal you'll get.

Connection pooling deserves a mention here too. It shows up as a launch-week failure mode more than a slow-query one. Each Postgres connection costs real memory on the server, and a NestJS app under load can exhaust the default pool fast if every request opens its own connection without limits. Set an explicit, sane pool size (TypeORM and Prisma both expose this) rather than relying on defaults. Put PgBouncer in front of Postgres once you have more than one backend instance, so connections are shared instead of multiplied per process.

Add caching for a reason, not a habit

Redis earns its place in the

About the Author

Hi, I'm Aman Singh — Senior Full Stack Engineer specializing in scalable SaaS products, distributed systems, cloud architecture, and AI-powered applications.

I write about System Design, Full Stack Engineering, Distributed Systems, Redis, PostgreSQL, AWS, Node.js, and NestJS.

• Portfolio:
  


• Product: https://vowerole.com
  


• Email: [email protected]