DynamoDB Read Capacity Unit (RCU)

AWS DynamoDB RCU Cost Explained

In DynamoDB provisioned mode, you pay for the number of RCUs you allocate, whether you use them fully or not. This creates a tradeoff:

• Too few RCUs = throttling + higher latency
• Too many RCUs = you pay for idle capacity

A key thing to understand is that DynamoDB read pricing doesn’t exist in isolation. Multiple factors can increase how many DynamoDB provisioned read capacity units are consumed, including:

• Larger item sizes
• Strongly consistent reads
• Secondary indexes
• Transactional operations
• Multi-region capacity requirements (Global Tables require you to provision and pay for RCU capacity in every replica region)

Also, reads and writes don’t cost the same. In many real-world DynamoDB workloads, writes are more expensive than reads, which is one reason teams skip optimizing reads to reduce waste and avoid scaling bottlenecks.

How to Calculate RCU on DynamoDB

To calculate DynamoDB RCUs, you need to account for item size and consistency level.

Step 1: Round item size up in 4 KB chunks

DynamoDB read capacity is calculated in 4 KB increments, meaning an item size is effectively rounded up:

• 1–4 KB = 1 “read unit chunk”
• 4–8 KB = 2 chunks
• 8–12 KB = 3 chunks … and so on.

Step 2: Apply consistency rules For each 4 KB chunk:

• Strongly consistent read = 1 RCU
• Eventually consistent read = 0.5 RCU (because 1 RCU = 2 eventually consistent reads)
• Transactional read = 2 RCUs (Transactions require double the capacity of a strongly consistent read)

Example RCU calculations

Example A: 3 KB item, strongly consistent read

• Size chunk: 1
• Strong read: 1 RCU per read/sec
• Total: 1 RCU

Example B: 3 KB item, eventually consistent read

• Size chunk: 1
• Eventually consistent: 0.5 RCU per read/sec
• Total: 0.5 RCU

Example C: 10 KB item, strongly consistent read

• Size chunk: 10 KB → rounds up to 12 KB → 3 chunks
• Strong read: 3 RCUs per read/sec
• Total: 3 RCUs

This is why AWS DynamoDB costs and throttling behavior can be surprising: even moderate increases in average item size can multiply your RCU requirements.

Pro-Tip: GetItem vs. Query Rounding

• Example D (GetItem or BatchGetItem): Reading 10 items (500 bytes each) via GetItem consumes 10 RCUs (each item is rounded up to 4 KB individually).
• Example E (Query or Scan): Reading those same 10 items (500 bytes each) via a single Query consumes only 2 RCUs (5,000 bytes total ÷ 4,096 = 1.22, rounded up to 2).

ScyllaDB Pricing Model vs DynamoDB Read Capacity Units Pricing

DynamoDB and ScyllaDB use fundamentally different pricing approaches that reflect their architectural differences.

DynamoDB’s capacity-based pricing

In provisioned mode, DynamoDB charges for allocated RCUs whether they’re fully used or not. In on-demand mode, reads and writes are charged per-request, at a premium on-demand pricing. Writes cost 5X more than reads in any capacity mode. Both models require separate provisioning and budgeting for read versus write capacity, with additional costs for secondary indexes, strongly consistent reads, and transactional operations.

This is all done on a per-table basis, provisioning separate read and write capacity for each table under the workload. Multiple tables may have different characteristics due to workload constraints. However, any overprovisioned capacity on a table cannot be salvaged by other table(s) on the account to save on cost. All costs are attributed separately.

ScyllaDB’s resource-based pricing

ScyllaDB charges based on cluster resources (CPU cores and storage) rather than request units. Read-heavy and write-heavy workloads cost the same for equivalent throughput. Performance and pricing scales linearly with cluster size. Unlike with DynamoDB, cluster sizing is not directly influenced by item size, consistency level, or operation type.

Cost impact

ScyllaDB guarantees savings of at least 50% on equivalent workloads migrating off of DynamoDB. The resource-based model also reduces operational overhead by eliminating capacity planning, throttling monitoring, autoscale management, and hot partition troubleshooting. Those tasks tend to consume ongoing engineering time with DynamoDB’s RCU model.

Tables from different workloads can be consolidated on a single cluster, sharing resources and allowing for heavy cost-savings. 

DynamoDB RCU vs WCU 

DynamoDB WCU and RCUs are the two throughput “currencies” DynamoDB uses to allocate performance.

Their key differences include:

• RCU controls read throughput
• WCU controls write throughput

In practice, your workload might be “read heavy” (dashboards, feed views, session lookups) or “write heavy” (event ingestion, telemetry, IoT). DynamoDB forces you to size and pay for both dimensions separately.

DynamoDB cost planning can become even more complex when you introduce secondary indexes, since those can have their own read and write capacity requirements depending on your configuration.

DynamoDB Item Size and RCU

DynamoDB RCU costs are impacted by the size of your items. DynamoDB charges based on the size of the items you read and write, rounded up to the nearest block size (for reads, this is 4 KB; for writes, this is 1 KB). If your items are larger than this block size, you will need to consume additional RCUs to read the items.

DynamoDB will always round up the item size to the nearest block size when calculating the cost of reads and writes. This can significantly affect your costs, especially if you are working with large or varying sized items.

Read consistency also changes how RCUs are accounted for. A single RCU allows for a single consistent read of up to 4KB, while an eventually-consistent read consumes half of that capacity – namely, a single RCU provides 8KB or 2 eventually-consistent reads under 4KB.

For example:

If you read an item that is 300B in size, you will need to consume 1 RCU for a strongly consistent read, or 0.5 RCUs for an eventually consistent read. If you read an item that is 5000B in size, you will need to consume 2 RCUs for a strongly consistent read, or 1 RCU for an eventually consistent read. This is because the item size is rounded up to the nearest block size of 4 KB (i.e., 5,000 bytes / 4,096 bytes = 1.22, which is rounded up to 2 Read Capacity Units).

How ScyllaDB Addresses DynamoDB RCU Limitations 

DynamoDB’s Read Capacity Unit model requires teams to provision capacity in advance and manage throttling when limits are exceeded. ScyllaDB takes a fundamentally different approach.

• No throttling from capacity limits: In DynamoDB provisioned mode, exceeding allocated RCUs triggers ProvisionedThroughputExceededException errors. ScyllaDB charges based on cores and storage rather than request units. With ScyllaDB, there is no provisioned capacity to exhaust and no throttling from exceeding RCU limits.
• No separate read and write capacity: DynamoDB writes cost five times more than reads, requiring teams to separately provision and pay for RCUs and WCUs. With ScyllaDB’s resource-based pricing, read-heavy and write-heavy workloads cost the same; it’s all about cluster size.
• Simplified cost planning: DynamoDB forces users to overprovision capacity to avoid throttling, paying for peak capacity even during low-traffic periods. ScyllaDB guarantees 50% cost savings on equivalent DynamoDB workloads. ScyllaDB pricing is based on the cluster resources you deploy rather than the number of read operations consumed.