AWS
Microsoft Azure
Google Cloud
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
Single-table design stores all entity types in one DynamoDB table under generic partition and sort keys (PK, SK), co-locating related items so a single query can fetch them together. It produces measurable savings in exactly two areas: reduced read operations and shared provisioned capacity.
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” can return the user and requested orders together when the chosen sort-key range includes both entity types. Restricting sort keys to the “ORDER#” prefix would exclude a separately keyed user record. The 11 KB example assumes the user and ten requested orders are all included; read consumption uses the data read.
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?
Assumptions:
- 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 1 KB GetItem plus one 10 KB 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
- For this illustrative model, billable table-plus-index storage is assumed to be 27 GB for single-table versus 25 GB for multi-table at $0.25/GB-month. Replace these assumptions with measured sizes.
| Cost Dimension | Single-Table | Multi-Table (3 tables) | Difference | Winner |
|---|---|---|---|---|
| Read operations | 75M RRU ($9.38) | 100M RRU ($12.50) | −$3.13 | 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 | $41.13 | $31.25 | +$9.88 | Multi-Table |
This example assumes the regional 25 GB DynamoDB Standard free storage allowance is already used by other tables. With the full allowance available, modeled storage is $0.50 for 27 GB versus $0 for 25 GB; monthly totals become $34.88 versus $25.00, preserving the $9.88 difference (rounded).
GSI write propagation is the only line item large enough to decide the outcome — it flips the total on its own.
In this illustrative workload, single-table saves $3.125 in reads but adds $12.50 in GSI writes and $0.50 in storage, for a net $9.875/month higher cost (displayed as $9.88). This is a scenario, not a general savings range. At larger scale, recalculate requests, item sizes, index fan-out and storage rather than multiplying every charge by one factor.
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?
Refactoring an existing multi-table deployment takes engineering time and carries migration risk. Compare measured request and index savings with that cost. In the illustrative overloaded-index scenario above, single-table is $9.88/month more expensive; another workload may produce a different result.
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 |
| Illustrative monthly result | Recalculate with actual reads, item sizes and index writes | $9.88/month cheaper in the overloaded-index example above |
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?
Once your table design is set, ongoing DynamoDB cost optimization shifts to the capacity layer: choosing between on-demand and provisioned capacity, right-sizing throughput, and identifying stable usage patterns.
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 conditional protection for eligible losses under the applicable agreement.
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.
Eligible Flex cashback is calculated when commitment cost exceeds equivalent On-Demand cost for the same usage, subject to eligibility and the agreement. Published documentation describes payout 90 days after accrual. It does not cancel the provider commitment or refund every unused dollar.
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 contains all entity types. Billable GetRecords readers pay $0.02 per 100,000 stream read request units after the applicable free allowance. AWS Lambda event-source reads are exempt except Lambda Managed Instances, so a Lambda consumer does not automatically incur that Streams read charge. Multi-table design can reduce filtering work for consumers that need only one entity type.
