dynamodump: mysqldump-shaped backups for DynamoDB

mysqldump habits applied to DynamoDB tables

The project describes itself as a simple backup and restore script for Amazon DynamoDB using the AWS SDK for Python (boto3), built to work similarly to mysqldump. That analogy is the right lens, because the command names, the mode flag, and the file layout all borrow from the MySQL tool rather than from a cloud backup service.

The scope is stated in one sentence that is worth quoting, because it is the boundary of the tool: it is suitable for DynamoDB usages of smaller data volume which do not warrant the usage of AWS Data Pipeline for backup/restores/empty. So the audience is a team that wants a script they can run from a laptop or a cron job, and not a team looking for continuous replication.

The mechanics follow from the same design. There is one console entry point, registered in setup.py as dynamodump=dynamodump.dynamodump:main, and one mode flag that selects backup, restore or empty. Installation is a single pip command, and the package lives on PyPI as dynamodump.

The tool also runs against local instances, which the README notes as tested with DynamoDB Local. That matters more than it first appears, because it means the same backup command can be exercised in development against a local copy of a table before anyone points it at a production region.

Three modes, and a confirmation you have to opt out of

The mode switch is the centre of the interface: -m {backup,restore,empty} picks the operation, and the same flag runs all three. Backup writes out a table, restore reads it back, and empty does the third thing that a dump tool needs, clearing a table without necessarily removing it.

Destructive operations are fenced. The --noConfirm option is described as don't ask for confirmation before deleting existing schemas, and the README calls out a change made in v1.2.0: --noConfirm is required to perform data restores involving deletions without any confirmation. In other words, since that version a scripted restore that overwrites or deletes data will not run silently, and a human or an automation wrapper has to add the flag deliberately. That is a small detail with a real effect on how you write your runbooks, and it is the kind of change that is easy to miss if you read only the help output.

The empty mode is worth thinking about separately, because it is the one operation with no restore path attached to it. A backup you can restore from is recoverable; an empty you cannot undo. The README does not describe a separate safeguard for that mode beyond the general confirmation handling.

The same confirmation logic is why the unattended usage section in the README is short. It documents the v1.2.0 requirement and nothing else, so any script that drives dynamodump has to carry the flag itself rather than relying on a prompt.

Wildcards, prefixes, and tags decide which tables move

Table selection is where this tool most resembles mysqldump. The --srcTable option takes a source table name, and the help text spells out the pattern syntax: use tablename* for wildcard prefix selection or * for all tables. The --destTable option is optional and defaults to the source, so the common case is a straight copy of one table onto itself.

The wildcard has a companion for tables whose names share a prefix. The README's own example set uses a production- prefix, and --prefixSeparator overrides the default separator, with --noSeparator to turn the separator off entirely for backup wildcard searches. The cross-environment case is supported directly: a backup of production* can be restored into development*, with the destination prefix given to --destTable.

There is a second way to pick tables, and it does not combine with the first. The --tag option takes a KEY=VALUE pair to identify tables to back up, and the help marks it mutually exclusive with srcTable. That is a genuine design decision rather than a documentation quirk: one run selects tables by name pattern, the other selects them by a tag on the table, and the tool refuses to accept both at once.

The mode list also includes empty, which takes the same selectors. So a wildcard selection is not limited to backup, and a run of -m empty with a wildcard needs the same care as a wildcard restore.

Schema, data, and throughput are separate switches

The tool separates the parts of a table that a mysqldump user would think about as structure and rows, and adds a third dimension that has no mysqldump equivalent: capacity.

--schemaOnly backs up or restores the schema alone and does not touch data, and it can be combined with either the backup or the restore mode. --dataOnly is the mirror image, restoring data without deleting and recreating the schema. The README documents one interaction explicitly: --schemaOnly cannot be used with --dataOnly. That pairing is what makes the tool usable in two different situations, a schema change that must be rolled forward to another environment, and a data refresh where the table structure is already correct and recreating it would be wrong.

Capacity is handled by --readCapacity for the table being read and --writeCapacity for the table being written to, where the write capacity defaults to 25, and by --skipThroughputUpdate to leave throughput values alone. The billing mode is set with --billingMode, which takes PROVISIONED or PAY_PER_REQUEST and defaults to PROVISIONED. A restore into a table in on-demand mode, or into one with a different capacity than the source, is exactly the case these flags exist for.

Two more controls shape the size of a run. --limit stops the backup once a given number of items has been backed up, and -f takes a JSON file whose keys are FilterExpression, ExpressionAttributeNames and ExpressionAttributeValues, which is how you narrow a backup to a subset of items. Read together with the read and write capacity flags, they show the design: the tool walks items one at a time, and every one of these options exists to keep that walk cheap.

