Quick Answer
If we run transactional databases, we usually need consistent low latency and stable p99 performance. If we run analytics, backups, or restores, throughput may matter more. We should compare storage using delivered database transactions, VM limits, recovery requirements, and total cost rather than maximum advertised IOPS.
When we choose block storage for a database, it is easy to focus on the service with the highest advertised IOPS. However, the largest number does not always produce the best application performance.
We should look for the lowest-cost configuration that consistently meets our database’s latency, throughput, durability, and recovery requirements. That means evaluating how storage performs with the database, virtual machine, file system, and real workload working together.
In this guide, we compare Amazon Elastic Block Store, Microsoft Azure Managed Disks, Google Cloud Hyperdisk, Oracle Cloud Infrastructure Block Volumes, and AceCloud Block Storage.
Which Storage Metrics Should You Consider for Databases?
The main database storage metrics we should consider are latency, IOPS, throughput, and performance consistency. If you need a broader introduction to the storage model, AceCloud’s guide to block storage in cloud computing explains how block volumes work.
Latency
Latency tells us how long a single storage operation takes. It directly affects:
- Transaction commits
- Write-ahead log writes
- Redo-log and journal writes
- Random database page reads
- Synchronous replication
We should monitor p95 and p99 latency instead of relying only on average. A volume may show acceptable average latency while occasional slow operations delay entire transactions.
If your users experience random response-time spikes, tail latency may be more relevant than peak IOPS.
IOPS
IOPS measures the number of storage operations completed each second. It is especially important when our databases perform:
- Index lookups
- Cache misses
- Small random reads
- Write-heavy transactions
- Checkpoints
- Background flushing
We should also remember that maximum IOPS usually requires multiple operations to run concurrently. A low-concurrency transactional workload may never reach the provider’s advertised limit.
Throughput
Throughput measures how much data the storage transfers each second. It becomes especially important for:
- Full-table scans
- Backups
- Restores
- Bulk imports
- Analytics
- Sequential reads and writes
We can use this simplified relationship:
Throughput = IOPS × I/O size
At an 8 KiB I/O size, 20,000 IOPS produces approximately 156 MiB/s. At 16 KiB, the same 20,000 IOPS produces approximately 313 MiB/s.
This is why we should always include block size when comparing storage performance. An IOPS number without the corresponding I/O size provides limited context.
Why High IOPS Not Always Make Database Faster?
Our database may not benefit from additional IOPS when another part of the system is the real bottleneck.
Delivered performance is limited by the lowest ceiling across:
- Volume IOPS
- Volume throughput
- VM storage limits
- VM network bandwidth
- CPU and memory
- File system overhead
- Database concurrency
- Query and index efficiency
For example, an 80,000 IOPS volume cannot reach that figure if the attached VM supports only 20,000 IOPS.
We may also gain little from additional storage performance if most reads come from memory, our queries are CPU-bound, or locks are delaying transactions. In some workloads, the database needs better synchronous-write latency rather than more parallel I/O capacity.
Queue depth also affects the results. A provider may use deep I/O queues to demonstrate maximum IOPS. That proves the storage can handle substantial parallel activity, but it does not show the latency of one synchronous database write.
We should also be cautious with short benchmarks. Some storage services offer temporary burst performance. A five-minute test may look impressive, but the same volume could slow down during a sustained checkpoint, backup, compaction cycle, or traffic peak.
Provisioned IOPS tells us what the storage can potentially deliver. It does not guarantee faster queries or higher application throughput.
How Do Cloud Block-storage Services Compare?
When we compare cloud block-storage services, we should consider performance limits, pricing flexibility, regional availability, and VM compatibility.
| Service | Maximum performance | Pricing model |
|---|---|---|
| AWS EBS gp3 | 80,000 IOPS and 2,000 MiB/s | Capacity plus additional IOPS and throughput |
| AWS EBS io2 Block Express | 256,000 IOPS and 4,000 MiB/s | Capacity plus provisioned IOPS |
| Azure Premium SSD v2 | 80,000 IOPS and 2,000 MB/s | Capacity, IOPS, and throughput |
| Azure Ultra Disk | 400,000 IOPS and 10,000 MB/s | Capacity, IOPS, and throughput |
| Google Cloud Hyperdisk Balanced | 160,000 IOPS and 2,400 MiB/s | Capacity, IOPS, and throughput |
| Google Cloud Hyperdisk Extreme | 350,000 IOPS and 5,000 MiB/s | Capacity plus provisioned IOPS |
| OCI Ultra High Performance | 300,000 IOPS and 2,680 MB/s | Capacity plus performance units |
| AceCloud High IOPS Block Storage | Confirm performance for the selected tier | Capacity-based pricing |
These figures represent published per-volume maximums. We should not treat them as guaranteed database-level results.
Our selected VM, region, block size, queue depth, and workload must all support the target performance. If one component has a lower limit, it can prevent us from using the volume’s full capability.
AWS positions io2 Block Express for latency-sensitive and mission-critical workloads. Azure and Google Cloud allow us to configure capacity and performance independently on several premium storage tiers. Oracle Cloud uses volume performance units to control available IOPS and throughput.
AceCloud High IOPS Block Storage provides NVMe-backed persistent volumes with resizing, encryption, and snapshot capabilities. Before we make a direct comparison, we should confirm the limits of the selected region, storage tier, and virtual machine.
Last verified: July 23, 2026.
How Should We Compare Block-storage Pricing?
Cloud block storage generally uses one of two pricing approaches.
With the first approach, we pay separately for capacity, provisioned IOPS, and provisioned throughput. With the second, we pay a simpler capacity-based rate, while the included performance depends on the selected storage tier.
We can estimate the full cost using this formula:
Monthly cost = capacity + additional IOPS + additional throughput + snapshots + backups + replication
AWS gp3 includes baseline IOPS and throughput. We pay extra when we provision more performance. AWS io2 charges for both capacity and provisioned IOPS.
Azure Premium SSD v2 and Ultra Disk price capacity, IOPS, and throughput independently. Google Cloud Hyperdisk Balanced uses a similar pricing model. Oracle Cloud combines capacity pricing with volume performance units.
At AceCloud, we offer NVMe High IOPS block storage pricing in India at ₹6 per GB per month in Noida.
For a 1 TiB volume, we can estimate the monthly capacity cost as:
1,024 GB × ₹6 = ₹6,144 per month
We should treat this as a capacity calculation. It does not prove that the volume is performance-equivalent to a hyperscaler disk configured for a specific IOPS and throughput target.
Using representative US pricing, a 1,000 GB AWS gp3 volume configured for 20,000 IOPS and 500 MB/s costs about $187.50 per month. A comparable Google Cloud Hyperdisk Balanced configuration may cost about $179.40 per month in a representative US region.
These examples exclude:
- Compute instances
- Snapshots
- Backups
- Replicas
- Taxes
- Network transfer
- Regional price differences
As buyers, we should compare the complete production architecture rather than the disk price alone. A lower-priced volume may cost us more overall if it causes slower transactions, longer recovery times, or the need for additional database nodes.
Which Storage Should We Use for Each Database Workload?
The right storage tier depends on whether our workload is latency-bound, IOPS-bound, throughput-bound, or capacity-bound.
| Workload | Most important metric | Suitable storage type |
|---|---|---|
| Transactional OLTP | Low write latency and stable p99 | Premium provisioned-IOPS storage |
| Read-heavy database | Random-read latency and IOPS | General-purpose or premium SSD |
| Write-heavy ingestion | Sustained write IOPS | Provisioned-performance storage |
| Analytics and reporting | Sequential throughput | High-throughput SSD |
| Backups and restores | Large-block throughput | High-throughput storage |
| Temporary data | Local latency and IOPS | Local NVMe |
| Transaction logs | Synchronous-write latency | Durable low-latency block storage |
If we use PostgreSQL, we should pay close attention to write-ahead log flush latency because transactions may wait for WAL records to reach durable storage.
If we use MySQL InnoDB, storage performance affects redo-log writes, dirty-page flushing, and checkpoints. A volume that cannot sustain the configured I/O rate may create queues and unpredictable latency.
If we use MongoDB WiredTiger, we need consistent random I/O, journal performance, and predictable checkpoint behavior. Storage becomes more important when our working set exceeds available memory.
Which Block-storage Service Should We Choose?
We can use the following table to create an initial shortlist.
| Requirement | Recommended starting point |
|---|---|
| General-purpose production database | AWS EBS gp3, Azure Premium SSD v2, Google Cloud Hyperdisk Balanced, or a benchmarked AceCloud tier |
| Latency-sensitive OLTP | AWS EBS io2 Block Express, Azure Ultra Disk, Google Cloud Hyperdisk Extreme, or OCI Ultra High Performance |
| Analytics and backup workloads | High-throughput general-purpose SSD storage |
| Temporary or rebuildable data | Local NVMe |
| Highly variable performance demand | Storage with independently adjustable IOPS and throughput |
| India-based, capacity-conscious workloads | AceCloud High IOPS Block Storage, subject to benchmark validation |
| Strict recovery requirements | Durable block storage with snapshots, replicas, and tested restoration |
We should treat this as a starting point rather than a final purchasing recommendation. Before you commit to a service, test it on the intended VM, in the intended region, with a workload that resembles production.
Should You Use Local NVMe or Network Block Storage?
Local NVMe can give us excellent latency and high IOPS at a lower cost than some premium network-attached block-storage services. It also introduces a greater risk of data loss.
Local NVMe data may disappear when an instance fails, stops, or is replaced. We should generally use it for:
- Temporary tables
- Sort and spill files
- Caches
- Rebuildable indexes
- Replicated database shards
Persistent network block storage is usually a better choice for:
- Authoritative database files
- Transaction logs
- Persistent indexes
- Snapshot-based recovery
- Databases that must survive instance replacement
We should use object storage for backups, archives, and infrequently accessed data. AceCloud’s guide to block storage vs. object storage explains the difference in more detail.
How Should You Benchmark Database Block Storage?
We should test database block storage at the raw-storage, file system, database, and recovery layers.
Start with fio tests that cover:
- 4 KiB, 8 KiB, 16 KiB, 64 KiB, 256 KiB, and 1 MiB blocks
- Queue depths from 1 to 64
- Random reads
- Random writes
- Mixed read and write workloads
- Sequential throughput
- Synchronous writes
Next, we should test the actual database using:
- pgbench for PostgreSQL
- Sysbench for MySQL
- YCSB for MongoDB and other NoSQL systems
- HammerDB for SQL Server and Oracle
- Production traffic replay when possible
We should report:
- Transactions per second
- p50, p95, p99, and p99.9 latency
- Read and write IOPS
- Throughput
- CPU utilization
- I/O queue depth
- Database cache-hit ratio
- Cost per completed transaction
We should avoid testing a dataset that fits entirely in memory. We should also avoid short burst-based tests and comparisons that use different block sizes or queue depths.
AceCloud’s block storage benchmarking guide covers IOPS, throughput, tail latency, and realistic queue-depth testing.
How to Choose the Right Block Storage Option?
We can follow this process:
- Determine whether our workload is latency-bound, IOPS-bound, throughput-bound, or capacity-bound.
- Define the required transaction rate and p99 latency.
- Measure the workload’s block size, concurrency, and read and write ratio.
- Verify the VM’s IOPS, throughput, and network limits.
- Include snapshots, replicas, backups, and recovery in the total cost.
- Benchmark the real database and select the least expensive configuration that meets the target.
We should consider premium storage when latency directly affects revenue, transaction completion, customer experience, or service-level objectives.
General-purpose storage is usually enough when it already meets our required p99 latency and sustained throughput.
AceCloud’s guide to block storage reliability, RPO, RTO, and high availability can help us include recovery requirements in the decision.
Final Takeaway
The best block storage for our database is the least expensive configuration that meets our p99 latency, sustained throughput, durability, and recovery targets under a realistic production workload.
We should not use maximum IOPS alone as our selection criterion. Instead, we should evaluate the complete system, including the volume, VM, file system, database engine, backups, replicas, and recovery process.
Whether we choose a hyperscaler service or AceCloud NVMe Block Storage, we should base our final decision on delivered database results. You should choose the configuration that gives your workload consistent performance without forcing you to pay for capacity that your application cannot use.
Frequently Asked Questions
For transactional databases, latency is often more important because each commit may wait for a durable log write. If you run analytics, scans, backups, or restores, throughput may matter more.
No. Our VM limits, CPU, memory, file system configuration, query design, and database behavior may prevent the application from using all provisioned IOPS.
Storage may be the bottleneck when disk latency, queue depth, and database I/O waits rise while transaction performance falls.
We should check these metrics alongside CPU utilization, lock waits, query plans, and cache-hit ratios. High disk utilization alone does not prove that storage is the root cause.
Separate volumes can reduce contention and improve monitoring because data files often generate random I/O while transaction logs require latency-sensitive sequential writes.
The design only improves performance when the volumes have independent performance capacity. It may provide little benefit when both volumes share the same VM-level storage limit.
It depends on the storage service. Some products link available IOPS and throughput to volume size. Others allow us to configure capacity, IOPS, and throughput independently.
We should always check both volume-level and VM-level limits before increasing capacity only to improve performance.
IOPS measures how many storage operations complete each second. Throughput measures how much data transfers each second. Latency measures how long an individual operation takes.
If we run OLTP databases, we will usually prioritize latency and random IOPS. If we run analytics, scans, backups, or restores, we will usually prioritize throughput.
Local NVMe is suitable for temporary, rebuildable, or replicated data. We should not use it as the only copy of critical database information because the data may disappear when the instance fails or is replaced.
AceCloud lists NVMe High IOPS Block Storage at ₹6 per GB per month in Noida. A 1 TiB volume costs approximately ₹6,144 per month before compute, snapshots, backups, and other services.
Not from the capacity price alone. AWS and Google Cloud allow us to provision specific IOPS and throughput levels, while AceCloud’s listed rate is based on capacity.
We should compare these services using measured latency, sustained IOPS, throughput, VM limits, recovery capabilities, and total database cost.
