DEV Community: Sidharth Bangera

Simulating DynamoDB Costs in Tables: GSIs, Backups, Streams, and Replicas

Sidharth Bangera — Sat, 10 Oct 2026 11:06:28 +0000

Introduction

When I evaluate a DynamoDB design change, I want to understand how it affects cost before I change the AWS resources themselves.

In this walkthrough, I use Tables by ServerlessCreed, a DynamoDB GUI with cost analysis and simulation tools, to compare a baseline workload with several what-if changes: two global secondary indexes (GSIs), point-in-time recovery (PITR), backup storage, DynamoDB Streams reads, and two replica Regions.

The test uses a fixed synthetic workload so that each cost driver can be added separately and compared with the previous state. The dollar values shown here are simulator estimates, not actual AWS charges.

Prerequisites

To reproduce the workflow, you need:

1. Tables by ServerlessCreed installed. The installer is available from the official download page.
Access to a non-production DynamoDB environment.
A table available in Tables for cost analysis.
A known Region and a consistent simulation period.

For this test, I used:

Tables version: v3.3.37
Table: Export_Source_Test
Primary Region: us-east-1
Simulation period: 7 days
Table items: 100
Execution: local what-if simulation

The simulation changed only estimator inputs; it did not modify those AWS resources.

1. Starting from the observed cost baseline

I first opened Cost Estimation using the table’s observed metrics.

Reads, writes, and table storage were available, but Streams reads and backup/PITR inputs were incomplete. Tables marked those components as incomplete instead of silently treating them as zero.

For the 7-day observed view, the current and forecast cost remained below $0.01. I used this only as the observed starting point; the detailed comparisons below use a fixed synthetic baseline.

Observed cost baseline for Export_Source_Test. The 7-day Cost Optimizer view shows current and forecast spend below $0.01, write amplification of 1.0×, and no material savings identified before any simulation inputs were added.

2. Loading a fixed synthetic baseline

To make the comparison repeatable, I loaded the built-in synthetic baseline.

Input	Value
Table storage	10 GB
Table read units	6,048,000 over 7 days
Table write units	3,024,000 over 7 days
Peak reads	20/second
Peak writes	10/second
Stream GetRecords calls	0
Backup storage	0 GB
PITR	Off
Simulated GSIs	None
Replica Regions	None

With those inputs, Tables produced these monthly estimates:

Billing model	Estimated monthly cost
On-Demand	$13.84
Provisioned	$10.47
Reserved 1 year	$6.16
Reserved 3 year	$4.33

For the comparisons below, I used On-Demand consistently so that each change was measured against the same billing model.

Synthetic baseline inputs. I loaded a fixed 7-day workload with 10 GB of storage, 6,048,000 read units, 3,024,000 write units, no Streams activity, no backup storage, PITR disabled, and no simulated GSIs or replicas.

3. Comparing two simulated GSIs

I next added two simulated GSIs with the same write volume but very different read activity.

For SimulatedGSI1, I used:

Read units: 500,000 over 7 days
Write units: 3,024,000 over 7 days

The On-Demand estimate increased from $13.84 to $22.21/month, an increment of:

+$8.37/month

The breakdown showed approximately $0.27/month for GSI reads and $8.10/month for GSI writes.

For SimulatedGSI2, I used:

Read units: 5,000 over 7 days
Write units: 3,024,000 over 7 days

With both GSIs present, the estimate reached $30.31/month. The second GSI added approximately:

+$8.10/month

GSI simulation inputs. SimulatedGSI1 uses 500,000 read units and SimulatedGSI2 uses 5,000 read units over the 7-day period, while both use 3,024,000 write units.

GSI cost result. With both simulated indexes added, the On-Demand estimate reaches $30.31/month. The similar write volume keeps the maintenance cost of the two GSIs close despite the large difference in read usage.

This produced the clearest ROI comparison in the test.

SimulatedGSI2 served 100 times fewer simulated reads than SimulatedGSI1, but it carried the same write volume and almost the same incremental cost. For this workload, that makes the second GSI the weaker-ROI candidate.

That does not mean a low-read production index should automatically be removed. It may still support an infrequent but important access pattern. The comparison instead gives a concrete reason to review whether its usage justifies the ongoing cost.

4. Adding PITR, backup storage, and Streams reads

I then added three more cost drivers one at a time.

Change	Estimate before	Estimate after	Increment
Enable PITR	$30.31	$32.31	+$2.00/month
Add 20 GB backup storage	$32.31	$34.31	+$2.00/month
Add 1,000,000 Stream GetRecords calls over 7 days	$34.31	$35.17	+$0.86/month

PITR enabled in the simulation. Point-in-time recovery was enabled while the existing GSI assumptions remained unchanged.

