DEV Community: DynoTable

From the Dynamo Paper to DynamoDB

DynoTable — Sun, 05 Jul 2026 10:07:42 +0000

The 2007 "Dynamo: Amazon's Highly Available Key-value Store" paper and the
DynamoDB you call today share a name and a goal — predictable performance at any
scale — but they are not the same system. The paper described an internal,
eventually-consistent store you ran yourself. DynamoDB is a managed service that
kept the lessons and threw out most of the machinery.

Is DynamoDB based on the Dynamo paper?

Partly. DynamoDB takes its name and core goals — predictable performance and high availability at scale — from the 2007 Amazon Dynamo paper, and it kept the partition-key hashing idea almost verbatim. But it is a different, managed system: the paper's vector clocks, gossip membership, and tunable read/write quorums are gone, replaced by AWS-owned internals.

The paper solved availability, not ergonomics. Its job was to never reject a write during a holiday-traffic spike, even at the cost of returning a stale read.
DynamoDB kept the shape, replaced the internals. Partitioned by a hash of the key, replicated across AZs, scaled horizontally — but the conflict-resolution guts (vector clocks, gossip, read-repair) are gone.
You no longer tune the knobs. N, R, and W from the paper became one choice: ConsistentRead true or false. AWS owns the rest.
The mental model still pays off. Knowing the lineage explains why a Scan is expensive and why a GSI read can lag — both fall out of the original design.

What the paper was actually solving

Amazon's shopping cart could not go down. A relational database that refused
writes under load — or blocked on a failed replica — was unacceptable. The 2007
Dynamo paper chose availability over consistency: always accept the write,
reconcile disagreements later. That trade is the root of everything below.

To do that without a single master, Dynamo had to answer two questions on its own:
where does a key live, and how many copies must agree before a read or write counts?

Consistent hashing: where a key lives

The paper placed every node on a hash ring. A key's position is the hash of its
key; it's owned by the next node clockwise, and replicated to the following N-1
nodes. Adding or removing a node only reshuffles its neighbors' keys — not the
whole dataset. That's consistent hashing, and it's the one idea DynamoDB kept
almost verbatim.

DynamoDB still hashes your partition key to decide which physical partition stores
the item. Pick a low-cardinality partition key — say STATUS with two values —
and every item with the same value lands in the same partition. That's the hot partition footgun, and it's a direct consequence of the ring: the hash sends
identical keys to identical homes.

Quorum: how many copies must agree

The paper's second knob was a quorum. With N replicas, a write succeeds once
W of them ack, and a read consults R of them. Set R + W > N and any read
overlaps at least one node holding the newest write — strong consistency. Set them
lower and you trade freshness for speed and uptime.

Dynamo ran "sloppy" quorums: if a target node was down, the write went to a
stand-in and was handed back later (hinted handoff). Conflicting versions were
tagged with vector clocks and reconciled by the application on read.

What DynamoDB kept versus changed

DynamoDB inherited the goals and the partitioning, then deleted the parts that
made the original hard to operate.

Concern	2007 Dynamo paper	DynamoDB today
Key placement	Consistent hashing ring	Hash of partition key → managed partition
Replication	`N` nodes, you choose	3 copies across AZs, fixed by AWS
Consistency knobs	`R`, `W` quorum tuning	One flag: `ConsistentRead`
Conflict resolution	Vector clocks, app-side merge on read	None needed in-Region — writes serialize through a leader replica; last-writer-wins only across Regions in global tables
Membership	Gossip protocol between peers	Fully managed; invisible to you
Multi-key ops	None — pure key-value	`Query`, GSIs, transactions layered on top

The paper's API was two calls: get(key) and put(key, value). DynamoDB added a
sort key, indexes, and queries on top of the same key-value core — which is why a
Query is cheap (one partition) and a Scan is not (it walks every partition the
ring ever created).

How a write travels, then and now

The flow below contrasts the paper's quorum write with DynamoDB's managed one. The
shape rhymes; the responsibility moved from your code to AWS.

Diagram: view on dynotable.com

In the paper you owned the quorum math and the merge; in DynamoDB that whole lower
half is managed, and you only choose ConsistentRead per request.

Where the lineage leaks into your code

The eventual-consistency default is the paper showing through. A global secondary
index is replicated asynchronously, so a freshly written item can be missing from
the index for a moment — the same "reconcile later" bargain, just at the index
layer. See GSI vs LSI for when that lag matters.

