How do I know if I need sharding?

If you haven’t added the right composite/covering indexes, controlled connections with a pooler, introduced a read replica, and partitioned large tables—sharding is premature. Most teams get 10–100x headroom with those steps. Shard only when you still miss SLOs and write throughput or dataset size exceed single-node limits.

Aren’t too many indexes bad for writes?

Yes—each index adds write overhead and vacuum work. Index only for the access paths you use. Prefer composite/covering indexes that serve multiple queries. Measure write amplification and use `pg_stat_user_indexes` to spot unused ones; drop with `DROP INDEX CONCURRENTLY`.

Can caching hide bugs or stale data?

It can. Cache stable resources (catalog, profiles) with explicit TTLs and busting on writes via events. Avoid caching per-user secrets or rapidly mutating rows. Add cache-hit metrics and alarms for stampedes; use per-key locks as shown.

How do I avoid downtime when adding big indexes?

Postgres: use `CREATE INDEX CONCURRENTLY` and throttle with `maintenance_work_mem`/`autovacuum` tuned. MySQL: use InnoDB online DDL or gh-ost/pt-online-schema-change. Canary the new index by pushing the query plan in staging first.

Are ORMs the problem?

ORMS aren’t evil; opaque queries are. Use them with discipline: explicit selects, preload/joins to avoid N+1, and log the generated SQL. For hot paths, write raw SQL with prepared statements and measured plans.

Performance-optimization · Nov 19, 2025 · 10 minute read

We Cut p95 Checkout Latency from 1.2s to 220ms by Fixing Three Queries—Here’s the Playbook

User growth isn’t what breaks your product—expensive queries do. This is the pragmatic database optimization plan that moves real product metrics without a rewrite.

Back to all posts

We Cut p95 Checkout Latency from 1.2s to 220ms by Fixing Three Queries—Here’s the Playbook

Key takeaways

Implementation checklist