SQLDatabeseのスペックをDTUモデルからvCoreタイプに変更したいが費用抑えつつ置き換えるにはどうしたら良いか

Question

現状、とあるPJでSQLDatabeseのスペックがDTUモデル/StandardのS12で使用しています。

ただ、そのスペックでは足りなくなったので、スペックアップしたいのですが、

DTUモデル/Premiumの最高のバージョンだとコスト的にNGとなる状況です。

そのため、vCoreモデルにし、S12よりバージョンアップ（CPU関連）したいものの、

費用をできるだけ抑える場合、どのようなプランを選択すればよいでしょうか。

S12で使用しているvCore数をそのままセットするととんでもない費用になるのと、

AIに確認したところ、常にフルでつかう訳ではないので、

そこまでのスペックはいらないと聞いたので、

どういう基準で選べばよいかご相談させていただきたいです。

Answer 1

Hi @wataru yoshida

Thanks for contacting to Microsoft Q&A, we have reviewed your question and below are few mitigation steps that may help you to resolve the issue.

Start by assessing how your SQL Database is currently performing. Check whether all your resources are being used efficiently. If your CPU usage has been consistently low, it might make sense to move to a plan with fewer vCores—you could maintain the same performance level while cutting costs. Looking at historical usage data can give you a clearer picture of your database’s actual needs.

The vCore model gives you flexibility to choose both the service tier and the number of vCores. For a budget-friendly upgrade, consider starting with fewer vCores than your existing DTU tier suggests. For example, if you’re using an S12 tier now, you might explore the General Purpose option with a smaller vCore setup to see if it still meets your performance goals.

If your workloads fluctuate throughout the day, the Serverless compute tier could be ideal. It automatically adjusts computing power based on demand and even pauses during idle periods—helping you save on costs without compromising responsiveness.

Use the Azure Pricing Calculator to experiment with different configurations and see which setup delivers the best performance-to-cost ratio for your budget.

Managing several databases? Consider elastic pools. They let multiple databases share resources, which often proves more cost-effective than giving each one its own dedicated resources.

Sometimes, small configuration adjustments—like tweaking the maximum degree of parallelism or compatibility levels—can boost performance without needing to scale up. Always test these changes before applying them broadly.