PITR cost result. Enabling PITR increased the simulated On-Demand estimate from $30.31 to $32.31/month, an increment of $2.00/month.

I then kept PITR enabled and added 20 GB of backup storage.

Backup storage added. Backup storage was increased to 20 GB while PITR and the existing GSI assumptions remained unchanged.

Backup storage cost result. Adding 20 GB of backup storage increased the simulated On-Demand estimate from $32.31 to $34.31/month, another $2.00/month increase.

Finally, I added 1,000,000 Stream GetRecords calls over the same seven-day period. This increased the simulated On-Demand estimate from $34.31 to $35.17/month, an additional $0.86/month.

Streams read activity added. I set the simulation to 1,000,000 DynamoDB Streams GetRecords calls over the 7-day period while keeping the existing GSIs, PITR, and backup assumptions unchanged.

Streams cost result. Adding 1,000,000 Stream GetRecords calls increased the simulated On-Demand estimate from $34.31 to $35.17/month, an increment of $0.86/month.

AWS documents PITR and on-demand backup charges as storage-based. DynamoDB Streams reads are billed in Streams read request units, with each GetRecords call counting as one unit, subject to the applicable AWS pricing and Free Tier conditions.

The $0.86 value above is the Tables simulator estimate for this seven-day Streams input.

Before adding replicas, the simulated On-Demand total was:

$35.17/month

5. Adding two replica Regions

I then added two replica Regions:

Replica 1: us-east-2
Replica 2: us-west-1

After adding us-east-2, the On-Demand estimate increased from $35.17 to $61.97/month.

Increment: +$26.80/month

The breakdown showed $24.30/month for replicated writes and $2.50/month for replicated storage.

First replica Region added. I added us-east-2 as the first simulated replica while keeping the existing GSIs, PITR, backup storage, and Streams assumptions unchanged.

First replica cost result. Adding us-east-2 increased the simulated On-Demand estimate from $35.17 to $61.97/month, an increment of $26.80/month.

After adding us-west-1, the estimate increased again:

$61.97/month -> $91.79/month

The second replica added:

+$29.82/month

With both replicas present, Tables showed $51.32/month for replicated writes and $5.30/month for replicated storage. The combined replica increase was therefore:

+$56.62/month

Second replica Region added. I then added us-west-1 as a second simulated replica while keeping the rest of the workload unchanged.

Two-replica cost result. Adding us-west-1 increased the simulated On-Demand estimate from $61.97 to $91.79/month. The two replicas added $56.62/month in total compared with the pre-replica state.

The replica increments differ because the selected Regions use different regional pricing.

This behavior is consistent with AWS DynamoDB Global Tables billing, where replicated writes are charged in every Region containing a replica and each replica also carries storage cost.

Tables also showed the one-year and three-year reserved options as Not offered after the Global Table scenario was added. AWS documentation states that reserved capacity cannot be purchased for replicated write capacity units.

Practical takeaways

The synthetic baseline started at $13.84/month On-Demand. After adding two GSIs, PITR, backup storage, Streams reads, and two replica Regions, the final simulated total reached $91.79/month.

The component-level comparison was more useful than the final number alone.

For this workload:

GSI write activity contributed much more to index cost than the difference in read activity.
The lower-read GSI had nearly the same maintenance cost as the higher-read GSI because both used the same simulated write volume.
PITR, backup storage, and Streams reads produced smaller incremental increases.
The two replica Regions were the largest incremental cost driver in the simulation.

These results are specific to the assumptions used in this test. Production traffic, item sizes, table class, Free Tier eligibility, discounts, Region-specific pricing, and the business value of individual access patterns can all change the outcome.

For me, the useful part of this workflow is being able to compare these design choices before changing the infrastructure. The simulation does not replace real usage data or an AWS bill, but it provides a consistent way to test assumptions and identify which cost drivers deserve closer review.

Running, Saving, and Reopening a Parameterized DynamoDB PartiQL SELECT in Tables

Sidharth Bangera — Thu, 08 Oct 2026 18:02:07 +0000

Introduction

When I reuse a database query, I want the query structure to stay consistent while the input value can change.

In this walkthrough, I use Tables by ServerlessCreed, a DynamoDB GUI with a PartiQL Workbench, to run a parameterized DynamoDB PartiQL SELECT, verify the returned items, save the statement, restart the application, reopen the saved query, and verify the result again.

I also include a simple syntax-error recovery check. The test uses a deterministic fixture, so I know the expected result before execution and can verify the workflow against actual data rather than relying only on a success message.

Prerequisites

To reproduce the workflow, you need:

