.png)
The short answer
The outcome depends on access patterns, item and index-entry sizes, index projections, write behavior, traffic shape, table class, and applicable AWS discounts. Use the worked scenario below as an illustration, then price the design with your own production metrics before refactoring.
DynamoDB Single-Table Design Cost: Where It Saves
A potential DynamoDB single-table design cost advantage comes from logical item co-location under a shared partition-key value. A Query on PK = “USER#123” with SK begins_with = “ORDER#” can return the user record and matching orders in one response, with read consumption based on the total size of the returned items.
Without a single-table design, fetching the same data requires at least 2 API calls, one GetItem for the user, one Query on a separate orders table and each call has its own read cost.
On provisioned tables, separate tables can require separate autoscaling settings and minimum-capacity choices, so compare their configured capacity and utilization rather than assuming consolidation creates a fixed saving. On-demand pricing does not charge a per-table capacity minimum.
Also read: DynamoDB Reserved Capacity: Pricing for Read & Write Throughput
Where Does Single-Table Design Increase Costs?
Denormalization Inflates Item Size and Cost
Write consumption rounds each base-table item and affected index entry up to 1 KB, so an item already close to that boundary can require an additional write request unit after its stored size increases.
Scans Cost More on a Single Table
A separate Orders table can therefore reduce scanned data by about 80% in this example, but a Query or an appropriate secondary index is generally preferable to either full-table Scan.
Also read: DynamoDB Contributor Insights Pricing
What Is the Net Cost Impact?
- 50 million composite user-and-orders fetches per month, eventually consistent; each fetch returns 11 KB
- The single-table model uses one Query per fetch, while the multi-table model uses one GetItem plus one Query per fetch
- 10 million writes per month, all base items and affected index entries are 1 KB or smaller
- Three GSIs receive every single-table write while one entity-specific GSI receives every multi-table write
- Prices use DynamoDB Standard on-demand rates in US East (N. Virginia), with AWS Free Tier benefits excluded
- Storage is excluded from the request-cost comparison because index-entry sizes and projections are not specified
| Cost Dimension | Single-Table | Multi-Table (3 tables) | Difference | Winner |
|---|---|---|---|---|
| Read operations | 35M RRU ($4.38) | 50M RRU ($6.25) | −$1.87 | Single-Table |
| Write operations (base) | 10M WRU ($6.25) | 10M WRU ($6.25) | $0.00 | Tie |
| GSI write propagation | 30M WRU ($18.75) | 10M WRU ($6.25) | +$12.50 | Multi-Table |
| Storage | 27 GB ($6.75) | 25 GB ($6.25) | +$0.50 | Multi-Table |
| Total monthly cost | $36.13 | $25.00 | +$11.13 | Multi-Table |
GSI write propagation is the only line item large enough to decide the outcome — it flips the total on its own.
Which Cost Levers Actually Move the Bill?
Table design is a second-order lever. Ranked by dollar impact:
Capacity Mode Selection: On-Demand vs. Provisioned. On-demand bills the request units your application consumes, while provisioned mode bills the read and write capacity you configure per hour. For steady, predictable workloads, compare both modes using actual utilization, autoscaling settings, and expected demand variation.
Reserved Capacity (~54–77% off provisioned). After choosing provisioned mode, reserved capacity cuts the rate by roughly 54% (1-year) to 77% (3-year). See our DynamoDB Reserved Capacity pricing guide for the full break-even math.
Database Savings Plans (12–18% in either mode). Launched December 2025, these cover DynamoDB on-demand (up to 18%) and provisioned (up to 12%) under one hourly commitment the only discount lever for teams that can't leave on-demand.
See our Database Savings Plans guide for the comparison against reserved capacity.
Item Size Optimization (1–3x multiplier). Reads bills in 4 KB blocks, writes in 1 KB blocks, trimming attribute names, dropping unused attributes, and compressing large fields can pull items under the next billing threshold.
Eventually Consistent Reads (50% read reduction). 0.5 RRU per 4 KB versus 1.0 for strongly consistent, an immediate halving if your application tolerates it.
Should You Refactor to Single-Table?
how many do you actually fetch together in one API call?
pull this from CloudWatch, don't estimate
sparse or overloaded across entity types?
do entities scale together or independently?
| Signal | Single-Table | Multi-Table |
|---|---|---|
| Entity types fetched together per API call | 3 or more | 1 or 2 |
| Read-to-write ratio | Above 10:1 | Below 5:1 |
| GSI strategy | Sparse (entity-specific key attributes) | Entity-specific GSIs, 1 per table |
| Team DynamoDB experience | High (comfortable with overloaded keys) | Low to medium |
| Independent entity scaling | No (entities grow together) | Yes (one entity 10x, others flat) |
| Per-entity config needed (PITR, encryption, table class) | No | Yes |
| Building new vs. refactoring existing | New build | Existing multi-table |
| Expected monthly cost vs. multi-table | $3–5/month cheaper with sparse GSIs | $10–15/month cheaper if single-table uses overloaded GSIs |
If the split is 4–4, default to multi-table and revisit after access patterns stabilize. In short: refactor only when building new, with stable access patterns, 3+ entity types fetched together, and a heavily read-skewed profile otherwise kept multi-table.
What Comes After Choosing a Table Design?
Usage.ai continuously analyzes AWS usage across your cloud environment to identify commitment opportunities and optimize coverage as workloads evolve.
With Flex Insured Commitments, teams can get up to 54% savings on a 1-year DynamoDB reserved capacity commitment with none of the commitment risk.
We monitor consumed read and write capacity across your DynamoDB environment, identify stable usage baselines, and help manage qualifying commitments where the economics make sense.
If a commitment ever costs more than the equivalent On-Demand usage, our Cashback Protection covers the difference, helping organizations maximize savings while retaining the flexibility to adapt as infrastructure changes.
Our pricing is performance-based, so you pay only a percentage of the savings we deliver.
See how much you can save on DynamoDB with Usage.ai.
Frequently asked questions
Does DynamoDB single-table design save money on on-demand tables?
Minimal to zero savings from consolidation itself on-demand pricing is per request, not per table. The only on-demand savings come from reduced read operations when single-table eliminates multi-call fetch patterns.
How much does a DynamoDB table cost?
There's no fixed monthly fee. You pay for on-demand or provisioned capacity, storage ($0.25/GB-month Standard class), and optional features. An empty, idle on-demand table costs $0.00/month.
Can you mix single-table and multi-table design?
Yes. Many production architectures use single-table for tightly coupled entity groups (a user and their orders) and separate tables for independent types like analytics events capturing read co-location while keeping independent scaling and per-table configuration.
How does single-table design affect DynamoDB Streams cost?
A single table's stream captures changes to all entity types, so a consumer needing one type still pays to read the full stream ($0.02 per 100,000 reads) and filter the rest. Multi-table design produces entity-specific streams.
