Has anyone implemented read replicas for mongodb or postgreSQL? I have a website which will have sudden spikes in traffic just for 15-20min and then back to normal traffic so in such cases I was trying to implement read replicas if traffic increases significantly. One more point is I know already at what time this sudden traffic spike will happen so in such cases can I deploy read replicas to overcome any failures in that time frame? If yes then can someone suggest how can this be done?

Depending on the size of the db and rate of writes, syncing read replica might take a long time. So the "can I deploy read replica in that time frame" might need you to start them long before that time. Also, unless you're fine with these replicas lagging behind, writes will slow down as you add more replicas. It might be worthwhile to ask if a cache might be a better solve for this?

@echoing-computer-87366 we have postgres read replicas at present on our servers which we use to run reporting on etc. I don’t think you can deploy read replicas and bring them down as they need time to sync and come online. More data, longer time it takes. Also if you are on AWS, they do not guarantee a time when the RR will be ready. So you would need it to be running 100% of the time and use that for reads and long data pulls with the expectation that it will be consistent eventually. For example, if I write data now, it may not be available over the next second or so (it’s possible). Hope this helps. Just saw Piyush’s response and I agree a 100% with his caching recommendation. Cost wise, it may be more or less in the same ballpark for a redis machine.

You have 2 good answers here but here are my 2 cents. In AWS ( or any other cloud) when you want to create read replica's, they take a snapshot of the database in real time and use it for your read replica's. So depending on the size of the DB it could take minutes to hours for snapshot creation. ( Once I had to wait for 50 min). During the time snapshot is being taken the performance of your database will deplete. If this is acceptable you can use any IaaC tool to do this for you on scheduled basis. Caching is a great solution but might involve some development efforts. Another workaround is to use a service like Amazon Aurora Serverless. It adjusts the IOPS according to the load. On paper the migration should be seamless. There are some 'gotcha' moments with Aurora Serverless which were addressed in the V2 release. But I suggest you test it thoroughly before considering to make a move. Hope this helps

1. Run ANALYZE on your peak time queries and optimize DB for those (think indexes, maybe move to higher instance etc). 2. (as @dry-monkey-93718 said) Depending on the use case, Redis caching might go a long way.

^ in my initial reply, I had assumed everything else has been checked already. Slightly more thorough, but incomplete list below. A clear sign to guess where you want to start from would be the cpu usage, qps of the db vs server. Db isn't hitting 80%+, servers are = Need more app servers. Db hits 80%+ = check indexes first, then scale machines. Both mongo and postgres can be configured to log slow queries. DB qps grows more than server rps = you possibly have a query in a loop that can be optimised or misconfigured pool. Nothing is hitting high cpu usage, number of connections don't grow, but latency keeps dropping = probably too few connections in the pool. We'll help better if you can share more details about the problem. 🙂

Will redis solve such issue? I have not used redis or memcached that much