Where the files land: the dump directory and an existing S3 bucket

By default the backup files are stored in a dump subdirectory, and restores are read back from that same place. The --dumpPath option changes the directory that is used to place and search for DynamoDB table backups, so a scheduled job can point it at a mounted volume or a path on a backup host.

For anything longer lived, the -b option names an S3 bucket in which to store or retrieve backups, and the help text is explicit about one requirement: the bucket must already exist. dynamodump will not create it, which is one fewer thing for the tool to get wrong with your credentials, and one more thing for you to set up.

Compression is a separate decision from the destination. The -a option takes zip or tar and is described as the type of compressed archive to create, and if it is unset no archive is created at all. That means the same run can leave plain files in the dump directory or produce a single archive, depending on the flag, and a restore has to point at a dump directory shaped the way the backup wrote it.

The AWS examples in the README are deliberately minimal, with a single table backup and restore in us-west-1, then the same two commands with a production* wildcard, and then the cross-environment variant that restores production* into development*. The example for backing up every table and restoring data only is cut off in the README text, so the exact command line for that case is not documented there, even though --dataOnly itself is described in the help output.

Docker and DynamoDB Local make the same script testable

The project ships a container image, and the README gives the one-line check for it:

docker run --rm -it bchew/dynamodump -h

The same images are published in three places, so a team with registry restrictions can pick one it already uses. The README lists the two additional image references and links to the three registries:

public.ecr.aws/bchew/dynamodump
ghcr.io/bchew/dynamodump

The second half of the story is local DynamoDB, and the repository carries a compose file for it. It defines a single service built from the amazon/dynamodb-local image, running with the -sharedDb and -inMemory flags, and publishing port 8000:

version: '3.8'
services:
  dynamodb-local:
    command: "-jar DynamoDBLocal.jar -sharedDb -inMemory"
    image: "amazon/dynamodb-local:latest"
    container_name: dynamodb-local
    ports:
      - "8000:8000"

Against that local instance, the tool needs the four options the help output marks as required only for local use: --host, --port, --accessKey and --secretKey. The region option is still needed, and the help text notes that any region can be used for local testing, which is a detail that saves a confusing error message.

The in-memory flag matters for how you use this. A local DynamoDB started with -inMemory starts empty every time, so a backup and restore cycle against it is a rehearsal of the commands, not a test of a copy of your data. The repository also has a .devcontainer/ directory, which suggests the same local setup is meant to be used from inside a development container.

Pinned dependencies, an MIT licence, and a release gap

The packaging is minimal and explicit. setup.py declares python_requires=">=3.10" and pins its two runtime dependencies exactly, install_requires=["boto3==1.43.107", "six==1.17.0"], and requirements.txt repeats the same two lines. The build itself is declared in pyproject.toml with setuptools and wheel, and the package layout is a single dynamodump package with one console script.

Exact pins are a deliberate choice with a practical effect. A backup tool that runs in a cron job wants the same boto3 behaviour on every run, and pinning to a specific boto3 build is how you get that. The cost is that the pins have to be refreshed by hand, which is presumably why the repository carries a renovate.json configuration file alongside the dependency files.

The licence is MIT, with a LICENSE file in the repository root, which leaves you free to wrap the tool in your own scripts.

On maintenance, the numbers are modest but recent. The last push was on 2026-10-02, and the repository is not archived. The published releases are v1.11.0 on 2025-10-02, v1.11.1 on 2025-11-07, and v1.10.1 before that on 2025-03-04, and setup.py still carries version="1.11.1", so the packaged version matches the newest tag. That leaves a stretch of source activity after the last release, and no scheduled release cadence that you can plan around.

The quality tooling around the code is worth a mention for anyone who intends to patch it. The top-level directory holds a Dockerfile, a docker-compose.yml, a.devcontainer/ directory, tests/, a test.sh, requirements-dev.txt, and configuration for flake8, pre-commit and SonarCloud, while the README badges point at separate workflows for builds, tests, linting, Docker images and CodeQL analysis.

Editorial conclusion

Use dynamodump when you want a mysqldump-style workflow for a set of DynamoDB tables, especially when the tables are small enough that a full scan and restore is acceptable, and when you need the same script to run against DynamoDB Local during development. Do not use it as a point-in-time recovery system for a busy production table, because the README limits it to smaller data volumes and the tool works by reading and writing items rather than by taking a table snapshot. Before adopting it, check the pinned boto3 version in setup.py, confirm your IAM principal can create the destination table and write its items, and decide where the dump directory lives, since the default is a local dump subdirectory and the S3 bucket you pass must already exist.

Frequently asked questions

Official sources

1. bchew/dynamodump on GitHub
2. Issues
3. License: MIT
4. README
5. Releases