Tables by ServerlessCreed installed. The installer is available from the official download page.
Access to a non-production DynamoDB environment.
A table with predictable test data.
A known expected result that you can compare with the query output.

For this test, I used a table named table_bulk with 120 deterministic items. The fixture was prepared so that 30 items had:

Status = BULK_EDITED

In this table, OrderId is the partition key and Status is the sort key. Because BULK_EDITED appears on multiple items, Status was a useful field for testing a parameterized query that returned more than one record.

1. The query I wanted to reuse

Instead of putting the filter value directly into the SQL, I used a named parameter:

SELECT *
FROM "table_bulk"
WHERE "Status" = {{statusValue}};

The parameter value for this run was:

statusValue = BULK_EDITED

This keeps the query structure reusable while letting the value be supplied separately when the statement is run.

I opened the PartiQL Workbench, selected table_bulk, and entered the statement. Autocomplete suggestions were available again in the v3.3.37 build while I was typing.

After selecting table_bulk, Tables shows the Status attribute in autocomplete while I build the PartiQL SELECT.

2. Supplying the parameter and reviewing the query

When I ran the parameterized statement, Tables opened a Query parameters dialog and detected statusValue.

I entered:

BULK_EDITED

and chose Load for review.

Tables then resolved the parameterized statement to:

SELECT *
FROM "table_bulk"
WHERE "Status" = 'BULK_EDITED';

This review step was useful because I could see the exact statement that would be executed before running it.

After running the parameterized statement, Tables prompts for statusValue; I entered BULK_EDITED and loaded the resolved query for review.

3. Verifying the first result

I then ran the resolved query.

The expected result was 30 matching items because the fixture had been prepared with exactly 30 items whose Status value was BULK_EDITED.

Tables returned 30 items, which matched that expectation.

This was the important verification point for the first run. I was not relying only on a generic success message; I had a known fixture and an expected result before execution.

After running the resolved SELECT, Tables returns the expected 30 items from the deterministic fixture.

4. Saving the statement and reopening it after restart

Next, I saved the parameterized template rather than only the resolved literal query.

The saved statement retained:

SELECT *
FROM "table_bulk"
WHERE "Status" = {{statusValue}};

I then restarted Tables, returned to the PartiQL Workbench, and selected the saved statement from My statements.

The parameterized query itself was still there after restart, but the previous parameter value was not retained. Selecting the saved query opened the Query parameters dialog again, so I entered BULK_EDITED a second time.

That behavior is important: Tables preserved the reusable query template, while the input value had to be supplied again when reopening it.

After loading the value for review and rerunning the query, Tables again returned the expected 30 items.

Check	First run	Reopened run	Expected keys/items	Actual keys/items	Difference
Query template	`{{statusValue}}` present	`{{statusValue}}` present	Same saved statement	Same saved statement reopened	None
Parameter value	Entered `BULK_EDITED`	Re-entered `BULK_EDITED`	Same input value	Same input value	None
Result	30 items	30 items	30 deterministic fixture items matching `Status = BULK_EDITED`	Same 30-item result set observed after restart	None observed

I did not export a separate key manifest for this run, so the comparison was based on the deterministic fixture and the matching 30-item result before and after restart.

After restarting Tables and reopening the saved statement, the parameterized query remains intact and Tables prompts me to enter statusValue again.

5. Recovering from a syntax error

I also tested a simple recovery case by deliberately changing the statement to invalid syntax:

SELECCC *
FROM "table_bulk"
WHERE "Status" = 'BULK_EDITED';

Tables rejected the statement and displayed:

Statement wasn't well formed, can't be processed: Expected data manipulation

The malformed statement remained visible in the editor, so I could correct it directly instead of recreating it from scratch.

After running the deliberately malformed SELECCC statement, Tables reports a syntax error while leaving the statement in the editor for correction.

I corrected the query and ran it again. Tables reported a successful execution and returned 30 items, matching the expected fixture result.

The query history also kept the failed statement and the successful corrected statement as separate entries during this retest.

After correcting the statement, Tables executes the SELECT successfully and returns the expected 30 matching items.

Conclusion

This test confirmed the full workflow I wanted to verify in Tables: creating a parameterized DynamoDB PartiQL query, supplying the parameter value, checking the returned items, saving the query template, reopening it after restart, and running it again with the same expected result.

The saved statement retained the {{statusValue}} placeholder, while the parameter value had to be entered again after reopening. With the same BULK_EDITED input and unchanged fixture, both runs returned the expected 30 items.

The syntax-error check also showed that a malformed statement remained available for correction, and the corrected query returned the expected result afterward.

For this test, the most useful part of the workflow was keeping the query reusable without hard-coding the input value into the saved template, while still verifying the result against a deterministic fixture.