Switching between different database purchasing models

Question

Hi,

We are thinking about changing purchasing models for our database, from a DTU-based model to a vCore-based model. My question is, if we switch to a general purpose vCore-based model, and we for some reason are not happy with it, can we easily switch back to the DTU-based model? The database is in the North Europe region.

Anything else we should have in mind when switching?

Regards, Markus

Answer 1

Yep — in general, switching from a DTU-based model to a vCore-based one (e.g. General Purpose) is reversible (you can switch back), with some exceptions and caveats.

Migrating a database from the DTU model → vCore model is supported via Portal / PowerShell / CLI / T-SQL. A database migrated to vCore can be migrated back to the DTU-based model at any time except for those that have been moved to the Hyperscale tier. So as long as your target vCore tier is General Purpose or Business Critical, and not Hyperscale, reverting is supported. Hyperscale is a one-way shift (no going back to DTU or non-Hyperscale vCore tiers) once you move into Hyperscale.

There are a few things to check / keep in mind when making the switch (and possibly switching back)

Area	What to check / possible risks
Performance equivalence / mapping	DTU is a bundled measure (CPU + IO + memory + etc). vCore lets you pick hardware generation, CPU count, etc. The “rule of thumb” is ~ 100 DTUs in Basic/Standard ≈ 1 vCore in General Purpose, and ~ 125 DTUs in Premium ≈ 1 vCore in Business Critical. But this is approximate: hardware gen, IO/latency, etc matter. So after switching, performance may differ.
Storage / size limits	Some vCore tiers have different maximum database sizes, storage limits, or IO capabilities than certain DTU tiers. If your DTU-tiered DB is large, ensure the target vCore tier can support its size and IO needs.
Hardware generation availability by region	Not all hardware generations (Gen4, Gen5, etc.) are available in all Azure regions. That may affect your performance/price when choosing vCore.
Geo-replication / Failover / Secondary databases	If using replicas, secondaries, failover groups, etc, need to make sure that those are compatible, or you upgrade/downgrade in the correct order. Sometimes you must first upgrade secondary, then primary, etc.
Downtime / cut-over time	The operation is similar to scaling between service tiers — there is minimal downtime, but there is some downtime during the cutover. How much depends on size, load, etc.
Cost implications	vCore gives more granular control, but with that, you may see cost differences depending how many vCores, storage types, etc. Also, vCore opens up options like Azure Hybrid Benefit, possibly reserved capacity, etc.
Feature differences	Some features differ by service tier/hardware: IO latency, storage type (remote vs local SSD), high availability features, replica support, etc. Also, Hyperscale has a different architecture. Some features valid in DTU or in non-Hyperscale vCore tiers may not exist or behave differently in Hyperscale.
Maximum limits / quotas	The vCore quota for your subscription/region may limit how many vCores you can provision. If switching many databases, check whether you have enough vCore quota in North Europe. Microsoft has simplified subscription limits, and now vCore limits per subscription per region are in place.
Billing / pricing model changes	Because of differences in how compute, storage, IO are charged, changing models means you’ll want to re-estimate your monthly / usage costs. Also, price per GB storage, cost of backups etc may differ.
Testing / performance regression	Since mapping is approximate, before going for production traffic or switching thousands of DTUs to a certain vCore count, it’s good to test under load to see the performance. Especially around IO, latency, concurrency.

---

If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

hth

Marcin