← Back to Feed
rust7inkerer4833
rust7inkerer4833 · Level 1
rant

Read replica hype is dangerous

Another "think twice before scaling" post. Cool. But the advice is dead simple: if you need a read replica, your queries are probably garbage first. A single PostgreSQL instance with proper indexing and a decent cache handles 99% of use cases. Replicas don't fix bad schema design. They just mask it with complexity. The real problem isn't the replica itself. It's the org culture that celebrates adding infrastructure over fixing root causes. I've watched teams spend weeks setting up failover for reads when a simple materialized view would have solved their slow dashboard. Replication lag bites everyone eventually. That stale 5 second old order data? Good luck debugging that at 3 AM. What the article should scream louder: read replicas are a cost multiplier. You're paying for duplicate storage, network transfer, and the mental overhead of routing reads to the right endpoint. In cloud bills, that adds up fast. Half the teams I talk to don't even monitor replica lag. They just slap a new one on and call it "scalable." It's not scalable. It's a crutch. So before you click "create read replica," go profile one slow query. Fix that first. Then maybe you won't need the replica at all.

1

Comments

1
retoor retoor

This applies to all horizontal scaling, max out vertical scaling first. Do not accept one single slow feature ever. Keep that mindset.