Design data storage solutions for relational data

Oakridge Dental needs an Azure SQL Database for a small appointment application. The workload is steady and predictable, the database is 5 GB, and the team has no SQL Server licenses to bring. The team wants a simple, bundled price that combines compute, storage, and I/O into one preconfigured unit rather than selecting cores and memory separately. Minimizing cost is the priority.

Which purchasing model and service tier should you recommend?

1. ADTU-based purchasing model, Standard service tierThe DTU model bundles compute, memory, and I/O into a preconfigured unit with simple fixed pricing, and the Standard tier is the low-cost choice for small, predictable production workloads.
2. BvCore-based purchasing model, General Purpose service tierThe vCore model requires choosing cores and memory independently and its main cost advantage, Azure Hybrid Benefit, needs existing SQL Server licenses that Oakridge does not have.
3. CvCore-based purchasing model, Business Critical service tierBusiness Critical adds local SSD storage and a readable secondary that a small steady workload does not need, at several times the cost.
4. DvCore-based purchasing model, Hyperscale service tierHyperscale targets very large databases and rapid scale; it is unnecessary for a 5 GB database and costs more than a Standard DTU database.

Ashgrove Software sells a SaaS product in which each of its 250 customers has a dedicated Azure SQL Database. Each database averages under 5% utilization but has short, unpredictable bursts, and the bursts of different customers rarely coincide. Ashgrove wants to minimize the total cost of the databases without changing the one-database-per-customer model.

What should you recommend?

1. APlace the databases in an Azure SQL Database elastic poolAn elastic pool shares a fixed set of resources among many databases with low average and uncorrelated peak usage, so the pool is sized well below the sum of individual peaks and each database keeps its own isolation.
2. BConvert each database to the serverless compute tier with auto-pauseServerless helps an individual database with idle periods, but 250 databases that each burst unpredictably would each need their own minimum and maximum vCore configuration and would still pay separately for their bursts; pooling is cheaper when peaks are uncorrelated.
3. CConsolidate all customers into one Hyperscale database with a tenant columnThis changes the one-database-per-customer model, which the requirement forbids, and reduces tenant isolation.
4. DMigrate the databases to a single Azure SQL Managed InstanceManaged Instance can host many databases but reserves instance-level vCores at a higher price point than a pool and is chosen for instance-scoped feature compatibility, not for cost optimization of many small bursty databases.

Marlowe Securities runs an order-matching application on an Azure SQL Database. The workload is OLTP with many small transactions and requires the lowest possible storage I/O latency, resilience to the loss of an availability zone, and a built-in readable replica for reporting at no extra charge. Marlowe owns SQL Server Enterprise licenses with active Software Assurance and wants to apply them to reduce cost.

Which service tier should you recommend?

1. AvCore General Purpose with zone redundancyGeneral Purpose uses remote premium storage with higher I/O latency and has no built-in readable secondary.
2. BvCore Business Critical with zone redundancyBusiness Critical keeps data on local SSD for the lowest I/O latency, uses multiple synchronous replicas (zone-redundant when enabled), includes a free readable secondary through read scale-out, and as a vCore tier supports Azure Hybrid Benefit for existing licenses.
3. CDTU Premium with zone redundancyPremium also uses local SSD and offers read scale-out, but the DTU model does not support Azure Hybrid Benefit, so Marlowe could not apply its existing licenses.
4. DvCore Hyperscale with zone redundancyHyperscale is optimized for very large databases and rapid scaling; its readable replicas are separately billed high-availability or named replicas rather than an included free secondary.

Stonemere Games stores player profiles for a mobile game in an Azure SQL Database that is already running at the largest Business Critical compute size. Write throughput is the bottleneck, reads are a small fraction of the load, and the database must stay on the SQL Server engine. The development team is willing to change the data access layer. The design must allow write capacity to keep growing as the player base expands.

What should you recommend?

1. AShard the data across multiple databases by player ID and use the Elastic Database client library to route requestsHorizontal partitioning spreads writes across many databases, each with its own compute, so write capacity grows by adding shards; the Elastic Database tools provide a shard map manager and data-dependent routing.
2. BEnable read scale-out and direct queries to the read-only replicaRead scale-out only offloads reads, which are a small part of the load; all writes still go to the single primary.
3. CMove the database to Hyperscale and add high-availability replicasHyperscale raises storage limits and read capacity, but there is still one primary compute replica accepting all writes, so the write ceiling remains.
4. DPlace the database in an elastic pool with the largest pool sizeAn elastic pool shares resources among databases; a single database in a pool cannot exceed the maximum size of a standalone database.