How to scale a vibe-coded app before it breaks

You cannot fix what you haven't measured, and the average load time actively lies to you. If 95% of requests take 100ms and 5% take 8 seconds, the average reports a reassuring 450ms while one in twenty real users is having a miserable experience.

In Postgres, enable pg_stat_statements and pull your slowest queries directly, ranked by actual time spent, not guesswork:

select query, calls, mean_exec_time, max_exec_time
from pg_stat_statements
order by mean_exec_time desc
limit 20;

At the application layer, log per-route duration and compute p50/p95/p99, or use your host's built-in tracing (Vercel Analytics, Sentry Performance) if it's already there.

An N+1 query happens when code fetches a list, then loops over it making one more database call per item. Ten orders becomes eleven queries, ten thousand orders becomes ten thousand and one, and the app that felt instant in testing crawls the moment real data shows up.

The pattern, almost always written this way by an AI moving fast:

const orders = await db.order.findMany();
for (const order of orders) {
  order.customer = await db.customer.findUnique({ where: { id: order.customerId } });
}

The fix, one query instead of N+1, using the ORM's built-in relation loading:

const orders = await db.order.findMany({ include: { customer: true } });

Run EXPLAIN ANALYZE on your slowest query from step one:

explain analyze
select * from orders
where customer_id = 123
order by created_at desc
limit 20;

If the output includes Seq Scan on orders, Postgres is reading the entire table row by row to find matches, no index is helping it. The fix is a composite index with the equality column first and the sort column second, matching the query's own where and order by:

create index idx_orders_customer_created
  on orders (customer_id, created_at desc);

Re-run the same EXPLAIN ANALYZE and you should see Index Scan in place of Seq Scan, with a dramatically lower "actual time" in the output. One caution: every index speeds up reads but slows down every insert, update, and delete on that table, and takes real disk space. Index the columns your queries actually filter and sort on, not every column that seems important.

A query with no limit at all is a ticking clock:

select * from posts order by created_at desc; -- fine with 200 rows, fatal with 2 million

Offset pagination is the common first fix, and it degrades as pages get deeper, because the database still has to scan and discard every earlier row:

select * from posts order by created_at desc limit 20 offset 4000; -- gets slower every page

Keyset (cursor-based) pagination stays fast at any depth, because it filters directly to a starting point instead of counting past rows:

select * from posts
where created_at < $1  -- the created_at of the last row on the previous page
order by created_at desc
limit 20;

Cache data that's read often and written rarely: product catalogs, configuration, public profile pages. A simple cache-aside pattern with Redis:

async function getProduct(id) {
  const cached = await redis.get(`product:${id}`);
  if (cached) return JSON.parse(cached);
  const product = await db.product.findUnique({ where: { id } });
  await redis.set(`product:${id}`, JSON.stringify(product), 'EX', 300);
  return product;
}

// invalidate on write, so stale data doesn't outlive the update
async function updateProduct(id, data) {
  await db.product.update({ where: { id }, data });
  await redis.del(`product:${id}`);
}

Beyond application caching: set Cache-Control headers on API responses that don't vary per user, and put static assets (images, JS, CSS) behind a CDN, most hosts (Vercel, Cloudflare) do this by default, just confirm it isn't disabled.

This is the classic serverless failure: every function invocation opens a fresh Postgres connection, Postgres has a hard connection ceiling (often around 100), and under real load you exhaust it, every request starts failing with "too many connections" or hanging until one frees up.

The fix is routing through a connection pooler instead of connecting directly:

# direct connection - fine for a long-running server process
DATABASE_URL=postgres://user:pass@host:5432/db

# pooled connection - required for serverless / edge functions
DATABASE_URL=postgres://user:pass@host:6543/db?pgbouncer=true

Supabase, Neon, and most managed Postgres providers ship a pooler (often PgBouncer) on a separate port, in transaction mode, made specifically for this. Use it for anything serverless.

The request path must stay fast. Anything that isn't required to answer the request right now, sending an email, generating a PDF, calling a third-party API with unpredictable latency, belongs in a background job, not inline.

// slow: the response waits on however long the email provider takes
await sendWelcomeEmail(user);
res.json({ ok: true });

// fast: hand off the work and respond immediately
await queue.enqueue('send-welcome-email', { userId: user.id });
res.json({ ok: true });

A Postgres-backed job table with a worker loop works fine to start; managed options like Inngest, Trigger.dev, or BullMQ with Redis take over once volume grows.

Returning every column of every row when the UI only renders three fields sends unnecessary weight over the wire on every request, and it's especially painful on mobile connections. Select only what's actually used:

const users = await db.user.findMany({
  select: { id: true, name: true, avatarUrl: true } // not select: '*'
});

A read replica spreads read traffic across a second database instance, at the cost of replication lag (a replica can serve slightly stale data) and real, ongoing operational complexity. Add one only after indexes are fixed, N+1 queries are gone, and a caching layer is in place, and your primary is still maxed on CPU or connections from legitimate read traffic.

In practice, almost no vibe-coded app reaches that point. A single well-indexed Postgres instance comfortably serves thousands of requests per second for a typical CRUD workload. Most requests for "we need a read replica" are, on inspection, actually a request for the index from step three.

If you do add one, be honest about the tradeoff you're taking on: a replica can lag behind the primary by anywhere from milliseconds to seconds under load, so any read that must reflect a write the same user just made (their own order, right after placing it) should still hit the primary. Routing that decision correctly, per query, is the real cost of a read replica, not the infrastructure bill.

Every fix above is a hypothesis until you measure it under load. Use a tool like k6 or autocannon against a staging environment with production-like data volume:

autocannon -c 50 -d 30 https://staging.yourapp.com/api/orders

Record p95 before each fix and again after. If a fix doesn't move the number, it wasn't the bottleneck, go back to step one and measure again rather than guessing at the next thing to change.