DynoTable

DynamoDB ResourceInUseException

TL;DR — You tried a table operation on a table that already exists or is still transitioning (CREATING / UPDATING / DELETING). Check the table's status first, or make the create idempotent by ignoring "already exists".

What it means

ResourceInUseException: Table already exists: <name>
ResourceInUseException: Attempt to change a resource which is still in use: Table is being created/deleted

# what the engine actually returns, reproduced against DynamoDB Local:
ResourceInUseException: Cannot create preexisting table

Control-plane operations (CreateTable, DeleteTable, UpdateTable) require the table to be in a compatible state. This error means it isn't — either it already exists, or it's mid-transition and DynamoDB won't accept another operation until it settles to ACTIVE. DynamoDB returns it with HTTP status 400, and it's not retryable as-is — retrying the identical request fails until the state changes (wait for the transition to finish, or change the request).

Why it happens

  • Re-running CreateTable for a table that already exists (a repeated migration/deploy, tests that don't clean up).
  • Operating during a transition — creating an index, deleting, or updating while the table is still CREATING/UPDATING.
  • A race — two processes creating the same table concurrently.

How to fix it

  1. Check status before acting. DescribeTable → only proceed when TableStatus is ACTIVE; use a waiter (waitUntilTableExists) to block until it settles.
  2. Make create idempotent. Catch ResourceInUseException on CreateTable and treat it as success (the table you wanted exists).
  3. Serialize table ops in tests/migrations so two don't run at once; clean up test tables in teardown.

Example

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

const client = new DynamoDBClient({});

try {
  await client.send(new CreateTableCommand(tableDef));
} catch (err) {
  if (!(err instanceof ResourceInUseException)) throw err;
  // Table already exists — that's fine, carry on.
}

FAQ

What does ResourceInUseException mean in DynamoDB? A control-plane operation (CreateTable, DeleteTable, UpdateTable) targeted a table that already exists or is still transitioning through CREATING, UPDATING, or DELETING. DynamoDB won't accept another operation until the table settles to ACTIVE.

How do I make CreateTable idempotent? Catch the ResourceInUseException and treat it as success — the table you wanted exists. Alternatively check DescribeTable first and only create when the table is absent, using a waiter like waitUntilTableExists to block until it settles.

Path in DynoTable

When a migration re-runs CreateTable, DynoTable shows the table as soon as it exists — open it with ⌘K → Open table by name while your script retries. Table settings on an open tab displays TableStatus (CREATING, UPDATING, ACTIVE) so you can wait for ACTIVE before issuing the next control-plane change. For local iteration, point a Local profile at http://localhost:8000 (Running DynamoDB Local) and use the DynamoDB JSON converter to load seed items once the table settles.

For cloud tables stuck in UPDATING, Table settings also lists in-flight GSI backfills — wait for ACTIVE on every index before the next UpdateTable in your deploy script.

Against DynamoDB Local, the same ResourceInUseException appears when a test re-runs CreateTable against an in-memory instance that never cleared — treat Local like cloud and catch the error or wait for ACTIVE.

Sources

Work with DynamoDB without the Console

A fast DynamoDB desktop client that runs the real SQL DynamoDB can’t — JOINs, GROUP BY, aggregates — with visual editing and an AI agent on your own Bedrock keys.

DownloadSee pricing

Free 30-day trial, no credit card — then the Free plan with no time limit.