DEV Community: DynoTable

DynamoDB DeleteItem in Go (AWS SDK v2)

DynoTable — Wed, 09 Sep 2026 13:43:48 +0000

client.DeleteItem takes a dynamodb.DeleteItemInput carrying the full primary key. With types.ReturnValueAllOld the response tells you whether anything was actually there; once you add a ConditionExpression, the error tells you why it stayed.

Code

package main

import (
    "context"
    "fmt"
    "log"

    "github.com/aws/aws-sdk-go-v2/aws"
    "github.com/aws/aws-sdk-go-v2/config"
    "github.com/aws/aws-sdk-go-v2/service/dynamodb"
    "github.com/aws/aws-sdk-go-v2/service/dynamodb/types"
)

func main() {
    ctx := context.TODO()
    cfg, err := config.LoadDefaultConfig(ctx, config.WithRegion("us-east-1"))
    if err != nil {
        log.Fatalf("load config: %v", err)
    }
    client := dynamodb.NewFromConfig(cfg)

    out, err := client.DeleteItem(ctx, &dynamodb.DeleteItemInput{
        TableName: aws.String("Music"),
        Key: map[string]types.AttributeValue{
            "Artist":    &types.AttributeValueMemberS{Value: "Arturo Sandoval"},
            "SongTitle": &types.AttributeValueMemberS{Value: "Cubano Chant"},
        },
        ReturnValues: types.ReturnValueAllOld,
    })
    if err != nil {
        log.Fatalf("delete item: %v", err)
    }

    if len(out.Attributes) == 0 {
        fmt.Println("No item with that key existed")
    } else {
        fmt.Println("Deleted:", out.Attributes)
    }
}

Explanation

types.ReturnValueAllOld is a typed constant, not the string "ALL_OLD" — the field takes a types.ReturnValue, so a typo is a compile error instead of a runtime ValidationException. DeleteItem accepts only NONE and ALL_OLD; the rest of the enum is shared with UpdateItem.
len(out.Attributes) == 0 is the only signal you get — deleting a key that was never there succeeds, and the SDK hands back a nil map rather than an error. Nothing else separates "deleted it" from "there was nothing to delete".
Match the guard failure with errors.As — var ccfe *types.ConditionalCheckFailedException then errors.As(err, &ccfe). A direct comparison misses it, because Go v2 wraps service faults in a Smithy operation error.
The exception can carry the losing item — set ReturnValuesOnConditionCheckFailure: types.ReturnValuesOnConditionCheckFailureAllOld and ccfe.Item holds the row as DynamoDB saw it, so you can log the value that actually failed the guard instead of re-reading it. The SDK documents the price: "No read capacity units are consumed."
One item per call — there is no delete-all API. Deleting many items means collecting the keys first and batching the writes, or dropping the table.

Cost note

DeleteItem consumes 1 WCU per ≤1 KB of the deleted item (rounded up). Confirm item size with the item size calculator before you batch-delete in a loop — a 3 KB item is still 3 WCUs each. On-demand prices those units in us-east-1 the same way as provisioned metering; check the pricing calculator if you are sizing a cleanup job.

Do it visually

The guard is the fiddly half: a ConditionExpression plus the name and value maps that go with it. The DynamoDB Expression Builder assembles all three from a form.

DynoTable attacks the same risk from the other end. A delete lands in a Pending changes panel first and only reaches the table when you commit it, so a wrong row is something you discard rather than something you restore. Download DynoTable.

Related examples

DynamoDB DeleteItem in Java — the same delete with AWS SDK for Java 2.x.
DynamoDB PutItem in Go — the write side of the same key.
DynamoDB condition expressions — guard deletes with attribute_exists and value checks.
DynamoDB ConditionalCheckFailedException — what a failed conditional delete throws, and when it's expected.

References

Last verified 2026-07-28 against the official AWS documentation linked above.

DynamoDB Conditional Write in Python (boto3)

DynoTable — Tue, 08 Sep 2026 13:37:40 +0000

boto3 is the one SDK where a conditional write has a named exception class to catch, and it is also the one where the returned item hides somewhere you would not guess. The expression itself works the same everywhere; DynamoDB condition expressions covers the functions and the optimistic-locking pattern.

Code

import boto3

client = boto3.client("dynamodb")

# Update the item only if nobody changed it since we read version 7.
try:
    client.update_item(
        TableName="Music",
        Key={"Artist": {"S": "Arturo Sandoval"}, "SongTitle": {"S": "Cubano Chant"}},
        UpdateExpression="SET #upd0 = :updValue0, #version = :newVersion",
        ConditionExpression="attribute_exists(#cond0) AND #version = :expectedVersion",
        ExpressionAttributeNames={"#upd0": "Genre", "#version": "Version", "#cond0": "Artist"},
        ExpressionAttributeValues={
            ":updValue0": {"S": "Latin Jazz"},
            ":expectedVersion": {"N": "7"},
            ":newVersion": {"N": "8"},
        },
        ReturnValuesOnConditionCheckFailure="ALL_OLD",
    )
    print("Updated to version 8")
except client.exceptions.ConditionalCheckFailedException as e:
    # With ReturnValuesOnConditionCheckFailure="ALL_OLD", the current item
    # rides back on the exception — no extra read to see what beat you.
    print("Lost the race — item is now:", e.response.get("Item"))

Explanation

ConditionalCheckFailedException is a modeled class, so except client.exceptions.… works. Most DynamoDB errors are not: ValidationException has no class at all and has to be matched on e.response["Error"]["Code"]. The modeled class still subclasses ClientError, so a broad except ClientError upstream will swallow it if you order your handlers carelessly.
The returned item is a top-level key of e.response, not of e.response["Error"]. That is why the fence reads e.response.get("Item"). It is easy to go looking under ["Error"] alongside Code and Message, find nothing, and conclude the parameter did not work.
The item comes back in DynamoDB JSON even though you may be used to native values, because this is the low-level client. boto3.dynamodb.types.TypeDeserializer converts it if you want plain Python.
The resource API expresses the same guard as objects, ConditionExpression=Attr("Version").eq(7) & Attr("Artist").exists(), with native values and no placeholder maps. It raises the identical exception, so the handling below is unchanged.
A failed check still bills a write. The Developer Guide is explicit that a false condition consumes write capacity, sized on the larger of the old and new item, so an unbounded retry on a contended key costs real money while making no progress.

Where boto3 puts the returned item

Run the fence against a stored Version of 9 and print the exception's response keys. DynamoDB Local 3.3.0, boto3 1.43.58:

sorted(e.response.keys())  ->  ['Error', 'Item', 'ResponseMetadata']

e.response["Item"]  ->  {'Artist': {'S': 'Arturo Sandoval'},
                         'Year': {'N': '1994'},
                         'Version': {'N': '9'},
                         'SongTitle': {'S': 'Cubano Chant'},
                         'AlbumTitle': {'S': 'Danzon'}}

Drop ReturnValuesOnConditionCheckFailure and the same failure gives ['Error', 'ResponseMetadata']. The Item key is absent, and e.response.get("Item") returns None rather than raising. That is the version of this bug that survives code review and starts logging None in production.

Why every name in the expression is aliased

The fence writes #version and #cond0 instead of Version and Artist, which looks like overkill for two ordinary words. It is, for these two. Version is not a DynamoDB reserved word, and used bare it passes name validation.

Year is reserved, and the same table has one. Guard on it directly and you get:

ValidationException: Invalid ConditionExpression: Attribute name is a reserved keyword;
reserved keyword: Year

573 words are on that list, including Name, Status, Size, Count, Data, Owner, Timestamp and Items. Aliasing everything is how generated code avoids ever having to know which is which. Paste your attribute names into the reserved words checker and it returns the ExpressionAttributeNames map for the ones that need it.

To write these guards against your own tables with the aliasing handled for you, download DynoTable.

Related examples

DynamoDB conditional write in Node.js — the same optimistic lock with AWS SDK v3.
DynamoDB conditional write with the AWS CLI — the same optimistic lock from the shell.
DynamoDB PutItem in Python — the create-only attribute_not_exists put.
DynamoDB condition expressions — every function, with patterns.
Enforcing uniqueness on multiple attributes — conditions + transactions combined.
DynamoDB ConditionalCheckFailedException — when the failed check is expected, and how to handle it cheaply.

References

Last verified 2026-07-28 against the official AWS documentation linked above.

DynamoDB Conditional Write in Node.js (AWS SDK v3)

DynoTable — Mon, 07 Sep 2026 15:03:38 +0000

The interesting part of a conditional write in AWS SDK v3 is not the ConditionExpression, which works the same everywhere and is covered in DynamoDB condition expressions. It is the failure path: v3 hands you the losing item on the thrown error, if you asked for it, and gives you nothing if you did not.

Code

import {DynamoDBClient, UpdateItemCommand} from '@aws-sdk/client-dynamodb';

const client = new DynamoDBClient({region: 'us-east-1'});

