Design data storage solutions →hardMultiple Choice

AZ-305 Design data storage solutions Practice Question

A company runs a large-scale write-intensive application that requires a horizontally scalable relational database. They need to distribute data across multiple nodes to handle high write throughput while supporting SQL queries, including joins and transactions. The solution must be fully managed and provide elastic scaling. Which Azure database service should they choose?

⚠ Common exam trap

Watch out — candidates often confuse 'horizontal scaling' with 'hyperscale' or 'managed instance' options, assuming any 'scalable' database service supports distributed writes, but only Citus provides true horizontal sharding for relational workloads with full SQL and transaction support.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

Azure Database for PostgreSQL Hyperscale (Citus)

Azure Database for PostgreSQL Hyperscale (Citus) is the correct choice because it provides horizontal scaling (sharding) across multiple worker nodes using the Citus extension, which distributes data and parallelizes SQL queries. It supports full SQL, including joins and transactions, while offering elastic scaling for write-intensive workloads. This makes it ideal for large-scale relational databases that need high write throughput and horizontal scalability.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
Azure SQL Database Hyperscale
Why it's wrong here
Azure SQL Database Hyperscale is relational but it only scale-out for reads: it separates compute and storage and can add read replicas, yet all read-write traffic is serialized through a single primary replica. Because every insert and update must be applied on that primary and its transaction log, write throughput cannot be horizontally scaled by adding nodes. A large-scale write-intensive workload still hits a single-writer bottleneck, so this service does not satisfy the requirement.
✗
Azure Cosmos DB
Why it's wrong here
Azure Cosmos DB is a globally distributed, multi-model NoSQL database; its SQL API uses syntax resembling SQL, but it does not implement a full relational engine with arbitrary cross-node joins and multi-table ACID transactions. Queries spanning partitions are limited and can be expensive, and transactional guarantees are scoped to a single logical partition or batch with one partition key. Even though it offers strong elastic write scalability, it cannot meet the requirement for full relational join and transaction semantics.
✓
Azure Database for PostgreSQL Hyperscale (Citus)
Why this is correct
Azure Database for PostgreSQL Hyperscale (Citus) is a managed relational database that horizontally shards tables across worker nodes by choosing a distribution column. Writes are distributed to multiple workers in parallel, so write throughput can scale out as worker nodes are added. It preserves full PostgreSQL SQL semantics, including distributed joins, foreign keys, and ACID transactions, making it the only option that combines relational integrity with horizontal write scaling.
✗
Azure SQL Managed Instance
Why it's wrong here
Azure SQL Managed Instance is a platform-as-a-service deployment of the SQL Server database engine and provides excellent compatibility, automated patching, and built-in high availability, but it runs as a single primary instance. You can scale compute and storage vertically or add read-only replicas, but there is no built-in sharding or multiple writable nodes to distribute write load. A heavy write workload is therefore constrained by the instance's compute and log throughput, so it does not meet the horizontal scaling requirement.

Go deeper

AZ-305 Design data storage solutions Practice Question

Why each option matters

Option-by-option breakdown

Related to this question