I'm using an Azure SQL Database on the Standard tier with 20 DTUs, which suits our low-performance requirements and costs about €25/month. However, we're encountering reliability issues, and I really need to boost availability without breaking the bank, ideally keeping costs under €200/month.
I've explored some options like Failover Groups and Premium tiers, but they either add too much complexity or drastically increase costs. The Failover Groups option seems promising but requires custom failover logic, and I'm unsure about the actual effort needed for that.
Premium and Hyperscale tiers are way outside my budget, so I'm looking for a balanced solution. Would setting up Failover Groups with custom logic be my best route, or is there something else I might be missing?
3 Answers
For your scenario, Failover Groups could be a bit much, especially with the manual efforts you’d require for failover alerts. If the downtime is really just around 30 minutes monthly, you're probably fine without major changes. Just make sure your app can handle those brief outages with retry logic in place. There might not be a perfect solution, but managing expectations within your current tier could be workable.
Would you consider moving to another service if Azure keeps giving you these issues? Sometimes a small switch can solve more significant headaches, especially if it’s just about cost efficiency and reliability. You could save on the high costs of Failover Groups and look for a more stable alternative.
It sounds like your main issue is the reliability of your connection. If it's only going down once a month, you might not need anything overly complex. Have you considered simplifying your database calls or checking for network issues? It might alleviate some downtime without having to implement a full failover logic. Sometimes just optimizing the connection can make a big difference.
That's a good point! Maybe just looking at network settings could fix the problem without extra costs.
I agree; it might be better to tweak your app to handle those downtime periods rather than overhauling your database setup.