The database wall
Every successful application hits the same wall: the database becomes the bottleneck. Queries that took 50ms start taking 5 seconds. The connection pool is maxed out. Your ORM is generating queries that would make a DBA cry. The temptation is to throw hardware at it — bigger instance, more RAM, faster disks. That buys you months, not years. Real scaling requires strategy.
Master the fundamentals
Start with the fundamentals. 90% of database performance problems are solved by proper indexing, query optimization, and connection pooling. Use EXPLAIN ANALYZE on your slowest queries. Add composite indexes that match your WHERE clauses and JOIN conditions. Use PgBouncer or Supavisor for connection pooling — your application doesn't need 200 direct database connections. Implement query result caching with Redis for data that doesn't change every request. These basics will carry you further than most teams realize.
Read replicas
When fundamentals aren't enough, read replicas are your next move. Route all read queries to one or more replicas and keep the primary for writes. Most applications are 80–90% reads, so this effectively multiplies your capacity. PostgreSQL streaming replication is mature and reliable. The trade-off is eventual consistency — replicas lag the primary by milliseconds to seconds. For most use cases, that's perfectly acceptable. For the ones where it isn't, read from the primary.
The nuclear option: sharding
Sharding — splitting data across multiple database instances — is the nuclear option. It solves problems that nothing else can, but it introduces enormous complexity: cross-shard queries, distributed transactions, rebalancing, and application-level routing. Before you shard, exhaust every other option. Partition large tables by date or tenant. Archive old data. Denormalize hot paths. Use materialized views for complex aggregations. At steezr, we've scaled PostgreSQL databases from startup to millions of daily transactions — and we've only needed sharding twice. The boring optimizations almost always come first.