Mar 4, 2025

When building distributed systems in the cloud, storage performance can make or break your application’s success. In this post, we’ll explore how different Azure disk types perform under distributed database workloads, using YugabyteDB as our distributed database. We’ll dive deep into benchmarking methodologies and reveal practical insights about Azure storage performance characteristics. The Azure Storage Landscape Azure offers several managed disk types, each designed for different workloads and performance requirements. We’ll focus on three key offerings: Premium SSD: The traditional performance-tier offering, providing consistent performance with burstable IOPS Premium SSD v2: A newer generation offering higher performance and more flexible scaling Ultra SSD: Azure’s highest-performance offering with configurable IOPS and throughput Each of these options presents different performance characteristics and price points, making the choice non-trivial for database workloads. Understanding Distributed Database Workloads Before diving into performance numbers, it’s essential to understand what makes distributed database workloads unique. Unlike traditional single-node databases, distributed databases like YugabyteDB handle data differently: Write Operations: Need to maintain consistency across replicas Often involve both WAL (Write-Ahead Log) and data file writes 2. Read Operations: Utilize caching at various levels Can be affected by data locality These characteristics mean that storage performance impacts database operations in complex ways, often not directly proportional to raw disk performance metrics. Benchmarking Methodology To thoroughly evaluate storage performance, we need a comprehensive testing approach. We employed two industry-standard benchmarking tools: TPC-C Benchmark Stock Level: Read-heavy transaction Each of this transaction is a set of queries that are fired to carry out the business use case. For e.g. the following are the queries that are fired for New Order transaction Get records describing a warehouse, customer, & district Update the district Insert record into Order and New-Order tables For 5–15 items, get Item record, get/update Stock record Insert Order-Line Record For TPC-C, we focus primarily on NewOrder latencies as number of NewOrder transactions define the efficiency. So if the NewOrder latency is 50ms, it means it took 50ms to carry out all the queries listed above. Sysbench Sysbench is a micro benchmarking workload. It creates a bunch of similar tables and the workloads are uniformly distributed across all keys of all the tables. Following are the two workloads that we use most: oltp_read_only — There are 10 selects in one transaction to random tables and random keys. So if the latency of the transaction is let’s say 10 ms, it means each select is taking 1 ms. And if the throughput is 100 ops/second, it means it is doing 1000 selects per second. oltp_multi_insert — There are 10 inserts in one transaction to random tables and random keys. So if the latency of the transaction is let’s say 50 ms, it means each insert is taking 5 ms. And if the throughput is 100 ops/second, it means it is doing 1000 inserts per second. While TPC-C provides a high-level view, Sysbench allows us to examine specific performance characteristics: Enables focused testing of individual operation types Provides precise control over workload parameters Helps isolate storage performance impacts Allows scaling tests with different table counts and sizes We configured Sysbench tests to examine: Point selects (read performance) For Read-Heavy Workloads Premium SSD v2 provides the best balance of performance and cost. The performance gap between Premium SSD v2 and Ultra SSD is minimal for read operations, making Ultra SSD harder to justify purely for read performance. For Write-Heavy Workloads Ultra SSD shows its value in write-intensive scenarios, particularly with larger datasets . The consistent performance and lower latencies can justify the higher cost for write-critical applications. For Mixed Workloads Premium SSD v2 emerges as the most cost-effective option for most mixed workloads. The performance improvements over Premium SSD are significant, while the cost remains lower than Ultra SSD. Conclusion Our testing reveals that Azure disk performance isn’t simply about raw IOPS and throughput numbers. The interaction between storage and distributed database workloads is complex, with CPU often becoming the limiting factor before storage performance is fully utilized. ● If the workload requires low latency, then Ultra SSD would be the best choice. If the workload requires high throughput, then Ultra SSD would also be the best choice. If the workload does not have any specific latency or throughput requirements, then Premium SSD V2 would be a good choice. ● Ultra SSD has the lowest latency and throughput of all three types of disks. However, it is also the most expensive. Premium SSD V2 is a good choice if you need high throughput and are on a budget. Premium SSD is a good choice if you do not have any specific latency or throughput requirements. For most distributed database deployments, Premium SSD v2 provides the sweet spot of performance and cost. Ultra SSD becomes compelling primarily for: Write-heavy workloads with strict latency requirements Large datasets with unpredictable access patterns Mission-critical applications requiring consistent performance When selecting Azure disk types for your distributed database, consider: Your workload characteristics (read/write ratio) Dataset size and growth expectations Performance requirements and budgetary constraints The actual bottlenecks in your current system Remember that storage performance is just one piece of the puzzle. A well-designed distributed database system needs to consider network topology , CPU resources, and memory configuration alongside storage performance for optimal results. Image by author