Cannot do operations on a non-existent table (DynamoDB Local)

TL;DR — This is DynamoDB Local's wording of ResourceNotFoundException, and the trap is that "non-existent" is scoped to the database file this instance opened for your current access key + region. Without -sharedDb, Local keeps a separate table set per credentials/region combo — so the table you created with the CLI can be invisible to your app. Run Local with -sharedDb (or pin identical dummy credentials + region everywhere), and remember -inMemory starts empty on every restart.

What it means

ResourceNotFoundException: Cannot do operations on a non-existent table

Your request reached a running DynamoDB Local, which looked for the table and didn't find it — in the database it's using for your request's identity. Real AWS words the same failure differently (Requested resource not found), so this exact message is a strong hint you're talking to an emulator.

Why it happens

  • Credential/region split-brain (the classic). Without -sharedDb, DynamoDB Local names its database file after the access key ID and region of each request. Your CLI (--profile with key local, region us-east-1) and your app (key fake, region local) therefore see two different table sets — each created the table "for itself".
  • -inMemory + a restart — in-memory mode keeps nothing on disk; every restart is a blank database.
  • A fresh container without a volumedocker run amazon/dynamodb-local starts empty; tables from the previous container are gone unless you mounted -dbPath storage.
  • The table genuinely wasn't created — setup scripts didn't run, or created it against a different port/instance.
  • Same code pointed at real AWS vs Local — the table exists in the cloud but not in the emulator (or vice versa).

How to fix it

  1. See what THIS identity sees — list tables with exactly the credentials/region/endpoint your app uses:

    AWS_ACCESS_KEY_ID=local AWS_SECRET_ACCESS_KEY=local \
    aws dynamodb list-tables --endpoint-url http://localhost:8000 --region us-east-1

    If the table's missing here but exists "somewhere", it's the scoping.

  2. Run Local with -sharedDb so every client shares one database regardless of credentials/region:

    java -Djava.library.path=./DynamoDBLocal_lib -jar DynamoDBLocal.jar -sharedDb
    # docker: docker run -p 8000:8000 amazon/dynamodb-local -jar DynamoDBLocal.jar -sharedDb
  3. Or pin one identity everywhere — the same dummy accessKeyId, secretAccessKey, and region in the CLI profile, SDK client config, and test setup.

  4. Persist across restarts — drop -inMemory, set -dbPath, and (in Docker) mount it as a volume.

  5. Create tables in setup — for tests, create the table (and wait for it) in the suite's bootstrap so a fresh instance is never a surprise.

The scoping problem is much easier to see than to deduce — the DynoTable desktop app connects to DynamoDB Local and shows exactly which tables an endpoint + credential combo can see, so the split-brain is visible in one glance. Prepping seed data? The DynamoDB JSON converter turns plain JSON into typed items.

FAQ

Why does DynamoDB Local say the table doesn't exist when I just created it? Without -sharedDb, DynamoDB Local keeps a separate database file per access key ID and region, so the table you created with the CLI can be invisible to your app if their credentials or region differ. Run Local with -sharedDb or pin identical dummy credentials and region everywhere.

Why did my DynamoDB Local tables disappear after a restart? In -inMemory mode nothing is kept on disk, so every restart is a blank database. A fresh Docker container without a mounted volume starts empty too. Drop -inMemory, set -dbPath, and mount it as a volume to persist tables.

References

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

Work with DynamoDB without the Console

DynoTable is a fast desktop client for DynamoDB — browse tables, run SQL-style queries, and edit items locally.