You buy back strong consistency two ways. Use ConsistentRead: true on a base-table
read (it routes to the leader copy), or guard a write with a ConditionExpression
so it only lands if the item's current state matches. Sketch one in the
DynamoDB expression builder — for example
attribute_not_exists(PK) to make a PutItem an insert-only operation, the
modern stand-in for the paper's conflict detection.

The one thing to remember

The paper optimized for never saying no to a write. DynamoDB inherited that bias,
which is why its defaults favor availability and why strong reads cost more. Model
your keys for single-partition Querys, as in single-table design,
and reach for a Scan only when you truly must — the ring
makes a full table walk as expensive as it sounds.

Try DynoTable to browse your tables and their GSIs, then run JOINs and
GROUP BY over your own data in the SQL Workbench.

DynamoDB Data Types

DynoTable — Sun, 05 Jul 2026 10:07:41 +0000

Every DynamoDB attribute is tagged with a one- or two-letter type code in the wire
format. Knowing the set matters because the type drives both how a value is stored
and how it counts toward an item's size.

What data types does DynamoDB support?

DynamoDB supports ten data types across three categories. Scalars are String (S), Number (N), Binary (B), Boolean (BOOL), and Null (NULL). Documents are Map (M) and List (L), which nest other types. Sets are String Set (SS), Number Set (NS), and Binary Set (BS) — unordered, homogeneous, and non-empty. Only S, N, and B can be a key.

Code	Type	Category	JSON / JS equivalent	Example (DynamoDB-JSON)
`S`	String	Scalar	string	`{"S": "Ada"}`
`N`	Number	Scalar	number	`{"N": "37"}`
`B`	Binary	Scalar	Uint8Array / base64	`{"B": "ZGF0YQ=="}`
`BOOL`	Boolean	Scalar	boolean	`{"BOOL": true}`
`NULL`	Null	Scalar	null	`{"NULL": true}`
`M`	Map	Document	object	`{"M": {"k": {"S": "v"}}}`
`L`	List	Document	array	`{"L": [{"N": "1"}]}`
`SS`	String set	Set	— (no JSON type)	`{"SS": ["a", "b"]}`
`NS`	Number set	Set	—	`{"NS": ["1", "2"]}`
`BS`	Binary set	Set	—	`{"BS": ["ZA=="]}`

Scalars

S — string (UTF-8; sized by its byte length, not character count).
N — number, sent as a string for precision; up to 38 digits.
B — binary, sent base64-encoded.
BOOL — true / false.
NULL — an explicit null marker.

Documents

M — map (object). Nested attributes each keep their own type tag.
L — list. Elements may be mixed types.

{"profile": {"M": {"name": {"S": "Ada"}, "age": {"N": "37"}}}}

Sets

SS — string set, NS — number set, BS — binary set.

Sets are unordered, homogeneous, and can't be empty. Crucially, plain JSON has
no set type — an array round-trips as a list (L), never an SS/NS. That's a
real conversion limitation, not a bug; see the
DynamoDB-JSON converter note.

Which types can be a key?

