DynamoDB Capacity
DynamoSQL queries DynamoDB in your own AWS account using the IAM role you configure. DynamoDB RCU consumption is charged directly to your AWS account — DynamoSQL does not meter or bill for DynamoDB read capacity.
Scan-heavy queries — those where the optimizer cannot match a suitable index — consume significantly more RCUs than index-backed queries. Use plan mode to verify which execution strategy the optimizer selected before running expensive queries against production tables.
If the plan tree shows Scan(...) for a query you expect to use an index, check that your GSI metadata is registered in the portal so the optimizer can see it.
API Call Volume
DynamoSQL meters the number of API calls per tenant. Current limits and your rolling usage are visible in the portal under Settings > Usage.
For programmatic access to usage data, use the /v1/usage/summary endpoint.
If you exceed your API call limit, the API returns a 429 response. Retry with exponential backoff. If you consistently hit the limit, contact support to discuss a higher quota.
Row Limits
There are no artificial row limits beyond the maxRows pagination parameter, which defaults to 100 rows per request. You can increase it per-request or page through the full result set using resumeIdx. See Pagination for details.
Reducing Costs
| Practice | Effect |
|---|
| Use plan mode during development | Zero RCU cost for SQL validation |
| Add GSIs for common WHERE predicates | Converts scans to index queries |
Use LIMIT to cap row counts | Reduces RCUs for exploratory queries |
| Prefer key-based lookups over scans | DynamoDB key reads are the cheapest operation |
| Filter at the SQL layer, not in application code | Fewer rows fetched from DynamoDB |
