DynamoDB and Amazon Neptune are both fully managed AWS databases, but they model data in fundamentally different ways. DynamoDB is a key-value and document store you query by key. Neptune is a purpose-built graph database that stores nodes and edges (or RDF triples) and traverses relationships directly with graph query languages. The choice comes down to whether relationships are the primary thing you query.
Should you use DynamoDB or Neptune?
Choose DynamoDB for key-based access to structured records at scale, where relationships are limited and can be modeled with keys. Choose Amazon Neptune when connections are the core of your queries — multi-hop traversals, shortest-path, recommendations, fraud rings, knowledge graphs — where a graph model expresses in one query what would be many round-trips against a key-value store. How relationship-heavy your queries are decides it.
DynamoDB vs Amazon Neptune at a glance
| Characteristic | DynamoDB | Amazon Neptune |
|---|---|---|
| Data model | NoSQL key-value and document; typed items up to 400 KB in tables | Graph — property graph (nodes/edges with properties) and RDF (subject-predicate-object triples) |
| Query language / API | Native API (GetItem, Query, Scan) plus PartiQL, a SQL-compatible language |
Gremlin and openCypher for property graphs; SPARQL for RDF graphs |
| Primary access | Key-based lookups on partition/sort key; relationships modeled via keys | Relationship traversal — walk edges across many hops in a single query |
| Relationships | No native traversal; model with an adjacency list or single-table design | Edges are first-class; multi-hop and path queries are native and efficient |
| Consistency | Eventually consistent by default; strongly consistent reads available per request | Reads are consistent within a cluster; read replicas serve scaled reads |
| Scaling model | Automatic partitioning; serverless on-demand or provisioned capacity | Provisioned DB instances with read replicas, or Neptune Serverless (capacity in NCUs) that autoscales |
| Transactions | ACID transactions across multiple items within a Region | ACID transactions over graph mutations |
| Pricing / ops model | Pay-per-request (on-demand) or provisioned capacity plus storage; serverless | Instance-hours (provisioned) or NCU-hours (Serverless), plus storage and I/O; AWS-only |
| Best-fit workloads | Profiles, sessions, carts, events — key-based records at scale | Social graphs, recommendations, fraud detection, knowledge graphs, network/identity graphs |
When DynamoDB is the better choice
- Your access is key-based. Get-by-id, query-a-partition, and filter-within-a-partition map naturally to DynamoDB and stay fast at any scale.
- Relationships are shallow or bounded. One-to-many and many-to-many links can be modeled with keys — an adjacency list or single-table design — without a graph engine.
- You want serverless simplicity and pay-per-request. On-demand capacity has nothing to size and scales to zero when idle.
- You do not run deep traversals. If you rarely walk more than a hop or two, a graph database's strengths go unused.
When Neptune is the better choice
- Relationships are the query. Multi-hop traversals — friends-of-friends, shortest path, "who is connected to whom" — are native in Gremlin, openCypher, or SPARQL, where a key-value store would need many sequential reads.
- You need a property graph or RDF. Neptune supports both models and their standard query languages, suiting knowledge graphs and linked-data use cases.
- Your domain is graph-shaped. Fraud detection, recommendation engines, social networks, and identity/network graphs express naturally as nodes and edges.
- Traversal patterns keep evolving. New relationship questions are new graph queries, not a redesign of your keys.
A useful rule of thumb: DynamoDB can represent relationships with an adjacency-list pattern, and that is enough when you know the traversals in advance and they stay shallow. When traversals are deep, variable-depth, or ad-hoc, Neptune's graph engine is built for exactly that and avoids the many-round-trip cost of walking edges in a key-value store.
What a Gremlin traversal becomes in DynamoDB
Three hops out from a user, deduplicated, is one line of Gremlin against Neptune:
g.V('user:8231').repeat(out('FOLLOWS')).times(3).dedup().values('handle')
Neptune even lets you tune how that traversal executes. The
Neptune#repeatMode query hint switches repeat() between breadth-first,
depth-first, and a chunked hybrid, because the frontier of a wide traversal is a
real memory problem the engine manages on your behalf.
The DynamoDB equivalent starts well. With an adjacency list where PK is the
vertex and SK is the outgoing edge, one hop is one Query:
{
"TableName": "social",
"KeyConditionExpression": "PK = :v AND begins_with(SK, :rel)",
"ExpressionAttributeValues": {
":v": {"S": "USER#8231"},
":rel": {"S": "FOLLOWS#"}
}
}
The second hop then needs one of those per vertex the first hop returned, and the
third needs one per vertex the second returned. BatchGetItem does not rescue
this: each hop is a partition query, BatchGetItem only fetches by full primary
key, and the two are not interchangeable. A user following 500 accounts costs 1
query, then 500, then up to 250,000, and the depth of that fan-out is sequential
because hop N cannot start until hop N-1 returns.
Everything the traversal did implicitly is now code you own. The visited set
dedup() gave you, cycle detection, the breadth-first versus depth-first choice
Neptune#repeatMode exposed as a one-word hint, and the memory a wide frontier
occupies now that it lives in your process rather than the database.
Variable depth has no equivalent at all.
repeat(out('FOLLOWS')).until(hasId('user:1104')) walks until it reaches the
target, however deep that is. No DynamoDB request expresses "keep going until a
condition holds". The loop, its termination, and its worst case are yours.
DynoTable's SQL Workbench flattens a fixed two-hop into one statement, joining the
adjacency list to itself with INNER JOIN and planning both sides against your
real keys. That is a real convenience at known depth and no help whatsoever at
variable depth.
Working with DynamoDB
If your workload is key-based and you model relationships with an adjacency list, DynoTable is a native desktop client for DynamoDB on macOS, Windows, and Linux. It reads your standard AWS credential chain, so your data stays in DynamoDB with nothing to migrate. It browses and inline-edits items, builds key conditions and filters visually, and adds a SQL Workbench that expresses relational-shaped queries within DynamoDB's access-pattern rules, plus an AI agent on your own AWS Bedrock credentials.
The free DynamoDB Expression Builder generates the key conditions, filters, and update expressions an adjacency-list model needs, in SDK, CLI, and PartiQL form. DynoTable is a closed-source commercial app; this page describes what it does, not how it is built.
FAQ
Can DynamoDB be used as a graph database?
Partially. DynamoDB has no native graph traversal, but you can model relationships with an adjacency-list pattern or single-table design, which works well when traversals are known and shallow. For deep, variable-depth, or ad-hoc traversals — shortest path, multi-hop recommendations — a purpose-built graph database like Neptune is a better fit because it walks edges natively instead of issuing many separate reads.
What query languages does Neptune support versus DynamoDB?
Neptune supports Gremlin and openCypher for property graphs and SPARQL for RDF graphs. DynamoDB uses its native API (GetItem, Query, Scan, and related operations) plus PartiQL, a SQL-compatible language. There is no overlap in query language — the models are different.
When should I choose Neptune over DynamoDB?
Choose Neptune when connections are what you query most: many-hop traversals, path finding, or relationship-centric domains like fraud detection, recommendations, and knowledge graphs. Choose DynamoDB when access is primarily by key and relationships are limited enough to model with keys. Some architectures use both — DynamoDB for the operational records and Neptune for the connected graph over them.
Related
- Model relationships in DynamoDB with the adjacency-list pattern, one-to-many, and many-to-many guides.
- Structure it all with single-table design.
- Build expressions with the free DynamoDB Expression Builder.
- Download DynoTable to browse, query, and edit your DynamoDB tables.
References
- What is Amazon DynamoDB? — AWS DynamoDB Developer Guide
- PartiQL — a SQL-compatible query language for DynamoDB
- Amazon DynamoDB transactions
- DynamoDB on-demand capacity mode
- What is Amazon Neptune?
- Amazon Neptune Serverless (NCU capacity)
- Amazon Neptune pricing
Last verified 2026-07-13 against the official AWS DynamoDB and Amazon Neptune documentation. Amazon Neptune and DynamoDB are services of Amazon Web Services; referenced here for identification only.
Top comments (0)