Partition and sort keys — on the table and on any index — must be a scalar,
and only S, N, or B. You can't key on a boolean, set, map, or list. Model a
"composite" key by concatenating values into one S (e.g. ORDER#2026#42).

Limits worth knowing

An item maxes out at 400 KB — every attribute name plus value, including nested ones.
Numbers carry up to 38 digits of precision (positive or negative).
Maps and lists nest up to 32 levels deep.
Sets are non-empty and homogeneous — no empty set, no mixing S and N.

Why the type affects cost

Item size is the sum of attribute-name bytes plus value bytes, and each type sizes
differently — numbers are compacted, booleans and nulls are 1 byte, maps and lists
add per-element overhead. That size rounds up to read/write
capacity units. Measure a real item with the
item-size calculator.

Do it in DynoTable

The set-vs-list distinction above is the thing tooling usually hides. DynoTable's
item editor makes it explicit with a format toggle:

Plain JSON — primitives stay plain ("age": 30), but sets keep their type wrapper so they survive the round-trip: "tags": { "SS": ["a", "b"] }, "scores": { "NS": ["1.5", "2.5"] }. This is the readable form for everyday editing.
DynamoDB JSON — the canonical AWS marshalled form, where every value carries its type tag: "age": { "N": "30" }, "name": { "S": "alice" }.

Switching between them shows you exactly how each scalar, document, and set type
is represented on the wire — and because the set types have no plain-JSON
equivalent, the toggle is the only way to author an SS/NS/BS by hand without
hand-marshalling the whole item.

Try DynoTable to see every attribute's type and the live byte count
as you edit an item — and to filter or aggregate across typed attributes in the
SQL Workbench, which reads each type tag for you. To convert a marshalled blob
without the app, the DynamoDB-JSON converter
does the same round-trip in the browser.

How to Copy a DynamoDB Table to Another Account or Region

DynoTable — Sat, 04 Jul 2026 10:43:21 +0000

DynamoDB has no one-click "copy table" command — not in the AWS CLI, not in the
console. Copying or migrating a table across accounts or regions means picking one of
four approaches, each with different cost, downtime, and fidelity tradeoffs. This guide
covers all four, plus the operational gotchas that bite in production.

How do I copy a DynamoDB table to another account or region?

There's no native copy-table command. Pick one of four approaches: a Scan + BatchWriteItem script for small one-off copies, an S3 export-then-import for large tables, AWS Backup copy + restore for cross-account moves with full fidelity, or global tables for ongoing live replication. Each restore or import creates a new table.

Situation	Best approach
Small table, one-off, full control	Scan + BatchWriteItem script
Large table, can tolerate a snapshot	S3 export → import (creates new table)
Cross-account / cross-region with restore	AWS Backup copy + restore
Ongoing live replication (not a one-time copy)	Global tables

No approach is universally "right" — it depends on table size, whether you need a
point-in-time snapshot or live data, and whether the destination is a new or existing
table.

Approach 1: Scan + BatchWriteItem (the script)

The lowest-tech option: read every item from the source with Scan, write it to the
destination with BatchWriteItem. Works cross-account and cross-region as long as your
script holds credentials for both sides (or assumes a role in the target account).

# Sketch — read source, write target (pseudo; use the SDK in real life)
aws dynamodb scan --table-name SourceTable --region us-east-1 \
  > items.json
# transform Items[] into BatchWriteItem RequestItems, then:
aws dynamodb batch-write-item --request-items file://batch.json \
  --region eu-west-1

The gotchas are real and easy to miss:

BatchWriteItem caps at 25 items or 16MB per call — you must chunk, and a single call can return unprocessed items you have to retry with exponential backoff (API reference).
Writes consume write capacity. On a provisioned target you'll hit ProvisionedThroughputExceededException fast; on-demand absorbs more but still caps each partition at a hard 1,000 WCU / 3,000 RCU limit. Size the write load against the destination's capacity before you start.
Scan reads the whole table and meters every item — the classic Query-vs-Scan cost. A big table also means paginating through LastEvaluatedKey; see pagination.
It's not atomic. Items written while the scan is in flight can be missed — you only get a consistent snapshot if the source is quiescent.

Best for small tables or when you need to transform/filter during the copy.

Approach 2: Export to S3, then import to a new table

For large tables, DynamoDB's managed export to S3 plus import from S3 avoids
hammering your capacity at all.

Export snapshots the table to an S3 bucket
(how it works):

Requires point-in-time recovery (PITR) enabled on the source table.
Does not consume read capacity and has no impact on table performance — it reads from continuous backups, not the live table.
Outputs DynamoDB JSON or Amazon Ion format. (The DynamoDB-JSON wire format is what lands in S3, type tags and all.)
Can write to an S3 bucket owned by another account and in a different region.
Supports full and incremental exports (incremental export GA, Sept 2023).

Import then builds a fresh table from that S3 data
(how it works):

Imports into a brand-new table only — you cannot import into an existing table.
Does not consume write capacity on the new table.
Accepts CSV, DynamoDB JSON, or Amazon Ion (optionally GZIP/ZSTD compressed).
The source S3 bucket may be in another account or another region.
You can define secondary indexes at import time, queryable as soon as the import completes.

Warning

Import overwrites duplicate keys silently — if the source has non-unique primary
keys, only the last write survives, and the processed-item count won't match the final
table count. Validate key uniqueness in the source first.

This is the cleanest path for a large cross-account/cross-region migration where a
point-in-time snapshot (not live data) is acceptable.

Approach 3: AWS Backup copy + restore

If you already use AWS Backup, it copies recovery points across accounts and regions
(cross-account migration guide):

Back up the source table into a backup vault.
Copy the backup to a vault in the target account/region.
Restore it to a new table in the target.

Key constraints:

Cross-account copy requires both accounts to be in the same AWS Organization.
Restore always creates a new table — you can't restore over an existing one.
Global secondary indexes are preserved by default (exclude some or all to save on restore time/cost); you can't add new indexes at restore.
Encryption gotcha: to keep the same KMS key on a cross-region restore you need a multi-region key; for cross-account you must share the key with the target account. AWS-owned and AWS-managed keys can't be shared or made multi-region (restore encryption notes).

Tip

For a one-off cross-region restore with table-setting changes, AWS Backup is more
operationally complete than a hand-rolled script — it carries GSIs, encryption, and
metadata, not just item data.

Approach 4: Global tables (live replication, not a one-time copy)

Global tables replicate a table across regions — and now optionally across accounts
(multi-account GA, Feb 2026) —
continuously. Any replica serves reads and writes (multi-active), with asynchronous,
last-writer-wins replication
(global tables docs).

This is not a "copy and walk away" tool — it's ongoing replication. Use it when you
want the destination region to stay in sync indefinitely (DR, low-latency local reads),
not for a clean one-time migration. Add a region to an existing table and DynamoDB
backfills the existing data into the new replica.

Note

Global tables default to multi-region eventual consistency (MREC); a strong-consistency
mode (MRSC) exists but is same-account only. If you treat a global-table replica as a
migration target and cut over immediately, replication lag can mean the new region hasn't
caught up yet.

Operational gotchas (all approaches)

GSIs aren't free to recreate. A scan+write copy doesn't carry indexes — you define them on the target and they backfill (and cost) separately. Plan your GSI vs LSI layout on the destination up front; LSIs can only be created at table-creation time (LSI docs).
Capacity mode doesn't transfer. The new table starts with whatever mode you set, not the source's. Estimate the write load before a scan+write copy — size a representative item with the item-size calculator and multiply by item count to ballpark WCUs.
TTL, streams, auto-scaling, and tags are table settings, not data — none of the copy methods carry all of them. Re-apply them on the target.
DynamoDB JSON ≠ plain JSON. Exports and scans emit type-tagged DynamoDB-JSON; if you're transforming en route, the DynamoDB JSON converter handles the marshalling.

FAQ

Is there an AWS CLI command to copy a DynamoDB table?
No. There's no native copy-table command. You combine scan + batch-write-item,
or use the managed export/import or AWS Backup features.

How do I copy a DynamoDB table to another account?
Three options: a scan+write script with credentials for both accounts, an S3
export/import (the bucket can be cross-account), or AWS Backup copy+restore (both accounts
must be in the same AWS Organization).

How do I copy a DynamoDB table to another region?
S3 export/import and AWS Backup both support cross-region. For ongoing cross-region
sync rather than a one-time copy, add a global-table replica in the target region.

Does copying a table copy its indexes?
S3 import and AWS Backup restore let you keep/define secondary indexes; a scan+write
script does not — you create indexes on the target yourself, and they backfill separately.

Can I import into an existing DynamoDB table?
No. DynamoDB's S3 import and AWS Backup restore both create a new table. To merge
into an existing table, use a scan+write script.

A GUI makes the cutover sane: browse both source and target side by side, verify item
counts and a few sample records after the copy, and run ad-hoc checks without writing a
scan script. Download DynoTable to inspect tables across accounts and
regions during a migration.

How to Connect to DynamoDB Local and LocalStack

DynoTable — Sat, 04 Jul 2026 10:41:19 +0000

You have a local DynamoDB running and your code talks to it fine — but you want
to see the tables, not write a scan script every time. Connecting a client to
a local endpoint is two changes: point at the right URL, and hand it throwaway
credentials. The details below are where people get stuck — region namespacing,
the alphanumeric-key rule, and the 8000 vs 4566 port split.

DynamoDB Local vs LocalStack: what you're connecting to

Both give you a DynamoDB API on localhost with no AWS account, but they're
different things:

DynamoDB Local is the downloadable DynamoDB engine in a single process — AWS ships it as a JAR and a Docker image (amazon/dynamodb-local). It's DynamoDB and nothing else. Default port 8000 (AWS docs). See running DynamoDB Local with Docker.
LocalStack emulates a stack of AWS services behind one endpoint. Its DynamoDB is itself powered by DynamoDB Local, but everything goes through LocalStack's single edge port 4566.

So the only practical difference for connecting is the endpoint URL: :8000 for
standalone DynamoDB Local, :4566 for DynamoDB-via-LocalStack. Everything else —
the API, the credentials trick, the GUI config — is identical.

The endpoint + dummy-credentials setup that trips everyone up

The AWS SDKs and CLI require an access key and a region even when talking to a
local endpoint — but those values don't have to be real. AWS's own docs say
these values "don't have to be valid AWS values to run locally"
(AWS docs).

Two gotchas that aren't obvious:

The region/access-key silently namespaces your data. Without the -sharedDb flag, DynamoDB Local writes a separate myaccesskeyid_region.db file per access-key-ID + region combination — AWS's exact naming. Connect with a different key or region than your app used and your tables look like they've vanished; they're just in another file. Run with -sharedDb (one shared-local-instance.db for every client) or match the exact key + region your app uses.
The access key ID must be alphanumeric on DynamoDB Local — no symbols. AWS docs state AWS_ACCESS_KEY_ID can contain only A–Z, a–z, and 0–9; AWS introduced this in DynamoDB Local 2.0.0 (and 1.23.0+), so a key with special characters that worked on an earlier image now fails (AWS re:Post). See the error below.

For LocalStack the safe default is test / test: it
ignores the secret key entirely
and never validates the secret value. Real-looking AKIA…/ASIA… keys are
rejected as a safeguard and fall back to the dummy account 000000000000 —
the same account an arbitrary key like test resolves to. Stick with test.

Note

Whatever dummy values you pick, use the same access key + region across your
app, the CLI, and your GUI. Mismatched values are the single most common reason a
local table "doesn't show up."

Connecting with the AWS CLI (sanity check)

Before pointing a GUI at it, confirm the endpoint is alive from the CLI. The CLI
has no built-in default local endpoint,
so either pass --endpoint-url per command or set
AWS_ENDPOINT_URL_DYNAMODB=http://localhost:8000 (CLI v2.13+).

DynamoDB Local:

aws dynamodb list-tables --endpoint-url http://localhost:8000

LocalStack (same command, different port):

aws dynamodb list-tables --endpoint-url http://localhost:4566

If you have credentials configured at all (even fake ones in ~/.aws/credentials
or via AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY), this returns your table list.
An empty list with no error means the endpoint works but you're looking at a
different key/region namespace — see the gotcha above.

Tip

Pass dummy creds inline for a one-off check without touching your profile:
AWS_ACCESS_KEY_ID=test AWS_SECRET_ACCESS_KEY=test AWS_REGION=us-east-1 \
  aws dynamodb list-tables --endpoint-url http://localhost:8000

DynamoDB Local GUI: browsing and querying local tables in DynoTable

Once the CLI works, a GUI needs the same three values: endpoint, region,
and any dummy credentials. The CLI returns DynamoDB-JSON you read by eye; a
GUI renders the same data as a table you can sort, filter, and edit.

In DynoTable, add a connection and set a custom endpoint:

Endpoint: http://localhost:8000 (DynamoDB Local) or http://localhost:4566 (LocalStack)
Region: whatever your app uses — e.g. us-east-1. It's a label here, not a real AWS region, but it must match so you land in the same data namespace.
Access key / secret: anything (test / test is conventional). Alphanumeric only for the access key on DynamoDB Local.

From there you browse items, run a Query or Scan, and edit rows visually
instead of marshalling JSON by hand on the CLI. When you load fixtures, the
DynamoDB-JSON converter turns plain JSON into
the wire format, and Query vs Scan covers which read to
reach for. Same drill for a
LocalStack DynamoDB viewer — only the port changes to
4566.

DynoTable is local-only desktop software, so pointing it at localhost keeps
your fixtures on your machine. For a broader look at the GUI landscape, see the
DynamoDB GUI comparison.

Common errors (region mismatch, port, credentials)

Warning

"Table not found" / empty list, but you know the table exists. Almost always
a region or access-key mismatch creating a separate myaccesskeyid_region.db
file. Match the key + region your app used, or restart DynamoDB Local with
-sharedDb so there's one shared database file.

Connection refused. Wrong port — 8000 is DynamoDB Local, 4566 is LocalStack. Also confirm the container actually published the port (docker run -p 8000:8000 amazon/dynamodb-local). For LocalStack, check the service is up at http://localhost:4566/_localstack/health.
The Access Key ID or Security Token is Invalid on DynamoDB Local. Since the 2.0.0 (and 1.23.0+) image, the access key ID must be alphanumeric only. A key with symbols that worked on an earlier image now fails — replace it with letters/numbers (e.g. test) and update every tool to match.
The security token included in the request is invalid against LocalStack. This is almost always an endpoint problem, not a credentials one — your SDK client dropped the --endpoint-url / endpoint_url and hit the real AWS endpoint, which rejects your dummy key. Confirm the client is actually pointed at http://localhost:4566.
Credential errors from the SDK/CLI. Even local endpoints need some credentials present. Set AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY (or a fake profile) so the SDK's credential chain resolves.
http vs https. Local endpoints are plain http. An https:// URL will fail the TLS handshake.

Is DynamoDB Local the same data as my real AWS tables?

No — local and cloud are completely separate stores. DynamoDB Local (and
LocalStack's DynamoDB) keeps data in a local file or in memory; it never touches
your AWS account, and
AWS Regions/accounts aren't supported at the client level
locally. That's the point: it's
for development and testing.
If you want the same fixtures in the cloud later,
AWS suggests
valid-looking key/region values locally so you only swap the endpoint when you move. To model that schema before
you ship it, single-table design and
GSI vs LSI cover the decisions that don't change between
local and prod.

FAQ

Do I need real AWS credentials? No. Both DynamoDB Local and LocalStack accept
dummy values. They just have to be present, alphanumeric (for DynamoDB Local),
and consistent across your tools.

Why do my tables disappear when I switch tools? Without -sharedDb, DynamoDB
Local partitions data by access-key + region into separate myaccesskeyid_region.db
files. Use -sharedDb or keep those values identical everywhere.

What's the difference between port 8000 and 4566? 8000 is standalone
DynamoDB Local's default; 4566 is LocalStack's single edge port that fronts all
its emulated services, DynamoDB included.

Can one GUI connect to both? Yes — they speak the same DynamoDB API. Only the
endpoint URL changes (:8000 vs :4566).

Is DynamoDB Local free? Yes. AWS distributes DynamoDB Local at no cost as a
JAR and a Docker image — there
are "no provisioned throughput, data storage, or data transfer costs"; it's
intended for development and testing only,
not production.

Can I run SQL against my local tables? Local DynamoDB speaks the same API as
the cloud, so the same access-pattern rules apply — and the same limits: DynamoDB's
PartiQL SELECT grammar
is SELECT … FROM … WHERE … ORDER BY only — no JOIN, no GROUP BY, and
no grouping aggregate functions
like COUNT/SUM/AVG (see PartiQL vs SQL).
DynoTable's SQL Workbench runs those
analytical queries over any connection, local included.

Try DynoTable to connect straight to localhost:8000 or
localhost:4566 and browse, query, and edit your local tables with a GUI.

The Best DynamoDB GUI Clients in 2026

DynoTable — Sat, 04 Jul 2026 10:38:10 +0000

There is no single "best" DynamoDB GUI — there are tools built for different jobs.
A data modeler is the wrong tool for poking at production rows; a generalist SQL
client is the wrong tool for DynamoDB's key structure. This is an honest roundup of
the main options — free, paid, and open-source, including our own — and what each
is genuinely good at, so you can match the tool to the work instead of the hype.

How to choose a DynamoDB GUI

Pick based on the job you actually do most:

Live data ops — browse, filter, and edit items in real tables, fast, without the AWS Console. This is the daily-driver case.
Data modeling — design tables, sort keys, and GSIs around your access patterns before you write code.
Analytics-shaped questions — JOINs, GROUP BY, aggregates. DynamoDB's own query surface does not do these (more below), so the tool has to compile around the limitation.

A tool that nails one of these is often mediocre at the others. Here's the quick
mapping:

Your main job	Reach for
Design tables / GSIs before coding	NoSQL Workbench
Browse & edit live data daily	Dynobase or DynoTable
Just see what's in a local table	dynamodb-admin / DynamoIt
Already live in a JetBrains IDE	DataGrip
JOIN / `GROUP BY` / aggregates over your data	DynoTable (SQL Workbench)

Tip

Most teams end up with two tools, not one: a modeler for design time and a
data-ops client for everything after. That split is normal — don't expect a single
GUI to be excellent at both.

AWS NoSQL Workbench

Free · macOS / Windows / Linux · modeling-first

NoSQL Workbench is AWS's own
free, cross-platform visual tool, built around three pillars: a data modeler for
building tables and GSIs (from scratch, imported, or modified from an existing
model), data visualization for previewing access patterns and relationships
against sample data, and an operation builder for exploring datasets and building
data-plane operations — it also generates ready-to-run sample code in several
languages. It connects directly to DynamoDB Local for offline work and can commit
models to a real AWS account. (Features and platforms per the
AWS NoSQL Workbench page,
verified 2026-06-10.)

It's the best free way to design a table, but it's a development and modeling tool,
not a production table browser. Reach for it when you're modeling your
single-table design, not when you're debugging a row
at 2am. Our NoSQL Workbench alternative page
covers the day-to-day gap.

Dynobase

$199 one-time or $9/mo ($108/yr) · 7-day trial · macOS / Windows / Linux

Dynobase is the established paid desktop client and the
most feature-complete commercial option. As of 2026-06-10 its
pricing page lists a $9/month Solo plan ($108 billed
annually) or a $199 one-time lifetime license (down from $249), with a 7-day free
trial that needs no credit card. It covers fast data exploration, inline editing,
code generation, import/export, a SQL/PartiQL console, and DynamoDB Local /
LocalStack support (including Docker distributions).

Note

Dynobase is still sold, and its pricing page lists cross-platform builds with
DynamoDB Local / LocalStack support and a PartiQL console; its last published
version is a 2023 beta. The trade-offs are price, that it's closed-source, and
that its SQL surface is AWS PartiQL pass-through — so it inherits PartiQL's
limits (no cross-table JOIN, GROUP BY, or aggregates).

If you want a polished, broad commercial GUI and the license cost is fine, it's a
solid pick. Our Dynobase alternative page covers
where DynoTable differs — chiefly the SQL Workbench and EUR/EU-tax billing.

TablePlus / DataGrip

Generalist SQL clients with partial-to-no DynamoDB support

These are excellent relational clients, but DynamoDB is a second-class citizen — or
absent.

TablePlus does not list DynamoDB among its supported databases — as of 2026-06-10 that list is relational plus Cassandra, Redis, and MongoDB (Beta), with no DynamoDB driver.
DataGrip added DynamoDB in version 2023.3, whose release notes state DynamoDB data is viewable in the data viewer, tables with keys and indexes are introspected, and PartiQL is supported in the code editor. It's genuinely useful if you already live in a JetBrains IDE, but it's a viewer-plus-PartiQL surface, not a DynamoDB-native modeling or query-planning tool.

If DynamoDB is a primary database for you, a purpose-built client fits the data
model better than a JDBC bridge. See the
TablePlus & DataGrip comparison.

dynamodb-admin / DynamoIt

Free / open-source · local-focused

For local development there are good free options:

dynamodb-admin is a small open-source web GUI for DynamoDB Local, dynalite, and LocalStack. Install it globally and point it at your local endpoint:

  pnpm add -g dynamodb-admin
  dynamodb-admin --dynamo-endpoint=http://localhost:8000

By default it sets dummy credentials (key/secret, region us-east-1) so it
connects straight to a local endpoint — the standard answer for "I just need to
see what's in my local table." (The --dynamo-endpoint flag and the
default key/secret/us-east-1 credentials are documented in the
dynamodb-admin README; the package
is MIT-licensed. Verified 2026-06-10. The README shows npm install -g; pnpm
installs the same npm package.) For a deeper walkthrough of endpoints and dummy
creds, see connecting to DynamoDB Local.

DynamoIt is a free, open-source JavaFX desktop viewer that reads your AWS CLI profiles for quick browse/edit/create/delete. It auto-picks scan vs query and supports pagination, local DynamoDB, and index awareness, and its README notes you need at least Java 17 (and Maven) to build and run it. (Features, GPL-3.0 license, and Java requirement per the DynamoIt README, verified 2026-06-10.)

Both are great for local and light use and cost nothing — but neither aims to be a
full-featured production workbench.

Warning

Local-only GUIs like dynamodb-admin and DynamoIt are excellent for development, but
pointing a bare admin UI at a production table is risky: there are no guardrails
around a full-table Scan, and an accidental scan on a
large table burns read capacity and money. Use a client that shows query cost before
you run it.

DynoTable

SQL Workbench: JOIN / GROUP BY / aggregates within DynamoDB's access-pattern rules

Full disclosure: this is our tool. DynoTable is a desktop DynamoDB GUI client whose
differentiator is a SQL Workbench that compiles SQL — INNER/LEFT JOIN,
GROUP BY, and aggregates — down to DynamoDB's real Query/Scan operations.

That matters because DynamoDB's own SQL surface, PartiQL, can't do those. Per the
PartiQL SELECT reference,
its grammar is SELECT … FROM … WHERE … ORDER BY only — there is no JOIN,
no GROUP BY, and no aggregate functions like COUNT, SUM, or AVG. So a tool
that wants to answer relational-shaped questions has to plan and compile them
against your keys and GSIs itself, rather than passing SQL through. The
PartiQL vs SQL guide walks through exactly where PartiQL
stops and how the Workbench fills the gap.

-- Runs in the DynoTable SQL 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

It also covers the daily-driver basics — fast table browser, inline item editing,
query/scan building, and DynamoDB Local for offline work — and runs its AI assistant
on your own AWS Bedrock credentials. It's the right pick when your questions are
analytics-shaped and PartiQL leaves you stuck. See
DynoTable as a DynamoDB GUI.

Comparison table

Tool	Cost	Platforms	Live data ops	Modeling	JOIN / GROUP BY / aggregates
NoSQL Workbench	Free	macOS / Win / Linux	Limited	Strong	No
Dynobase	$199 once / $9·mo	macOS / Win / Linux	Strong	Partial	No (PartiQL only)
TablePlus	—	—	No DynamoDB support	No	No
DataGrip	Paid IDE	macOS / Win / Linux	Viewer + PartiQL	No	No (PartiQL only)
dynamodb-admin	Free (OSS)	Any (Node)	Local only	No	No
DynamoIt	Free (OSS)	Any (JVM)	Basic	No	No
DynoTable	See pricing	macOS / Win / Linux	Strong	No	Yes (SQL Workbench)

Pricing and version claims are dated 2026-06-10; re-check the vendor pages before
relying on them.

What is the best DynamoDB GUI client?

There isn't one universal answer — it depends on the job. NoSQL Workbench is the
best free modeling tool, Dynobase is the most feature-complete commercial client,
dynamodb-admin is the standard for local development, and DynoTable adds a SQL
Workbench that runs JOINs, GROUP BY, and aggregates that DynamoDB's own PartiQL
can't. Start from the work you do most — design, daily data ops, or analytics — and
the choice usually makes itself.

Is there a free DynamoDB GUI?

Yes. AWS NoSQL Workbench is free and cross-platform (and the safest "official"
choice), and dynamodb-admin and DynamoIt are free and open-source. The catch:
dynamodb-admin and DynamoIt are aimed at local development, and NoSQL Workbench is a
modeling tool, not a live-data daily driver. There's no free, full-featured
production data-ops client — that's where the paid clients earn their keep.

What's a good DynamoDB GUI for Mac, Windows, or Docker?

All the desktop clients here are cross-platform (macOS, Windows, Linux) —
NoSQL Workbench, Dynobase, DataGrip, and DynoTable all ship for Apple Silicon Macs
and Windows. For Docker-based local setups, dynamodb-admin is the usual pick: it
runs against the amazon/dynamodb-local container by pointing
--dynamo-endpoint at the exposed port. DynoTable and Dynobase also connect to a
local endpoint, including LocalStack.

Can TablePlus or DataGrip connect to DynamoDB?

TablePlus does not list DynamoDB among its supported databases. DataGrip added
DynamoDB support in 2023.3 as a data viewer with key/index introspection plus a
PartiQL editor, but it's not a DynamoDB-native modeling or query-planning tool — it
inherits PartiQL's limits and can't JOIN, group, or aggregate across tables.

Can a GUI run real SQL (JOINs and aggregates) against DynamoDB?

Not through PartiQL — DynamoDB's PartiQL SELECT has no JOIN, GROUP BY, or
aggregate functions, so any client that "supports SQL" via PartiQL (Dynobase,
DataGrip) hits the same wall. A tool has to compile those into DynamoDB's
Query/Scan operations itself; DynoTable's SQL Workbench is built to do exactly
that. If you only need to assemble the raw filter/key conditions for a single API
call, the DynamoDB Expression Builder
generates the correct FilterExpression / KeyConditionExpression without any SQL
surface at all.

Do I still need a GUI if I have the AWS Console?

Many people switch precisely because of the Console's limits — weak filtering,
clumsy pagination, and no real export. A purpose-built GUI adds fast filtering,
inline editing, query/scan building with cost visibility, and one-click export. If
your pain is Console-specific, that's a feature-by-feature gap a native client
closes.

Concepts the right tool should make easy: query vs scan, single-table design, and the PartiQL vs SQL gap that the SQL Workbench fills (with worked PartiQL examples).
Free tools that run in your browser, no install: the DynamoDB JSON converter and the Expression Builder.
Head-to-head pages: DynamoDB GUI client overview, Dynobase, NoSQL Workbench, and TablePlus & DataGrip.
Download DynoTable and run a JOIN against your own tables.

Last verified 2026-06-10. Product names are trademarks of their respective owners;
referenced here for identification only.