// Update the item only if nobody changed it since we read version 7.
const command = new UpdateItemCommand({
  TableName: 'Music',
  Key: {
    Artist: {S: 'Arturo Sandoval'},
    SongTitle: {S: 'Cubano Chant'}
  },
  UpdateExpression: 'SET #upd0 = :updValue0, #version = :newVersion',
  ConditionExpression: 'attribute_exists(#cond0) AND #version = :expectedVersion',
  ExpressionAttributeNames: {
    '#upd0': 'Genre',
    '#version': 'Version',
    '#cond0': 'Artist'
  },
  ExpressionAttributeValues: {
    ':updValue0': {S: 'Latin Jazz'},
    ':expectedVersion': {N: '7'},
    ':newVersion': {N: '8'}
  },
  ReturnValuesOnConditionCheckFailure: 'ALL_OLD'
});

try {
  await client.send(command);
  console.log('Updated to version 8');
} catch (err) {
  if (err.name === 'ConditionalCheckFailedException') {
    // With ReturnValuesOnConditionCheckFailure: 'ALL_OLD', the current item
    // rides back on the exception — no extra read to see what beat you.
    console.log('Lost the race — item is now:', err.Item);
  } else {
    throw err;
  }
}

Explanation

The failed check is a thrown error, not a status field. v3 rejects the promise, so the write path and the lost-race path are different branches. err.name === 'ConditionalCheckFailedException' is the discriminator; anything else has to be re-thrown, which is what the else in the fence is for. Swallow the whole catch and you have silently turned a throttle into a no-op.
ReturnValuesOnConditionCheckFailure is the only way to see who beat you. Without it, the error carries the message and nothing else, and you are back to a GetItem you did not need. The API reference sets its valid values as ALL_OLD | NONE and confirms it consumes no read capacity.
err.Item is a raw AttributeValue map, the same shape as the Key you sent, not plain JavaScript. Run it through unmarshall from @aws-sdk/util-dynamodb before you compare Version to a number, or you will be comparing against {N: '9'}.
The failed write is still billed. The Developer Guide is explicit that a condition evaluating to false still consumes write capacity, sized on the larger of the old and new item. A retry loop on a hot key is a real line on the bill, so cap the attempts.
Every name in the fence is aliased (#version → Version, #cond0 → Artist) because the Expression Builder that generated it aliases unconditionally. That is heavier than necessary here and never wrong, which is the trade it makes.

Reading the loser's copy off the exception

Set the stored Version to 9 and run the fence, which expects 7. DynamoDB Local 3.3.0 throws, and the caught error carries:

err.name     ConditionalCheckFailedException
err.message  The conditional request failed
err.$metadata.httpStatusCode  400
err.Item     {
               Artist:     { S: 'Arturo Sandoval' },
               Year:       { N: '1994' },
               Version:    { N: '9' },
               SongTitle:  { S: 'Cubano Chant' },
               AlbumTitle: { S: 'Danzon' }
             }

That Version: 9 is the whole point. The retry can go straight back through the update with :expectedVersion set to 9, with no extra read and no window in which a third writer slips in between your GetItem and your retry.

Delete ReturnValuesOnConditionCheckFailure from the same command and re-run it. Same name, same message, same 400, and err.Item is undefined. Nothing warns you: the parameter is optional, its absence is not an error, and the code that reads err.Item just starts logging undefined in production.

Note also that a 400 here does not mean a malformed request. ValidationException and ConditionalCheckFailedException share the status code, and only one of them is a bug, which is why the branch is on err.name and never on the status.

To watch a condition succeed and fail against your own data, with the expression written for you rather than typed, download DynoTable.

Related examples

DynamoDB conditional write in Python — the same optimistic lock with boto3.
DynamoDB conditional write with the AWS CLI — the same optimistic lock from the shell.
DynamoDB PutItem in Node.js — the create-only attribute_not_exists put.
DynamoDB condition expressions — every function, with patterns.
Enforcing uniqueness on multiple attributes — conditions + transactions combined.
DynamoDB ConditionalCheckFailedException — when the failed check is expected, and how to handle it cheaply.

References

Last verified 2026-07-28 against the official AWS documentation linked above.

DynamoDB Conditional Write with the AWS CLI

DynoTable — Sun, 06 Sep 2026 12:54:04 +0000

A conditional write is straightforward to send from the shell and awkward to read, because the interesting result of a failed one arrives as an error rather than as output. DynamoDB condition expressions covers what the expression can say; this page is about running one from the CLI and getting the losing item back out of the failure.

Code

aws dynamodb update-item \
  --table-name 'Music' \
  --key '{"Artist":{"S":"Arturo Sandoval"},"SongTitle":{"S":"Cubano Chant"}}' \
  --update-expression 'SET #upd0 = :updValue0, #version = :newVersion' \
  --condition-expression 'attribute_exists(#cond0) AND #version = :expectedVersion' \
  --expression-attribute-names '{"#upd0":"Genre","#version":"Version","#cond0":"Artist"}' \
  --expression-attribute-values '{":updValue0":{"S":"Latin Jazz"},":expectedVersion":{"N":"7"},":newVersion":{"N":"8"}}'

On success the command prints nothing and exits 0. If another writer got there first, the condition fails and the CLI reports the service message:

An error occurred (ConditionalCheckFailedException) when calling the UpdateItem operation:
The conditional request failed

Explanation

Success — silent. No output, exit 0. There is nothing to parse and nothing to assert on, so a shell script has to treat the exit status as the result. Add --return-values ALL_NEW if you want the updated item printed.
Failure is exit status 254, which is the CLI v2 code for a client-side error and is shared with a malformed request. Branch on the message before you retry, or a typo in your expression becomes an infinite backoff loop.
--return-values-on-condition-check-failure ALL_OLD does work here. Valid values are ALL_OLD and NONE, and it consumes no read capacity. Getting the item out of the error takes one more flag, covered below.
Shared placeholder namespace — the condition and the update are separate flags, yet --expression-attribute-names and --expression-attribute-values are merged across --update-expression and --condition-expression, which is why the generated names run #upd0, #cond0 rather than restarting per clause. Reuse a placeholder for two different meanings and the second silently wins.
A failed write is still billed. The Developer Guide is explicit: a condition evaluating to false consumes write capacity anyway, sized on the larger of the old and new item. Conditions are not a cheap existence probe.

The failure output, and how to get the item out of it

Run the fence once and it succeeds silently. Run it a second time, when Version is no longer 7, and aws-cli/2.36.9 prints to stderr:

aws: [ERROR]: An error occurred (ConditionalCheckFailedException) when calling the UpdateItem operation: The conditional request failed

Add --return-values-on-condition-check-failure ALL_OLD and the default output tells you there is more, without showing it:

aws: [ERROR]: An error occurred (ConditionalCheckFailedException) when calling the UpdateItem operation: The conditional request failed

Additional error details:
Item: <complex value>
Use "--cli-error-format json" or another error format to see the full details.

<complex value> is the item, withheld by the default text renderer. Add --cli-error-format json and the whole thing prints:

{
    "Message": "The conditional request failed",
    "Code": "ConditionalCheckFailedException",
    "Item": {
        "Artist": {"S": "Arturo Sandoval"},
        "Year": {"N": "1994"},
        "Version": {"N": "8"},
        "SongTitle": {"S": "Cubano Chant"},
        "AlbumTitle": {"S": "Danzon"},
        "Genre": {"S": "Latin Jazz"}
    }
}

(Attribute maps folded onto one line each; everything else is as printed.) Version is 8 and Genre is set because the first run succeeded. That is the optimistic-locking loop closed from a shell script: pipe stderr through jq -r '.Item.Version.N', feed it back as :expectedVersion, retry. No get-item, and no window between the read and the retry for a third writer to slip into.

The retries are not free. Each rejected attempt consumes a write unit, so a contended key under a tight loop bills steadily while making no progress. The pricing calculator turns a write rate into a monthly figure if you want to know what a retry storm actually costs before you cap the attempts.

To run these guards against your own tables without shell-quoting the placeholder maps, download DynoTable.

Related examples

DynamoDB conditional write in Node.js — the same optimistic lock with AWS SDK v3.
DynamoDB conditional write in Python — the same optimistic lock with boto3.
DynamoDB PutItem with the AWS CLI — the create-only attribute_not_exists put.
DynamoDB condition expressions — every function, with patterns.
Understanding ReturnValues — what each return option gives you.
DynamoDB ConditionalCheckFailedException — when the failed check is expected, and how to handle it cheaply.

References

Last verified 2026-07-28 against the official AWS documentation linked above.

DynamoDB Batch Write in Python (boto3 batch_writer)

DynoTable — Sat, 05 Sep 2026 12:42:52 +0000

batch_writer() is the one DynamoDB call where Python is less work than the other SDKs. It buffers puts and deletes, cuts them into BatchWriteItem requests of 25, and resends unprocessed items itself. What it does not do is protect you from the two failures that break most bulk loads, and both of them surface at the flush rather than at the line that supplied the bad item.

Code

import boto3

dynamodb = boto3.resource("dynamodb")
table = dynamodb.Table("Music")

songs = [
    {"Artist": "Arturo Sandoval", "SongTitle": "Cubano Chant", "AlbumTitle": "Danzon", "Year": 1994},
    {"Artist": "Arturo Sandoval", "SongTitle": "A Mis Abuelos", "AlbumTitle": "Danzon", "Year": 1994},
    {"Artist": "Arturo Sandoval", "SongTitle": "Groovin' High", "AlbumTitle": "Swingin'", "Year": 1996},
]

with table.batch_writer() as batch:
    for song in songs:
        batch.put_item(Item=song)
    # batch_writer buffers deletes too — target a key you're NOT also putting
    # (two writes to the same key in one batch are rejected as a duplicate)
    batch.delete_item(Key={"Artist": "Ella Fitzgerald", "SongTitle": "Misty"})

print(f"Buffered {len(songs)} puts + 1 delete; the batch flushes on exit")

Explanation

Deferred flush — batch.put_item() appends to a list. Nothing is validated, serialized, or sent until the buffer reaches 25 or the with block exits, so the traceback for a bad item comes from the flush and not from the put_item call that supplied it. If you are loading from an iterator, keep your own index of what went into the buffer.
Plain Python values — this is the resource API, so you write 1994, not {"N": "1994"}. Decimals are required for anything fractional; a float is accepted into the buffer and rejected on flush.
batch_writer() is a Table method. The read-side counterpart is not: batch_get_item lives on the ServiceResource, and table.batch_get_item does not exist. There is no buffering, chunking, or retry helper for batch reads at all.
UnprocessedItems, not errors — that is the only retry it handles. A throttled write is resent; a ValidationException propagates. Going through client.batch_write_item instead hands you the whole loop, as in the Node.js example.
It cannot lift the service limits. 25 writes per request, 400 KB per item, 16 MB per request, no conditions and no updates, and every put replaces the entire stored item. Need a guard, or all-or-nothing? TransactWriteItems.

What batch_writer actually does on flush

Buffer 30 puts and watch the calls it makes. Wrapping table.meta.client.batch_write_item and recording the request sizes, against DynamoDB Local 3.3.0:

batch sizes sent: [25, 5]

Two requests, cut at the service limit, with the remainder flushed by __exit__. That flush is unconditional: raise a RuntimeError inside the block and the buffered items are still written on the way out. A bulk load that dies halfway leaves a partial load behind, not a clean slate.

Now the two failures. Buffer the same key twice, which is what happens the moment your source data has a repeat:

with table.batch_writer() as batch:
    batch.put_item(Item={"Artist": "Dup", "SongTitle": "Key", "Year": 1})
    batch.put_item(Item={"Artist": "Dup", "SongTitle": "Key", "Year": 2})

botocore.exceptions.ClientError: An error occurred (ValidationException) when calling the
BatchWriteItem operation: Provided list of item keys contains duplicates

Neither put_item complained. batch_writer() does not deduplicate unless you ask it to, and asking is table.batch_writer(overwrite_by_pkeys=["Artist", "SongTitle"]). Run the same two puts through that and the item stores as Year: 2 — the buffer keeps the last write per key, so the dedupe is silent data loss if your two rows were meant to be different items under a key you got wrong.

The second one is boto3's alone and never reaches DynamoDB:

TypeError: Float types are not supported. Use Decimal types instead.

A Rating of 4.5 sits in the buffer without complaint and blows up on the flush. Decimal("4.5") round-trips correctly as {"N": "4.5"}. Read a price or a rating out of JSON with json.loads and every number is a float, so this is a first-run failure for most import scripts. Passing parse_float=Decimal to json.loads fixes it at the source.

If you are moving between native Python values and the wire format by hand, the DynamoDB JSON converter shows both sides of the same item so you can see what your Decimal actually becomes.

To bulk-load from CSV or JSON without writing the type mapping yourself, download DynoTable.

Related examples

DynamoDB BatchWriteItem in Node.js — the manual retry loop batch_writer hides.
DynamoDB BatchWriteItem with the AWS CLI — the same batch write from the shell.
DynamoDB PutItem in Python — the single-item write this batches.
Batch operations in DynamoDB — limits, partial failure, and when batching pays off.
"Too many items requested for the BatchWriteItem call" — more than 25 put/delete requests in one batch.
"Provided list of item keys contains duplicates" — two requests touching the same key in one batch.

References

Last verified 2026-07-28 against the official AWS documentation linked above.

When to Use DynamoDB (and When Not To)

DynoTable — Fri, 04 Sep 2026 13:32:37 +0000

DynamoDB is a fantastic database for the workloads it's built for and a frustrating
one for the rest. The deciding question is "do I know
my access patterns up front, and are they key-based?" Get that right and DynamoDB
gives you single-digit-millisecond reads at any scale; get it wrong and you'll fight
the lack of joins and ad-hoc queries forever.

When should I use DynamoDB?

Use DynamoDB when your access patterns are known, key-based, and high-volume, and you
want predictable single-digit-millisecond latency at any scale with zero servers to
manage. Avoid it for ad-hoc queries, rich joins, or whole-dataset analytics, and when
the data is small with query shapes that keep changing.

Use DynamoDB when your access patterns are known, key-based, and high-volume — and you want predictable latency at any scale with no servers to manage.
Avoid it when you need ad-hoc queries, rich joins, or analytics over the whole dataset, or when the data is small and the query shapes keep changing.
The core trade: DynamoDB makes you design for your queries up front; in return it never slows down as you grow.
It is not a relational database with a different syntax — modeling it like one is the #1 source of pain.

The signals that favor DynamoDB

DynamoDB shines when most of these hold:

You know your access patterns in advance. You can list the exact queries the app makes ("get a user by id", "list a user's orders newest-first") and they don't change on a whim. DynamoDB is modeled around those queries.
Access is key-based. You look items up by a known partition key, not by scanning for arbitrary attribute combinations.
Scale and predictable latency matter. DynamoDB delivers consistent single-digit-millisecond performance whether the table holds a thousand items or a billion.
You want zero operational overhead. No instances, no failover, no vacuuming — it's fully managed and scales to zero on-demand.
Write throughput is high and spiky. Event logs, IoT telemetry, session/cart state, leaderboards — append-heavy workloads with a clear key.

The signals against it

Reach for a relational database (or a search/analytics engine) instead when:

Your queries are ad-hoc. Analysts slice the data by arbitrary columns, or requirements change weekly. SQL's flexibility wins; DynamoDB would need a new index per pattern.
You need real joins and aggregations across the whole dataset. Reporting, business intelligence, "sum revenue by region by month" — that's an OLAP/relational job. (The one-off question against a live table is a different case — DynoTable's SQL Workbench runs JOIN, GROUP BY, and aggregates over DynamoDB client-side; it's the standing BI workload that belongs elsewhere.)
The dataset is small and low-traffic. A few thousand rows on a quiet admin app gets no benefit from DynamoDB's scale and loses SQL's convenience.
You can't predict access patterns yet. Early-stage product still finding its shape? A relational schema you can re-query freely is more forgiving until the patterns settle.

How DynamoDB compares to other databases

"Should I use DynamoDB or X?" is usually the same question in different clothes: does X
let me postpone the access-pattern decision, and what do I pay for that? DynamoDB is
the option that refuses to let you postpone it. Every comparison below turns on that one
trade, not on feature checklists.

Relational: PostgreSQL, RDS, and Aurora

This is the real fork, and the one most teams get wrong. A relational database lets you
write the query after you have the data. DynamoDB does not — the table is shaped by the
queries before a single item is written.

Pick relational when the query shapes are still moving, when you need joins or
aggregates across the whole dataset, or when the data is small enough that scale is not
the problem you have. Pick DynamoDB when the patterns are settled and key-based and you
want them to cost the same at a billion items as at a thousand.

RDS and Aurora do not change that calculus — they are managed relational engines, so
they inherit SQL's flexibility and its scaling model. What they change is the operational
comparison: with Aurora Serverless the "no servers to manage" argument for DynamoDB gets
much weaker, and the decision falls back cleanly onto access patterns. Aurora scales
compute; DynamoDB removes the concept.

Document: MongoDB and DocumentDB

Both store JSON-ish documents, so they look interchangeable with DynamoDB from a distance.
They are not. MongoDB indexes any field and runs ad-hoc queries against it; DynamoDB gives
you the partition key, the sort key, and the indexes you declared in advance.

That makes MongoDB the better fit for evolving query shapes, and DynamoDB the better fit
for known ones at high volume. DocumentDB sits on the AWS side of the same line — it
speaks the MongoDB API, so treat it as "MongoDB's flexibility, AWS's operational model",
and compare it to DynamoDB on exactly the flexibility-versus-predictability axis above.

Wide-column: Cassandra

Cassandra is DynamoDB's closest architectural relative: partition key, clustering
key, and the same hard truth that a bad partition key is a design bug you cannot index
your way out of. If you are choosing between them, the deciding factors are rarely the
data model — they are who runs it and how you pay. Cassandra you operate (or buy managed);
DynamoDB you consume. Amazon Keyspaces is the managed-Cassandra middle ground.

Because the models are so close, the modeling guidance on this site mostly transfers: the
single-table design reasoning about partition keys
and access patterns applies to Cassandra almost line for line.

In-memory: Redis

Redis and DynamoDB solve different problems. Redis is memory-first and optimized for sub-millisecond access to
data you can afford to lose or rebuild; DynamoDB is durable by default. The common
production answer is both — DynamoDB as the system of record, Redis (or DAX, which is
DynamoDB's own read-through cache) in front of the hot keys.

Reach for Redis alone only when the data is genuinely ephemeral: rate-limit counters,
short-lived sessions, leaderboards you can recompute.

Search: Elasticsearch and OpenSearch

Search and DynamoDB solve different problems too — for a sharper reason than Redis: DynamoDB has no full-text
search at all. Query matches on key equality and a narrow set of sort-key conditions.
Scan with a FilterExpression reads every item and then discards most of them — it is a
table walk with a filter bolted on, not a search, and you pay for the items read rather than
the items returned. There is no relevance ranking, no analyzers, no fuzzy matching, no
faceting.

So the question is never "DynamoDB or a search engine". It is "does this workload need
search, and if so, what feeds the index?" The standard shape is both: DynamoDB as the system
of record, a search cluster alongside it, and DynamoDB Streams carrying every change into the
index. That buys real search and costs you a second system to run and an index that is
eventually consistent with the table.

OpenSearch and Elasticsearch are the same decision. OpenSearch is AWS's fork of
Elasticsearch, split at 7.10 in 2021 over Elastic's licence change, and the two have drifted
apart since. None of that drift touches this question — for "should the search live outside
DynamoDB", they behave identically. Choose between them on licensing, hosting and which
managed service you want to operate, not on anything to do with DynamoDB.

Reach for a search engine as the primary store only when search genuinely is the product —
log analytics, a catalogue whose main access pattern is free-text. Even then, most teams keep
a durable store behind it, because a search index is a derived view you need to be able to
rebuild.

The cost axis, which the model comparison hides

Every comparison above is about data models, but the surprise on the bill is usually
structural: relational engines bill for capacity you provision, DynamoDB bills for
operations you perform. That makes DynamoDB cheap for spiky and idle workloads and
expensive for sustained scanning — the same workload can win on one engine and lose badly
on the other with no code change between them.

The multiplier people miss is indexes. On a relational engine an extra index costs storage
and some write latency; on DynamoDB every secondary index is a full extra write of the
projected attributes. We worked the arithmetic out at three write volumes in
the indexes guide — one GSI doubles the write bill, two triple
it. Model your real read/write mix in the
pricing calculator before you commit to either side.

Counting the cost before you commit

DynamoDB pricing follows reads, writes, and storage — not instance hours — so it's
cheap for spiky and serverless workloads and can be pricey for sustained heavy scans.
Model your real read/write mix with the
DynamoDB pricing calculator before committing;
a workload that looks like a fit technically should also pencil out on cost.

Once you've decided it fits

The work shifts to modeling. DynamoDB rewards designing the table around your queries
— see how to model data in DynamoDB and
single-table design — and explicitly
when not to reach for single-table.

Pitfalls + next steps

Don't model DynamoDB like a relational database — normalized tables you join at read time is the anti-pattern it punishes hardest.
Don't pick it for analytics — pair it with an analytics store (or export to one) for reporting instead of scanning.
Unsure about access patterns? Wait. Adopting DynamoDB before you know your queries is choosing the one database that demands you know them.
Related: query vs scan shows what "key-based access" actually buys you.

Want to explore a DynamoDB table before betting your app on it?
Download DynoTable and connect to your data directly — its
SQL Workbench runs the ad-hoc JOINs and aggregates
DynamoDB itself won't.

How to View, Browse and Edit DynamoDB Data

DynoTable — Thu, 03 Sep 2026 13:35:30 +0000

Every "look at" or "change" you do to a DynamoDB table maps to one of a small set of
API operations — GetItem, Query, Scan, PutItem, UpdateItem, DeleteItem.
There's no relational table viewer underneath: "browsing a table" is literally a
Scan, and "editing a row" is an UpdateItem against a primary key. Knowing which
operation each click maps to is the difference between a cheap read and a full-table
scan you didn't mean to run.

DynoTable is a GUI over exactly these operations — it shows you which one you're
about to run, and the cost, before it hits the wire.

How to browse a DynamoDB table

Opening a table to "see what's in it" is a Scan — it reads every item in the
table or index (AWS:
"A Scan operation in Amazon DynamoDB reads every item in a table or a secondary
index."). Fine for small tables; on a large one it's the classic cost footgun
covered in query vs scan.

A single Scan returns at most 1 MB of data, then hands you a LastEvaluatedKey to
fetch the next page — so "browse the whole table" is really a pagination loop
(AWS:
"A single Scan request can retrieve a maximum of 1 MB of data" and "the
LastEvaluatedKey from a Scan response should be used as the ExclusiveStartKey
for the next Scan request"). See
pagination for how the cursor works and why offset-style page
numbers don't exist here.

Tip

A DynamoDB GUI hides the pagination loop behind a scroll or a "next page" button,
but it's still issuing one paged Scan per page. Watch the consumed-capacity
readout, not the row count, to know what you're spending.

How to filter / scan DynamoDB data

A filter expression does not save you a scan. DynamoDB applies the
filter after the read completes, so you pay for every item scanned — not just the
rows you keep.

A filter expression is applied after a Scan finishes but before the results are
returned. Therefore, a Scan consumes the same amount of read capacity,
regardless of whether a filter expression is present.
— AWS Scan docs

The response makes this visible: ScannedCount is "the number of items evaluated,
before any ScanFilter is applied" while Count is what survived the filter
(AWS).
A high ScannedCount with a tiny Count is the signature of an inefficient scan.

Warning

"Filtering a table" in any DynamoDB GUI is a filtered Scan — it reads (and
charges for) the whole table, then throws most of it away client-side. If you're
filtering by an attribute you query often, that attribute probably wants a
GSI so you can Query it instead.

How to query a DynamoDB table

A Query is the cheap, targeted read — but it requires a partition key. Per
AWS:
"You must provide the name of the partition key attribute and a single value for
that attribute. Query returns all items with that partition key value. Optionally,
you can provide a sort key attribute and use a comparison operator to refine the
search results."

So a Query reads only the items under one partition key, optionally narrowed by a
sort-key condition — never the whole table. No partition key, no Query: you're
back to a Scan. That choice is the single most important cost decision in
DynamoDB; the full breakdown is in query vs scan.

On on-demand in us-east-1, opening a table to "browse" it runs a paged Scan
that bills 0.5 RCU per 4 KB eventually-consistent per item examined — a GUI
scroll through a 10 GB table of 1 KB rows is on the order of 2.5
million RCU if you load everything. A targeted Query on one partition key reads
only that item collection. Estimate browse vs query in the
pricing calculator.

To assemble the KeyConditionExpression / FilterExpression without hand-writing
the placeholder syntax, use the
DynamoDB Expression Builder — it emits the
exact names/values maps the API expects.

How to edit an item in DynamoDB

Editing one item is an UpdateItem against its full primary key. You don't
rewrite the whole item — you supply an update expression naming only the
attributes you're changing:

UpdateItem
  Key:              { "PK": "USER#42", "SK": "PROFILE" }
  UpdateExpression: SET email = :e, updatedAt = :t

Two facts that trip people up, both from the
AWS items docs:

You must specify the entire primary key, not just part of it. On a composite-key table that's partition key and sort key. You can't "edit a row" by an arbitrary attribute — that needs a scan to find the key first.
UpdateItem is an upsert. "If an item with the specified key does not exist, UpdateItem creates a new item. Otherwise, it modifies an existing item's attributes." A typo in the key silently creates a new item instead of erroring.

Note

Inline-editing a cell in a DynamoDB GUI compiles to an UpdateItem with a
single-attribute SET. The value's type tag matters — editing "37" as a string
(S) vs a number (N) writes a different item. See
DynamoDB data types for the wire format behind every cell.

How to delete an item

A DeleteItem, again keyed by the full primary key:
"DeleteItem deletes the item with the specified key"
(AWS).
Same rule as edit — you need the whole key, so deleting "all rows where status =
'open'" isn't one call; you scan/query to find the keys, then delete each one.
BatchWriteItem bundles up to 25 put/delete requests
(AWS:
"The BatchWriteItem operation can contain up to 25 individual PutItem and
DeleteItem requests"), but each still targets one key — there's no DELETE … WHERE.

How to view nested / JSON data

DynamoDB items are stored in a type-tagged wire format (DynamoDB-JSON), where every
value carries a one- or two-letter type descriptor (S, N, M, L, SS… — the
full descriptor list is in the
AWS data types docs).
Plain JSON has no set type, so an array round-trips as a list (L), never a string
set (SS) — a real conversion limitation, not a display bug. The full type map is in
DynamoDB data types; to convert a DynamoDB-JSON blob to plain
JSON and back, use the DynamoDB JSON converter.

Beyond browse-and-edit: querying that DynamoDB can't

Scan/Query/UpdateItem cover viewing and editing, but they can't analyze —
DynamoDB has no JOIN, GROUP BY, or aggregate functions like COUNT/SUM, and
PartiQL doesn't add them either: its SELECT grammar is
just SELECT … FROM table [WHERE …] [ORDER BY …], with no join or grouping clause
(AWS PartiQL SELECT reference),
so each statement maps to a single Get/Query/Scan/Put/Update/Delete. DynoTable's SQL
Workbench fills that gap by materializing your tables through DynamoDB's real query
runtime and running SQL on top — SQL within DynamoDB's access-pattern rules —
but for day-to-day browse-and-edit, the operations above are the whole toolbox.

FAQ

How do I view DynamoDB data without the AWS Console?
Use a desktop GUI that issues the same Scan/Query calls. The AWS Console
browses tables via paged scans; a dedicated client like DynoTable does the same but
shows the consumed capacity and the operation you're running.

How do I edit a DynamoDB item?
Issue an UpdateItem against the item's full primary key with a SET update
expression naming only the attributes you're changing. In a GUI, inline-edit the
cell — it compiles to that UpdateItem for you.

Why does filtering still cost a full scan?
Because DynamoDB applies the filter after the scan reads the items. Filtered-out
items are still read and metered. To cut cost, query by a partition key (or a
GSI) instead of scanning.

Can I update many items at once?
There's no UPDATE … WHERE — each UpdateItem/DeleteItem targets a single primary
key. To change several items in one atomic request, TransactWriteItems applies up to
100 write actions (including Update) that all succeed or all roll back. Otherwise you
scan/query to collect the keys, then write each (up to 25 per BatchWriteItem).

Can I browse a DynamoDB Local table the same way?
Yes — point the same GUI at the local endpoint. See
DynamoDB Local.

Want to browse, filter and inline-edit DynamoDB tables — and run the SQL PartiQL
can't? Download DynoTable.

SQL for DynamoDB and the Limits of PartiQL

DynoTable — Wed, 02 Sep 2026 13:39:41 +0000

DynamoDB is a NoSQL key-value store, but it answers SQL-shaped questions more
than people expect — and far less than they hope. This is the honest map: what
SQL-on-DynamoDB you actually get out of the box, where it stops, and the few ways
to run the JOIN / GROUP BY / aggregate queries the native surface can't
express.

Can you query DynamoDB with SQL?

Partly. DynamoDB ships PartiQL, a SQL-compatible language for
SELECT/INSERT/UPDATE/DELETE by key, so SELECT * FROM "Orders" WHERE OrderID = 100 works. But it's a SQL-compatible surface over the DynamoDB API,
not a SQL engine — AWS supports only a subset, so JOIN, GROUP BY, and
COUNT(*) are out. For those you need an engine layered on top.

AWS describes PartiQL as
"a SQL-compatible query language, to select, insert, update, and delete data in
Amazon DynamoDB",
but is equally explicit that "Amazon DynamoDB supports a subset of the PartiQL
query language." The moment you reach for a JOIN, a GROUP BY, or COUNT(*),
you're outside what PartiQL can do — see
PartiQL vs SQL for the full feature-by-feature
comparison.

Note

Is DynamoDB SQL or NoSQL? NoSQL. DynamoDB is a managed key-value and document
store with no relational engine, no schema, and no query planner. PartiQL gives
it a SQL-looking query language; it does not make it a relational database.

PartiQL: a SQL-compatible surface, not a SQL engine

PartiQL maps SQL-looking statements onto the same data-plane operations the SDK
exposes. A SELECT with a partition-key equality compiles to a Query; a
SELECT without one compiles to a Scan. Per the
AWS SELECT reference:

Using the SELECT statement can result in a full table scan if an equality or
IN condition with a partition key is not provided in the WHERE clause.

So the same access-pattern rules that govern Query and Scan still apply —
PartiQL just hides them behind familiar syntax. It adds no query planner, no
joins, and no set-based aggregation. Every statement collapses to one native
operation:

A SELECT without a partition-key equality compiles to a full-table Scan. In
us-east-1 on-demand that bills 0.5 RCU per 4 KB eventually-consistent for
every item examined — a 500 MB table of 2 KB rows is roughly 62,500
RCU before any WHERE filter narrows the result set. Line-rate PartiQL-shaped
reads in the pricing calculator.

You write	DynamoDB runs
`SELECT … WHERE PK = …`	`GetItem` or `Query`
`SELECT …` (no PK)	`Scan` (reads the whole table)
`INSERT INTO …`	`PutItem`
`UPDATE … WHERE PK=… AND SK=…`	`UpdateItem` (one item)
`DELETE … WHERE PK=… AND SK=…`	`DeleteItem` (one item)

If an operation doesn't reduce to a single Get/Query/Scan/Put/Update/Delete,
PartiQL simply can't express it. Everything below is a consequence of that one
fact.

Warning

Writing SELECT * FROM "Orders" WHERE Total > 500 looks like SQL, but Total
is a non-key attribute — the AWS docs list this exact Total > 500 predicate
among the SELECT statements that "will result in a full table scan"
(reference).
Same for WHERE Total IN [500, 600] or WHERE Total BETWEEN 500 AND 600 on a
non-key attribute. SQL syntax doesn't change DynamoDB's economics. See
Query vs Scan.

What PartiQL covers

DynamoDB's PartiQL supports four DML/query statements:

SELECT — read items (compiles to Query or Scan)
INSERT — add an item (PutItem)
UPDATE — modify an item (UpdateItem)
DELETE — remove an item (DeleteItem)

It also supports
transactions and batch operations.
A well-formed read targets
the partition key with an equality or IN:

SELECT OrderID, Total
FROM "Orders"
WHERE OrderID IN [1, 2, 3] ORDER BY OrderID DESC

ORDER BY is allowed, but the AWS reference restricts the ordering key to "a
hash key or a sort key" — the partition or sort key, not arbitrary columns.
That's the ceiling of what PartiQL's SELECT accepts. For copy-paste-ready
statements, see PartiQL examples.

What PartiQL can't do

These are the things developers most often expect from "SQL," and PartiQL
supports none of them:

No JOIN. The PartiQL SELECT syntax is a single FROM {{table}}[.{{index}}] — one table or one index, never two tables related on a key. This is the single-table-design tradeoff: you model for your access patterns up front because the query layer can't reshape data afterward.
No GROUP BY. It isn't in the grammar; there's no clause to group rows.
No aggregate functions. The PartiQL functions reference lists exactly one function under "Aggregate functions": SIZE, which returns an attribute's size in bytes for a single item. There is no COUNT, SUM, AVG, MIN, or MAX across rows. AWS states plainly: "Any SQL functions that are not included in this list are not currently supported in DynamoDB."
No LIKE, no subqueries, no UNION, no window functions. Pattern matching uses contains / begins_with; the rest have no equivalent at all.

So "total revenue by customer last month" — a one-line GROUP BY in any
relational database — can't be expressed in PartiQL. You'd scan the data out and
aggregate it in application code.

The only way to get real JOIN / GROUP BY / aggregate behavior over DynamoDB
data is a tool that runs an actual SQL engine on top of it. For interactive,
ad-hoc queries there are two: Amazon Athena's federated connector, and
DynoTable's SQL Workbench. (For scheduled analytics, DynamoDB's zero-ETL
integration to Amazon Redshift also runs SQL joins and aggregates.)

How to query DynamoDB with real SQL via Amazon Athena

AWS's own answer to "real SQL over DynamoDB" is the
Amazon Athena DynamoDB connector,
which "enables Amazon Athena to communicate with DynamoDB so that you can query
your tables with SQL." Because Athena is a full SQL engine, this does get you
JOIN and aggregates — AWS's walkthrough is titled
"Access, query, and join Amazon DynamoDB tables using Athena."

The catch is setup and cost:

It's a Lambda-based federated connector you deploy into your account (via the Athena console or the Serverless Application Repository), wired through AWS Glue for schema and spilling results to an S3 bucket (connector docs).
Under the hood it still uses DynamoDB's Query and Scan API operations. AWS warns that "queries that use scans can consume a large number of read capacity units (RCUs)," so an analytical query over a big table reads — and meters — a lot of items (connector costs). Use the item-size calculator to gauge what a scan-heavy query will cost.
Write operations like INSERT INTO are not supported through the connector.

Athena is the right tool for scheduled analytics and BI dashboards. It's heavy
for the everyday "I just need to join two tables and eyeball the result" case —
that's the gap the next section fills.

DynoTable SQL Workbench: SQL within DynamoDB's access-pattern rules

DynoTable's SQL Workbench runs real SQL — JOIN, GROUP BY,
COUNT/SUM/AVG — against your live DynamoDB tables from a desktop client,
with no Lambda, Glue, or S3 to stand up. It materializes the rows through
DynamoDB's real Query/Scan runtime, then runs a single SELECT over them
locally on your desktop:

-- Runs in the DynoTable Workbench (NOT in PartiQL):
SELECT c.country, COUNT(*) AS orders, SUM(o.total) AS revenue
FROM orders o
INNER JOIN customers c ON o.customerId = c.PK
GROUP BY c.country
ORDER BY revenue DESC

The "within DynamoDB's access-pattern rules" part matters. The Workbench doesn't
pretend DynamoDB is Postgres — it still reads through Query/Scan under the
hood, so you stay aware of what each query costs, and it enforces DynamoDB's
access model rather than hiding it:

INNER JOIN and LEFT JOIN only — the ON target attribute must be a partition key or GSI partition key. No RIGHT / FULL / CROSS / comma-join.
No self-joins yet, no subqueries, no derived tables, no window functions.
Joins and projections operate on scalar attributes.

If you only need to compose the conditions and key expressions for the raw API —
not a full SQL statement — the
DynamoDB Expression Builder generates the
correct FilterExpression / KeyConditionExpression without the PartiQL surface
at all.

If your goal is a DynamoDB SQL client for exploring, debugging, and analyzing
tables, the Workbench fills that gap — and the rest of DynoTable is a full
DynamoDB GUI around it.

Try DynoTable to run real SQL against your own tables.

FAQ

Can you run SQL on DynamoDB?
You can run PartiQL, a SQL-compatible subset (SELECT/INSERT/UPDATE/DELETE by
key). For JOIN, GROUP BY and aggregates you need a SQL engine on top: the Amazon
Athena DynamoDB connector, or DynoTable's SQL Workbench — a single SELECT dialect
with INNER/LEFT JOIN, no CTEs, unions or subqueries.

Does DynamoDB PartiQL support JOIN?
No. The PartiQL SELECT syntax has a single FROM table or index and no join
grammar. Joins require an engine layered over DynamoDB.

Does PartiQL support GROUP BY or aggregates like COUNT and SUM?
No. There's no GROUP BY clause, and the only "aggregate" function is SIZE
(an attribute's byte size for one item). COUNT, SUM, AVG, MIN, and MAX
across rows aren't supported.

Is DynamoDB SQL or NoSQL?
NoSQL — a key-value and document store. PartiQL adds a SQL-compatible query
language on top, but DynamoDB has no relational engine, joins, or aggregates.

Is PartiQL good for ad-hoc queries?
For key-based lookups, yes. For analytical ad-hoc queries (counts, rollups,
joins), no — PartiQL can't express them, and unconstrained SELECTs silently
become full table scans.

Is there a DynamoDB SQL client that handles JOIN and GROUP BY?
Yes — DynoTable's SQL Workbench runs JOIN/GROUP BY/aggregates against live
tables from the desktop, and Amazon Athena does it via a federated connector you
deploy in your AWS account.

How to Query DynamoDB with AI (Natural Language)

DynoTable — Tue, 01 Sep 2026 14:10:04 +0000

"Show me last week's failed orders" is a one-liner in your head and a
KeyConditionExpression with placeholder maps on the wire. Closing that gap
is what "query DynamoDB with AI" actually means — because the DynamoDB API
itself has no natural-language endpoint. Every request is still
expressions or PartiQL; AI sits in the tooling layer, translating
your intent into them.

That translation can be genuinely great or quietly dangerous, depending on
one thing: whether the model can see your real schema. This guide covers
the three working setups and where each one breaks.

How do I query DynamoDB using natural language?

Three real options: ask a general LLM to draft PartiQL and run it yourself
(fast, but the model is guessing your attribute names), connect an AI agent
to DynamoDB through an MCP server so it can
inspect and query for real, or use a DynamoDB client with a built-in
schema-aware agent — DynoTable's AI chat turns plain
language into PartiQL or SQL against your actual indexed schema, computes
exact whole-table aggregates, and stages any write for your review.

Option 1: LLM-drafted PartiQL, run by you

Describe the query to any capable model, get PartiQL
back, run it in the console's PartiQL editor or via the CLI:

aws dynamodb execute-statement \
  --statement "SELECT * FROM \"Orders\" WHERE PK = 'ORDER#1001'"

It works — and it fails in three predictable ways:

The model can't see your table. It will confidently invent attribute names and key shapes (orderId when yours is PK = ORDER#<id>). You end up debugging hallucinated schema instead of writing the query.
PartiQL's limits still apply. A SELECT reads exactly one table, and a WHERE that doesn't pin a key becomes a full table scan — silently expensive, exactly as if you'd written it yourself. The model rarely warns you; PartiQL vs SQL explains what the SQL surface does and doesn't buy.
Pasting schema or data into a chatbot is a data-governance decision. Sample items in a prompt are production data leaving your boundary.

Good for one-off queries on a schema you can paste from memory; shaky as a
workflow.

Option 2: an AI agent connected via MCP

The structural fix for "the model can't see your table" is to give the agent
tools instead of a prompt-pasted schema. The Model Context Protocol (MCP)
does exactly that: an MCP server exposes DynamoDB operations as typed tools,
and any MCP-capable agent (Claude, IDE assistants, custom agents) can list
tables, inspect keys, and run queries with real results feeding back into the
conversation.

We cover the full setup — and the consent, scoping, and write-safety
questions that come with letting an agent touch a database — in
Using DynamoDB with an MCP server. DynoTable
itself ships one: it can expose gated, loopback-only tools to external
agents, with per-connection consent and scopes.

This is the right architecture when the agent is the product — a support
bot, an internal Slack assistant. For interactive day-to-day work, it still
leaves you assembling agent, server, and credentials yourself.

Option 3: a schema-aware agent in your DynamoDB client

DynoTable's built-in agent is the integrated version: it
lives next to your tables (⌘;), and it reads your indexed
schema — the tables under the active profile, their keys and indexes, the
attribute paths and types discovered by
table indexing, even sample values —
so "filter this to last week" resolves against your real attribute names, not
a guess. Type @ to reference a @table, @column, or @gsi explicitly.

What it does with a question, per the capability catalog:

Writes the query for you — read-only PartiQL, or Workbench SQL when the question needs JOIN / GROUP BY / aggregates (the analytics DynamoDB's API doesn't have) — and proposes the result as a chip you click to open as a real tab.
Computes exact whole-table answers. Ask for a count, sum, average, or per-group breakdown and it reads every matching item, not a sampled page — "how many orders last month?" reflects the actual table. It can reshape the same pass into a transformed export file.
Stages every write. Ask it to fix a row and the change lands in the staging area as a reviewable diff — the agent cannot write to DynamoDB directly, batch-delete a table, or alter table structure, in any permission mode. You review, you commit.
Asks before spending your money. Reads that hit AWS and cost capacity are permission-gated (Manual / Auto / Full Auto, per profile), and every gated decision lands in a local, always-on audit log.

The trust model matters as much as the features: the agent runs on your
own AWS Bedrock credentials, talking directly to Bedrock in your account —
prompts, schema, and table data never route through DynoTable's servers, and
inference is billed to you at Bedrock's own rates with no markup. Tool
results are treated as untrusted data, so a row containing "ignore previous
instructions" can't hijack the agent.

What AI does NOT change about DynamoDB

Any honest AI layer inherits the database's physics:

Access patterns still rule. "Where status = X" over a non-key attribute is a filtered scan no matter who writes it — the model just types the expensive query faster. If a question keeps forcing scans, the fix is modeling (a GSI, a better sort key), not a better prompt.
Reads cost real capacity. An exact whole-table aggregate is a whole-table read. Good tools gate it and say so; the pricing calculator tells you what a full pass costs before you approve it.
Determinism has its place. For a query you'll run forever in production, hand-build the expression once in the Expression Builder and ship the exact names/values maps — AI is for exploration, the builder is for the code you commit.

FAQ

Can I query DynamoDB in plain English?
Not against the API itself — DynamoDB only speaks expressions and PartiQL.
But an AI layer can translate: an LLM drafting PartiQL, an MCP-connected
agent, or a schema-aware agent like DynoTable's that generates and runs
the query against your real schema.

Does DynamoDB have a built-in AI query feature?
The DynamoDB API has no natural-language endpoint. Whatever AI querying you
get comes from the tooling layer on top — which is why the safety model of
that tooling (read gates, staged writes, your own credentials) is the thing
to evaluate.

Is it safe to let AI near production data?
It's a permissions question. Look for: reads gated behind explicit approval,
writes that land in a reviewable staging area instead of executing directly,
an audit log, and inference on credentials you control. DynoTable's
agent meets all four; a chatbot with your pasted data meets none.

Can the AI join tables or do GROUP BY?
Not via the DynamoDB API — no engine exists for it.
DynoTable's agent answers those questions through its Workbench SQL (real JOIN, GROUP BY, and aggregates within DynamoDB's access-pattern
rules), which is also where count/sum/average
questions land.

What does it cost?
Two meters: DynamoDB read capacity for whatever the queries touch (the
agent asks before gated reads), and Bedrock inference billed to your own
AWS account — DynoTable adds no markup and proxies nothing.

Ask your next question in plain language — download DynoTable,
point AI at your own Bedrock, and keep every write behind a review.

One-to-Many Relationships in DynamoDB

DynoTable — Mon, 31 Aug 2026 17:04:27 +0000

A SaaS control plane almost always has a containment hierarchy: one workspace
owns many projects. In SQL you'd put a workspace_id foreign key on the
projects table and JOIN.

DynamoDB has no joins and no foreign keys, so the relationship has to live in the
key schema itself. Done right, "load a workspace and every project inside it"
becomes a single Query instead of one read plus a follow-up scan.

How do you model a one-to-many relationship in DynamoDB?

Give the parent and all its children the same partition key so they share one item collection, then differentiate them with the sort key. DynamoDB has no joins or foreign keys, so the relationship lives in the key schema itself. Loading a parent plus every child then becomes a single Query instead of a join.

Model the reads, not the entities. The one-to-many relationship only exists to serve "list a workspace's projects" — shape the keys around that query.
Encode the parent into the child's partition key. Give the workspace and all its projects the same partition-key value so they land in one item collection.
Then the list read is one Query. Parent plus its children come back together — no join, no second round trip (a Query returns up to 1 MB per page, paginating via LastEvaluatedKey beyond that).
Watch the hot partition. One huge tenant concentrates all its traffic on one partition; a giant workspace may need a sharded key and a fan-out read.

The access pattern, first

DynamoDB modeling is access-pattern-first, not entity-first — the same discipline
behind single-table design. Before choosing any
key, write down the reads the app actually issues:

Get one workspace's settings.
List every project in a workspace, newest-first.
Get one specific project by id.

The "one workspace, many projects" relationship only matters because of read #2.
If you never needed to list a workspace's projects together, you wouldn't model
the relationship at all — you'd store projects independently.

So the question is never "how do I represent one-to-many?" in the abstract. It's
"which queries must this relationship serve?" Answer that, then shape the keys
around it.

Why a foreign key won't help here

In DynamoDB every GetItem and Query targets a partition key, and the
service hashes that key to locate the partition holding the item.

AWS says so directly in the Core Components
docs: the partition-key value is the input to an internal hash function that
decides where data lives.

That hash-based placement is the inheritance from the original 2007 Dynamo:
Amazon's Highly Available Key-value Store paper, where consistent hashing
distributes keys across nodes.

A bare workspace_id attribute on a project item is invisible to that
machinery — DynamoDB can't "follow" it.

To fetch related items in one request, the parent's identity must be encoded into
the project's partition key, so all of a workspace's items hash to the same
partition and one Query can sweep them.

Worked example: workspaces and projects

Use a generic, overloaded key schema. Call the partition key EntityRef and the
sort key Detail. The workspace identity goes into EntityRef for both the
workspace item and every project under it:

EntityRef	Detail	attributes
WS#acme	META	displayName, region, seatLimit
WS#acme	PROJ#2026-0007	title, status, createdBy
WS#acme	PROJ#2026-0042	title, status, createdBy
WS#acme	PROJ#2026-0118	title, status, createdBy
WS#globex	META	displayName, region, seatLimit
WS#globex	PROJ#2026-0009	title, status, createdBy

The workspace and all its projects share EntityRef = "WS#acme", so they form a
single item collection living together on one partition.

The Detail sort key separates them: META is the workspace record, and each
project carries a PROJ# prefix with a zero-padded, time-ordered id so projects
sort naturally.

Visually, the parent and its children stack inside one partition, ordered by the
sort key:

One Query on EntityRef = "WS#acme" sweeps the whole stack — parent plus every
child — in a single read.

Now the three access patterns each collapse to one call:

Workspace settings — GetItem(EntityRef="WS#acme", Detail="META").
List projects newest-first — Query(EntityRef="WS#acme") with Detail begins_with "PROJ#", run in descending order (ScanIndexForward = false).
One project — GetItem(EntityRef="WS#acme", Detail="PROJ#2026-0042").

The second one is the point. The parent and its children come back from
one Query, no join and no second round trip — DynamoDB returns up to 1 MB
per page and hands you a LastEvaluatedKey to fetch the rest. That's the move
you can't make with a foreign-key attribute and a Scan.

Interactive access pattern explorer: try it on dynotable.com

Writing that begins_with condition by hand is fiddly — the key-condition and
projection-expression syntax bites.

The DynamoDB Expression Builder generates
the KeyConditionExpression, the #name/:value placeholder maps, and a
ready-to-run SDK snippet so you don't fight the grammar:

Example	Notes
`KeyConditionExpression "#er = :er AND begins_with(#d, :p)"`
`ExpressionAttributeNames { "#er": "EntityRef", "#d": "Detail" }`
`ExpressionAttributeValues { ":er": "WS#acme", ":p": "PROJ#" }`

Inspect the item collection in DynoTable

Every row sharing an EntityRef is the
workspace plus its children, sitting next to each other.

DynoTable groups them so you see the one-to-many relationship as one contiguous
block instead of guessing at it across separate tables.

Pitfalls and the alternative shape

A few things to watch:

Hot partitions. Every item for one workspace lives on one partition, so a single very large or very busy tenant concentrates traffic. The adaptive capacity behavior AWS describes absorbs moderate skew, but a workspace with millions of projects may need a sharded key (e.g. WS#acme#01 … #10) and a fan-out read.
Item-collection size. With a local secondary index, a single partition's item collection is capped at 10 GB; without an LSI there's no such limit. If you're weighing index types here, see GSI vs LSI.
Reach for Query, never Scan. The whole design exists so you can Query one partition. Falling back to a filtered Scan to "find a workspace's projects" throws the model away and reads the entire table — the trap covered in Query vs Scan.

If you genuinely need to list projects across workspaces (say, all
status = ACTIVE projects globally), the base table can't answer that — its
partition key is workspace-scoped.

That's a job for a secondary index that re-partitions projects on a different
attribute, not for reshaping this relationship.

Next steps

Model the access patterns, encode the parent into the child's partition key, and
the one-to-many read is a single Query. Build and validate the key condition
with the DynamoDB Expression Builder — and
if you'd rather start from the access patterns themselves, the free
Single-Table Design tool drafts the
PK/SK/GSI plan with example items.

Then download DynoTable to load this schema, browse the
workspace→projects item collection live, and confirm each query does exactly one
read. If you'd rather see workspaces and projects as a joined, relational view,
DynoTable's SQL Workbench runs that JOIN too.

Many-to-Many Relationships in DynamoDB

DynoTable — Sun, 30 Aug 2026 14:25:29 +0000

A student enrolls in many courses; a course holds many students. In SQL you reach
for a join table and a three-table JOIN.

DynamoDB has no joins, so the relationship has to live in the keys — and the
trick is to store each enrollment edge in a shape that both sides can Query
directly.

This guide walks the students ↔ courses problem end to end: the access patterns, the
adjacency-list pattern that solves them, an original key schema you can copy, and how
to read both directions back without ever scanning the table.

How do you model a many-to-many relationship in DynamoDB?

DynamoDB has no joins, so you model a many-to-many relationship with the adjacency-list pattern: store each link as its own edge item keyed by one side, then add an inverted GSI that swaps the keys. A single edge, written once, then answers queries from both directions cheaply.

Store each enrollment as its own edge item, not a list attribute on either side.
Key the edge by the student (PK = STU#…, SK = ENROLL#CRS#…) so one Query returns a student's whole course list.
Add an inverted GSI that swaps the roles (GSI1PK = CRS#…) so the same edge also answers "who's in this course?".
One edge, written once, reads cheaply both ways — that's the entire game.

Frame the access patterns first

DynamoDB modeling is access-pattern-first: you decide the reads before you pick a
single attribute name. A many-to-many relationship almost always has two symmetric
reads plus the entity lookups:

Get a student's profile, and list every course that student is enrolled in.
Get a course's metadata, and list every student enrolled in that course.
Look up a single enrollment edge — to update a grade or drop the course.

The two list reads point in opposite directions across the same set of
edges. A naive design serves one cheaply and forces a Scan for the other — the exact
footgun covered in Query vs Scan.

The job is to make both directions a single Query.

Use the adjacency-list pattern

DynamoDB's own guidance for relationships is the adjacency list: model each
relationship as an item whose partition key is one endpoint and whose sort key is the
other.

AWS documents this on the
Best Practices for Managing Many-to-Many Relationships
page of the DynamoDB Developer Guide.

Why keys and not a second table? Because the primitive DynamoDB gives you is a Query
against a single partition.

A Query reads a contiguous range of sort-key values under one partition key in one
billed operation — that is the only "join" the engine offers.

To get a relationship that reads cheaply from both sides, you duplicate the edge:
write it once keyed by the student, then use a secondary index to project the same edge
keyed by the course.

This is the overloaded-key thinking from
Single-Table Design, applied to a relationship instead
of a parent-child hierarchy.

The shape is two stacked views of the same edge — the base table keyed by student, the
inverted GSI keyed by course:

Each edge is written once on the base table and projected into the GSI with its keys
swapped, so a Query against either partition reads the relationship cheaply.

The lineage goes back to the 2007 Amazon
Dynamo paper:
the partition key is the unit of distribution, and single-key access is the fast path.

Relationships in DynamoDB are an exercise in bending many-to-many reads into that fast
path.

Work the example: students ↔ courses

Use one table with generic keys, PK and SK, and encode the entity type in the
value. The enrollment edge is the heart of it:

PK	SK	attributes
STU#a91	PROFILE	name, year, major
STU#a91	ENROLL#CRS#math204 enrolledOn, grade
STU#a91	ENROLL#CRS#cs101	enrolledOn, grade
CRS#math204	METADATA	title, credits, term
CRS#cs101	METADATA	title, credits, term

A single Query PK = "STU#a91" returns the student's profile and every enrollment
in one read. Narrow it with SK begins_with "ENROLL#" to get just the course edges.
That solves "list a student's courses".

But "list a course's students" points the other way — and the base table can't answer
it, because the student id is in the partition key, not the sort key.

Add an inverted global secondary index that swaps the roles. Give the edge items a
generic GSI1PK/GSI1SK pair holding the course on the partition side and the student
on the sort side:

PK	SK	GSI1PK	GSI1SK
STU#a91	ENROLL#CRS#math204	CRS#math204	STU#a91
STU#b30	ENROLL#CRS#math204	CRS#math204	STU#b30
STU#a91	ENROLL#CRS#cs101	CRS#cs101	STU#a91

Now Query GSI1 WHERE GSI1PK = "CRS#math204" lists every student in that course — the
read the base table couldn't serve. One edge item, written once, answers both
directions.

Interactive access pattern explorer: try it on dynotable.com

It has to be a GSI, not an LSI: the course partition is entirely different from the
student partition, and an LSI shares the base table's partition key.

The index spans multiple partitions, so it must be global — see
GSI vs LSI.

GSIs in DynamoDB are populated asynchronously. A brand-new enrollment can take a
moment to appear in the CRS#… direction.

Treat the course-roster read as eventually consistent — which the Developer Guide calls
out explicitly for global secondary indexes.

Write and read it in DynoTable

Writing the enrollment means setting four key attributes plus the edge's own data. The
condition that stops a student from enrolling twice in the same course is an
attribute_not_exists(PK) guard on the composite key.

That's exactly the kind of condition you can assemble visually with the
DynamoDB Expression Builder instead of
hand-writing the ExpressionAttributeNames and placeholder values.

In DynoTable you point a Query at GSI1, set GSI1PK = "CRS#math204", and the
roster comes back as a table you can read, sort, and edit in place — both directions of
the relationship browsable from one schema.

Pitfalls and next steps

Don't store one side as a list attribute. A courseIds array on the student item feels tidy until a course needs its roster, the array hits the 400 KB item ceiling, or two enrollments race and clobber each other. Discrete edge items scale and update independently.
Keep edge data on the edge. The enrollment's grade and enrolledOn belong on the edge item, not duplicated onto the student or course — there's exactly one row per (student, course) pair to update.
Mind GSI propagation. The inverted-index direction is eventually consistent, so a read immediately after an enrollment may lag by a fraction of a second.
Project only what the roster needs. A KEYS_ONLY or narrow projection keeps the GSI small when the roster view only needs ids.

To go deeper on the surrounding patterns, read
Single-Table Design for overloaded keys and
GSI vs LSI for when the inverted index has to be global. And
to start from your own relationships, the free
Single-Table Design tool turns an
access-pattern list like "list a student's courses / list a course's students"
into a PK/SK/GSI plan with example items.

Then download DynoTable to model the students ↔ courses schema for real —
write the edges, build the condition with the Expression Builder, and query both
directions of the relationship without a single scan. And when you want the
classic three-table JOIN view anyway, DynoTable's SQL
Workbench runs it over your live tables.

How to Model Data in DynamoDB

DynoTable — Sat, 29 Aug 2026 14:28:39 +0000

In SQL you model entities and relationships first, then trust the query planner to assemble whatever you ask for later. DynamoDB inverts that. You model the reads you already know you'll make, and the keys exist to serve them.

There is no join engine and no planner picking a strategy at runtime. A Query reads one partition along one key, and that is the entire performance contract. So you design keys for known access patterns, not for a tidy schema.

AWS says it plainly in its best-practices guide: "you shouldn't start designing your schema until you know the questions it will need to answer."

This guide walks the whole process on one domain: a multiplayer game leaderboard tracking players, the matches they play, and their per-season ranking. We go from a list of questions to a working key schema.

How do you model data in DynamoDB?

Model the reads first, not the tables. List every query the app makes, then design a partition key and sort key so each question resolves to a single Query or GetItem. Co-locate items that are read together, range over values in the sort key, and add a GSI for any access pattern the base table can't serve.

List the reads first, not the tables. The questions are the spec; the nouns are a distraction.
Each question must be one Query or GetItem. If a question needs a Scan, the model is wrong.
Co-located items share a partition key; anything you range over goes in the sort key.
A question the base table can't answer gets a GSI — never a Scan with a filter.

Step 1 — Frame the problem as questions, not tables

Resist the urge to draw players, matches, and scores tables. That instinct is the SQL habit, and here it's wrong. Instead write down every read the app actually performs. For our leaderboard:

Fetch one player's profile by id.
List a player's recent matches, newest first.
Show the top N players for a given season, ranked by rating.
Look up a player by their public handle (e.g. for a profile URL).

These four questions — not the nouns — are the spec. Each one must resolve to a single Query (or GetItem), because that's the only access shape DynamoDB serves cheaply at scale.

If a question can only be answered by scanning the table, the model is wrong, and you'll feel it in latency and cost — see Query vs Scan for why a Scan is the footgun to avoid.

The whole method is a short, ordered pipeline you run once per domain:

Each step below maps onto one box: list, enumerate, design keys, add indexes for the rest, then validate.

Step 2 — Understand the primitives you're modeling with

A table has a partition key (PK) that picks which physical partition an item lives on, and an optional sort key (SK) that orders items within that partition.

The AWS core-components docs call the pair the item's primary key. A Query always targets exactly one PK value and can range-scan or filter the SK — that's the whole toolkit.

This single-partition design is what lets DynamoDB deliver the predictable, low-latency, horizontally partitioned reads first described in the 2007 Amazon Dynamo paper.

Two consequences drive every decision below:

Items that are read together should share a partition key so one Query returns them in a single billed request.
Anything you want to range over (recent matches, top ratings) must live in the sort key, because that's the only attribute Query can order and bound.

When a question needs a different access shape than the base table provides, you add a Global Secondary Index — a re-projection of the table under a different PK/SK.

(For GSI versus Local Secondary Index, see GSI vs LSI.)

Step 3 — Design the keys, one question at a time

We use a single table with generic, overloaded key attributes — the single-table approach — because a player and their matches are read together.

Invent your own prefixes; here PLAYER#, MATCH#, and SEASON# tag the entity type inside otherwise-generic keys.

Questions 1 and 2 (profile + recent matches) share a partition, so both hang off the same PK:

partitionId	rangeId	attributes
PLAYER#u8231	PROFILE	handle, region, createdAt
PLAYER#u8231	MATCH#2026-06-23T14	result=win, ratingDelta=+18, mapId
PLAYER#u8231	MATCH#2026-06-23T11	result=loss, ratingDelta=-15, mapId

Query partitionId = "PLAYER#u8231" returns the profile and every match in one read. For the profile alone, GetItem.

For recent matches, rangeId begins_with "MATCH#" with ScanIndexForward = false walks them newest-first — the timestamp in the sort key does the ordering for free.

Questions 3 and 4 can't be answered from that partition — they pivot on season rank and on handle, neither of which is the base PK. Each gets a GSI.

We add two pairs of generic index attributes — seasonPartition / seasonSort for the rank index and handlePartition / handleSort for the handle index — populated on the same profile item (the one written in Step 3, now shown with its index attributes filled in):

partitionId	rangeId	seasonPartition	seasonSort	handlePartition	handleSort
PLAYER#u8231	PROFILE	SEASON#2026-Q2	RATING#1842	HANDLE#nighthawk	PLAYER#u8231

Now Query the season index WHERE seasonPartition = "SEASON#2026-Q2" with ScanIndexForward = false returns players ranked by rating — that's the leaderboard.

A second index keyed on handlePartition = "HANDLE#…" resolves a public handle to a player id in one read. One physical table, four single-Query access patterns.

A zero-padding note on RATING#1842: DynamoDB sorts sort keys lexicographically, not numerically, so a rating must be zero-padded to a fixed width (RATING#01842) or 9 would sort after 1000. This is a classic modeling gotcha worth getting right up front.

Step 4 — Validate the model in DynoTable

A key schema only earns trust when you watch a real Query return exactly the items you expected and nothing more.

Open the table in DynoTable, run the leaderboard query against the season index, and confirm the partition comes back ranked and bounded — no Scan, no client-side sorting.

When you build the condition expressions for these queries — the begins_with, the seasonPartition = :p, the placeholder :p binding — let the DynamoDB Expression Builder do it.

It generates the KeyConditionExpression, the ExpressionAttributeNames, and the ExpressionAttributeValues, so a reserved word like result or a typo'd placeholder never silently breaks a read.

Step 5 — Pitfalls and next steps

A few traps to check before you ship the model:

Don't model relationships you never read together. A GSI per question is cheap; a wasted GSI is recurring cost. Add indexes from the question list, not speculatively.
Watch partition heat. If one PK (a celebrity player, a single hot season) absorbs most traffic, that partition can throttle. Spread writes with a suffix shard when a key is provably hot — AWS covers this under partition-key design.
Zero-pad and ISO-8601 everything numeric or temporal in a sort key, so lexicographic ordering matches the order you mean.
A new question = a new key or index, never a Scan. When a genuinely new access pattern appears later, extend the keys; don't paper over it with a filter.

Model the questions first, design keys so each is one Query, then prove it.

For a head start on the middle step, the free Single-Table Design tool turns a list of access patterns like this one into a PK/SK/GSI plan, with example items and cost hints.

Try DynoTable to browse your table, run these queries against the base table and the GSIs side by side, and watch the access patterns you designed return exactly what you planned. And for the question you didn't model, its SQL Workbench runs real JOINs, GROUP BY, and aggregates client-side.