Your DynamoDB Queries Are Code. Treat Them Like It.
Version control your queries. Share with your team. Review changes. No cloud lock-in. Just files on disk that work with your existing developer workflow.
No credit card required • Works with your existing Git workflow
"Just Check Slack for That Query"
You know the drill. Someone on your team wrote the perfect DynamoDB query last month. Where is it now? Buried in Slack? In someone's scratch file? Copy-pasted into five different scripts with slight variations?
# Slack Message
@channel Does anyone have that query for getting user sessions from last month?
# random-scripts/debug.js
// TODO: Clean this up
const query = dynamodb.query({
TableName: 'users-table-prod', // or was it user-table?
KeyConditionExpression: 'pk = :pk',
ExpressionAttributeValues: {
':pk': 'USER#' + userId // Hope this is right
}
});
# Sarah's scratch.txt
dynamodb query --table users --key '{"pk": {"S": "USER#123"}}' --projection "id,name,email"
# ^^ This one works for prod, use different table for stagingHere's what happens without proper query management:
The Real Cost
Let's be honest. We've all been there at 2 AM, trying to debug a production issue, desperately searching Slack for that one query that would help. Or worse, rewriting it from scratch because it's faster than finding the original.
12 min
Average time to find a query
47%
Queries with outdated docs
Queries as First-Class Citizens
Dynomate stores everything as local files in your project. No proprietary formats. No cloud databases. Just JSON files that you can commit to Git, review in pull requests, track changes over time, and share across your team.
How It Actually Works
your-project/ ├── src/ ├── tests/ ├── .dynomate/ │ ├── collections/ │ │ ├── user-queries/ │ │ │ ├── get-user-profile.json │ │ │ ├── update-user-settings.json │ │ │ └── user-activity-report.json │ │ ├── order-queries/ │ │ │ ├── get-recent-orders.json │ │ │ ├── order-by-status.json │ │ │ └── order-fulfillment-chain.json │ │ └── analytics/ │ │ ├── daily-active-users.json │ │ ├── revenue-by-product.json │ │ └── customer-lifetime-value.json │ └── environments/ │ ├── development.json │ ├── staging.json │ └── production.json └── package.json
Your queries live alongside your code, in a .dynomate folder that works just like .vscode or .idea.
Every query change is tracked in Git. Every modification has an author. Every decision has context.
See It In Action
1. Create Query
Build your query in Dynomate's visual editor
2. Save & Commit
Query saved as JSON, ready for version control
3. Team Syncs
Everyone gets the query on their next git pull
Features That Make Sense
Git-Friendly Query Storage
Every query is a readable JSON file. No binary formats. No merge conflicts you can't resolve.
- Human-readable format with comments
- Diff-friendly structure for code reviews
- IntelliSense and validation in your IDE
{
"name": "get-user-activity",
"description": "Fetches user activity logs for the past 30 days",
"operations": [
{
"type": "query",
"table": "{{activityTable}}",
"params": {
"KeyConditionExpression": "pk = :pk AND sk BETWEEN :start AND :end",
"ExpressionAttributeValues": {
":pk": "USER#{{userId}}",
":start": "ACTIVITY#{{startDate}}",
":end": "ACTIVITY#{{endDate}}"
},
"ProjectionExpression": "timestamp, action, metadata",
"ScanIndexForward": false,
"Limit": {{limit}}
}
}
],
"variables": {
"userId": "",
"startDate": "",
"endDate": "",
"limit": 100
},
"tags": ["user-analytics", "reporting"]
}// .dynomate/environments/production.json
{
"name": "production",
"profile": "prod-aws-profile",
"region": "us-east-1",
"variables": {
"userTable": "prod-users-table",
"orderTable": "prod-orders-table",
"activityTable": "prod-activity-logs",
"analyticsTable": "prod-analytics-events"
},
"defaults": {
"timeout": 30000,
"retryAttempts": 3
}
}
// .dynomate/environments/development.json
{
"name": "development",
"profile": "dev-local",
"endpoint": "http://localhost:8000",
"variables": {
"userTable": "dev-users-table",
"orderTable": "dev-orders-table",
"activityTable": "dev-activity-logs",
"analyticsTable": "dev-analytics-events"
}
}Environment-Aware Execution
Different tables for dev, staging, and prod? Different AWS accounts? No problem. Environments are just configuration files.
The same query works everywhere. Variables handle the differences.
Query Collections That Tell a Story
User Management
- • get-user-profile.json
- • update-preferences.json
- • user-activity-log.json
- • delete-user-data.json
Order Processing
- • create-order.json
- • order-status-update.json
- • fulfillment-check.json
- • refund-process.json
Analytics Queries
- • daily-active-users.json
- • revenue-by-product.json
- • customer-lifetime-value.json
- • churn-analysis.json
Organize queries by feature, by team, or by access pattern. Your choice. Collections are just folders that make sense to your team.
Real Team Workflows
Onboarding New Developers
Before:
"Ask Sarah for the DynamoDB queries. She'll send you a zip file."
After:
All queries are in the repo. Clone and go.
# Day 1: New Developer Onboarding
$ git clone https://github.com/yourcompany/your-app.git
$ cd your-app
$ npm install
# Open Dynomate
# All queries are already there! 🎉
# The new developer can immediately:
- Browse all existing queries in .dynomate/collections/
- See query documentation and examples
- Understand your data access patterns
- Run queries against dev environment
- Start contributing without asking "where's that query?"New team members can explore and understand your data access patterns from day one.
Code Review for Database Operations
Database queries get the same review rigor as your application code.
diff --git a/.dynomate/collections/user-queries/get-user-activity.json b/.dynomate/collections/user-queries/get-user-activity.json
index a1b2c3d..e4f5g6h 100644
--- a/.dynomate/collections/user-queries/get-user-activity.json
+++ b/.dynomate/collections/user-queries/get-user-activity.json
@@ -8,7 +8,10 @@
"KeyConditionExpression": "pk = :pk AND sk BETWEEN :start AND :end",
"ExpressionAttributeValues": {
":pk": "USER#{{userId}}",
- ":start": "ACTIVITY#{{startDate}}",
+ ":start": "ACTIVITY#{{startDate}}T00:00:00Z",
- ":end": "ACTIVITY#{{endDate}}"
+ ":end": "ACTIVITY#{{endDate}}T23:59:59Z"
},
+ "FilterExpression": "activityType IN (:type1, :type2, :type3)",
+ "ExpressionAttributeValues": {
+ ":type1": "LOGIN",
+ ":type2": "PURCHASE",
+ ":type3": "SUPPORT_TICKET"
+ },
"ProjectionExpression": "timestamp, action, metadata",
- "Limit": {{limit}}
+ "Limit": 25
}
}
]
// PR Comment: "Good catch on the timestamp precision. The filter will help reduce client-side processing.
// Consider making activity types configurable via variables too." - @teammateDebugging Production Issues
When something goes wrong, your queries are right there in your repo history:
$ git log --oneline .dynomate/collections/user-queries/
7f3a2b1 fix: Add timezone handling to activity queries
a91c4d2 perf: Add projection to reduce response size
3e5f7a8 feat: Add user activity report query
d4c9e1f refactor: Standardize query naming convention
9b2a3c7 fix: Handle pagination for large result sets
$ git blame .dynomate/collections/user-queries/get-user-activity.json
7f3a2b1 (Sarah Chen 2024-01-15) "KeyConditionExpression": "pk = :pk AND sk BETWEEN :start AND :end",
a91c4d2 (Mike Ross 2024-01-12) "ProjectionExpression": "timestamp, action, metadata",
3e5f7a8 (Sarah Chen 2024-01-10) "ScanIndexForward": false,See exactly when queries changed, who changed them, and why.
What Your Team Gets
For Developers
- • Find queries instantly
- • Understand data patterns
- • Share solutions, not problems
- • Debug with confidence
For Team Leads
- • Standardized query patterns
- • Knowledge preservation
- • Faster onboarding
- • Audit trail for changes
For Everyone
- • Less "Can you send me that query?"
- • More "It's in the repo"
- • Better sleep during on-call
- • Faster incident resolution
The Numbers Don't Lie
| Metric | Before Dynomate | With Dynomate | Improvement |
|---|---|---|---|
| Finding the right query | 12 min | 30 sec | 24x faster |
| Onboarding new developer | 2 days | 2 hours | 8x faster |
| Debugging query issues | 45 min | 5 min | 9x faster |
| Sharing query updates | Ad-hoc | Automatic | ∞ better |
| Query documentation | Scattered | Centralized | 100% coverage |
For a team of 10 engineers:
Save 156 hours per month
That's $23,400 in recovered productivity
Calculate your team's savingsTeams That Made the Switch
The Fast-Growing Startup
"We went from 5 to 25 engineers in 6 months. Without Dynomate's query versioning, we'd still be doing 'knowledge transfer sessions' every week. Now new hires are productive on day one - they just pull the repo and all our DynamoDB patterns are there, documented and runnable."
— Sarah Chen, CTO at TechStartup
Key Win: Reduced onboarding time from 2 weeks to 2 days
The Enterprise Team
"Compliance asked for an audit trail of all database access patterns. Before Dynomate? Nightmare. Now? I just point them to our Git history. Every query change is tracked, reviewed, and documented. Passed our SOC2 audit with flying colors."
— Michael Rodriguez, Lead Engineer at FinanceCorp
Key Win: Complete audit trail for compliance requirements
The Distributed Team
"We have engineers in 12 time zones. The 'ping someone for that query' approach wasn't working. Now everything's in Git. Need a query at 3 AM in Singapore? It's there. Updated by someone in New York? You'll see it next pull. Async collaboration at its finest."
— Priya Patel, Engineering Manager at GlobalTech
Key Win: Eliminated timezone dependencies for query sharing
Frequently Asked Questions
How do we handle sensitive query parameters?
Use environment variables. Keep sensitive data in your AWS credentials or environment files (which are gitignored). Queries reference variables, not values. Your secrets stay secret.
Do queries sync to the cloud?
No. Your queries stay in your Git repo. We don't store them, sync them, or see them. They're your files on your infrastructure. Dynomate just helps you create and run them.
How do we migrate existing queries?
Start small. Pick your most-used queries and save them in Dynomate. Commit to Git. Let the team see the benefits. The rest will follow naturally. No big-bang migration needed.
Stop Treating Queries as Second-Class Citizens
Your DynamoDB queries power your application. They deserve the same version control, code review, and team collaboration as the rest of your code.
Getting Started Is Simple
Install Dynomate
Download and connect to your AWS profiles
Create Collections
Organize queries that make sense for your team
Commit to Git
Add .dynomate/ to your repository
Share with Team
They pull the repo and have all queries
Your queries are as important as your code. Start treating them that way.
— The Dynomate Team