Read and write to DynamoDB
from your local workflows
Run your state machines and Lambda functions locally while reading and writing your real DynamoDB tables — no deployment, no stack updates, no mocking required.
Your real data. Your real tables. Zero deploys to iterate.
You shouldn't need to deploy your stack just to test a DynamoDB write
Before Thrubit, validating a workflow that touched DynamoDB meant a full deploy cycle — SAM build, CloudFormation update, execution role sync — just to check that your PutItem payload was structured correctly.
Deploy. Wait. Check CloudWatch. Repeat.
Every change to a DynamoDB-integrated workflow required a full deploy cycle. Update your ASL, run SAM build, wait for CloudFormation, re-trigger the execution, then dig through CloudWatch to find out your key schema was wrong.
Run locally. Hit real DynamoDB. Iterate instantly.
Open your state machine in Thrubit and run it. Your workflow executes locally while DynamoDB calls go directly to your real tables using your configured AWS profile — with full input, output, and error visibility in the execution panel.
Your local execution reaches real DynamoDB — automatically
When you run a state machine or invoke a Lambda in Thrubit, DynamoDB calls are passed through to real AWS using the profile and region configured in your settings. No changes to your workflow definition, no endpoint overrides, no code modifications needed.
- Works for both Step Functions native DynamoDB integrations (
arn:aws:states:::dynamodb:putItem,getItem, etc.) and direct SDK calls inside Lambda - Uses the same AWS profile and region as the rest of your Thrubit configuration
- IAM permissions on your local profile apply — catch access and key schema issues before they reach production
- Conditional expressions, update expressions, and projection expressions all execute against real DynamoDB — no translation layer
"TableName":
"Orders",
"Key": {
"orderId": {
"S": "ord-8a3c"
}
}
}
"Item": {
"orderId": {
"S": "ord-8a3c"
},
"status": {
"S": "pending"
},
"total": {
"N": "149.99"
}
}
}
Actual DynamoDB responses — not stubs
Because Thrubit passes DynamoDB calls through to real AWS, you get real responses — actual item data, real consumed capacity units, correct error messages for missing keys and failed condition expressions. Your ResultSelector mappings work against real data from day one.
GetItemreturns the real item with DynamoDB's typed attribute format —{"S": "..."},{"N": "..."},{"BOOL": true}— exactly as yourResultSelectorwill see it in productionPutItemreturns realConsumedCapacityand reflects actual conditional expression outcomes — includingConditionalCheckFailedExceptionQueryandScanreturn realItems,Count, andLastEvaluatedKeyfor paginated results from your actual data- Error messages reflect real table and permission state — wrong key schema, throttling, and access denied errors surface before production
DynamoDB in state machines and Lambda — both work locally
DynamoDB appears in two places in Step Functions architectures: as a native service integration in the ASL, and as direct SDK calls inside Lambda functions. Thrubit handles both, routing requests to your real tables in either case.
- ASL-level integrations like
arn:aws:states:::dynamodb:getItemanddynamodb:putItemare handled natively by the Thrubit execution engine - Lambda-side
AWS.DynamoDB.DocumentClientandDynamoDBClientcalls reach your real tables through your configured AWS profile - Both
DynamoDB(typed) andDocumentClient(simplified) APIs work — marshalling and unmarshalling behaves identically to the real SDK - Streams, GSI queries, transactional writes, and batch operations all pass through to real DynamoDB without modification
ASL Native Integrations
dynamodb:getItemdynamodb:putItemdynamodb:updateItemdynamodb:deleteItemdynamodb:querydynamodb:scan
Direct SDK Calls
DynamoDB.getItem()DynamoDB.putItem()DynamoDB.updateItem()DynamoDB.query()DocumentClient.get()DocumentClient.put()
The DynamoDB operations your workflows actually use
Thrubit supports the full range of DynamoDB operations used in production Step Functions architectures — from single-item reads and writes to batch operations, transactions, and GSI queries.
ProjectionExpression, ConsistentRead, and ExpressionAttributeNames — exactly as your ResultSelector will parse it.attribute_not_exists, attribute_exists, and comparison conditions raise real ConditionalCheckFailedException on failure.SET, REMOVE, ADD, DELETE — against your actual table data. Atomic counter increments and list appends work as expected in production.Items, Count, and LastEvaluatedKey — essential for Map state fan-outs and paginated result processing.ExclusiveStartKey pagination, and Limit — useful for bulk processing workflows with Map states.UnprocessedItems and transaction conflict errors surface correctly for robust error handling.Access real DynamoDB from your first local run
No additional setup required beyond a configured AWS profile. Your local executions read and write real DynamoDB tables automatically.
In Thrubit's Settings, select the AWS profile and region you use for development. Any IAM permissions your local profile has are available to your local executions — including DynamoDB read and write access to your tables.
Load your state machine from your local SAM template.yaml. Thrubit reads your ASL definition and resolves Lambda functions locally — including those that call DynamoDB using DocumentClient or DynamoDBClient inside their handlers.
Start an execution with your input. DynamoDB task states execute against real AWS using your configured profile. Each state's inputs, outputs, and raw DynamoDB response attributes are visible in the real-time execution panel — no CloudWatch digging required.
Update your ASL definition, Lambda handler, or expression attributes and run again immediately — no SAM build, no CloudFormation update, no role sync. Changes take effect on the next run.
Stop deploying just to test your DynamoDB integration.
Download Thrubit and run your first DynamoDB-integrated state machine locally in under five minutes — real reads and writes, full response visibility, zero deployment required.
What teams are saying
Real feedback from engineers, trainers and decision makers.
“Thrubit cut our Step Functions debugging cycle from 15 minutes per iteration down to seconds. The visual trace is worth the price alone. It’s become an essential part of our development workflow.”
“I was looking for ways to make Step Functions and Lambdas more tangible for students. Thrubit makes it significantly easier to visualize workflows and experiment locally, accelerating real understanding.”
“Thrubit saves us over $24k a year & protects us from surprise AWS bills. One rogue state machine once cost us 10x our typical month. With Thrubit, that risk is gone and our developers iterate faster.”
