Hey all,
Curious what the consensus might be here. Our app sits on our main sql DB, wondering if you’d look to separate out the DB for basic dynamic blog content to avoid any load on the core apps DB performance?
Matt
I’d stick with the one to start with and as traffic grows look at a managed database provider. They typically offer standby nodes and automatic replication if the main DB goes offline.
By that stage I’m also looking at load balancing the front end app/site too.
Hey @max_gb - we are moving over from an existing site that already has high traffic volume, so I was just wondering if a standard approach would in fact be to have separate DB’s for say a blog over the actual functional app? Sounds like you would go down that path?
Just out of interest, what do you count as high traffic volume? I see what you’re saying now. Yes, you could separate (again depending on traffic figures) but they equally could both run on the same db server with good housekeeping.
Currently around 30/40k unique a month - but this is going to ramp up quite a bit with the current changes we are implementing. I know it’s not millions - but always thinking about the core apps performance.
One of the things I ran into with postgres was limited number of connections. I am using AWS RDS Managed DB for our prod DB, so I’m assuming this just scales and we won’t hit a connection limit - just with 30/40k per month plus concurrent use with our existing users - I didn’t want to risk hitting performance issues and connections issues…
Ok, well in that case it sounds like two databases may be your preferred option. Quick info on the number of db connections in RDS here -
You could also take a look at Aurora Serverless if you’re in the AWS bubble. It’s Postgres compatible and scales with your needs. Not sure on pricing but may be more suitable than RDS if you’re unsure of traffic volumes or concerned with connection limits and timeouts.
1 Like
Thank you Max. This is really helpful