Specialized AWS Databases: Neptune, DocumentDB & Timestream
Three purpose-built managed databases for data shapes that RDS and DynamoDB don't fit well — graph relationships, MongoDB-compatible documents, and time-series data.
Want a visual for this topic?
Generate a diagram tailored to Specialized AWS Databases: Neptune, DocumentDB & Timestream — the AI picks whichever visual (architecture, flowchart, ER diagram, etc.) best fits this specific AWS concept.
Sign in to generate a visual →🎓 Learning objectives
- •Explain what a graph database is for and why Neptune exists alongside RDS/DynamoDB
- •Explain DocumentDB's MongoDB compatibility and what that does and doesn't guarantee
- •Explain what makes time-series data different enough to need a purpose-built database (Timestream)
- •Match a described data access pattern to the right one of these three (or to RDS/DynamoDB instead)
What is it?
Amazon Neptune is a fully managed graph database supporting both the property-graph model (queried with Gremlin or openCypher) and the RDF model (queried with SPARQL) — purpose-built for data where relationships between entities are a first-class concern, not just a foreign key. Amazon DocumentDB is a fully managed document database with MongoDB API compatibility, built on AWS's own distributed storage engine (in the same architectural family as Aurora), letting existing MongoDB-driver application code run largely unmodified. Amazon Timestream is a fully managed time-series database purpose-built for workloads with massive continuous ingest of timestamped data and queries that filter/aggregate by time range, with automatic storage tiering between fast 'recent' storage and cheaper 'historical' storage.
Why it exists
Each exists because forcing its specific data shape into a general-purpose database becomes genuinely painful past a certain scale or complexity: deep relationship queries in SQL require chains of self-joins that get slower and harder to write as traversal depth grows; teams with large existing MongoDB codebases faced a real rewrite cost moving to AWS's other database options; and time-series workloads manually built on top of a general-purpose database require hand-rolled partitioning-by-time and archival logic that Timestream provides natively.
Problem it solves
Neptune solves efficient deep-relationship-traversal queries that become impractical in relational self-joins. DocumentDB solves migrating existing MongoDB-based applications to AWS without a driver/query rewrite. Timestream solves the ingest-volume-plus-time-range-query pattern that would otherwise require significant custom partitioning/archival engineering on a general-purpose database.
Intuition
The core question for all three is 'does my data's natural shape and access pattern match this database's specialty, or am I forcing a general-purpose fit into a specialized tool just because it exists.' Graph databases earn their keep specifically when relationship-traversal depth/complexity is the actual bottleneck, not just because data 'has relationships' (almost all data does). DocumentDB's value is almost entirely about NOT rewriting existing MongoDB code, not about document modeling being inherently superior. Timestream's value is specifically about ingest volume and time-range query patterns at a scale where manual time-based partitioning in a general-purpose database would become its own engineering project.
Analogy
RDS and DynamoDB are general-purpose toolboxes that handle most jobs well. Neptune, DocumentDB, and Timestream are specialty tools for jobs where the general-purpose tool technically works but is clearly the wrong shape — Neptune is a tool built specifically for mapping and tracing connections (like a corkboard-and-string investigation board), DocumentDB is a tool shaped exactly like one your team already owns (MongoDB) so existing muscle memory still works, and Timestream is a tool built specifically for the 'firehose of timestamped readings' shape of data.
Technical explanation
Neptune's property-graph engine stores vertices and edges with their properties directly, using specialized graph-traversal indexes rather than relational B-tree indexes, so a Gremlin traversal like 'friends of friends of friends' executes as a sequence of native graph hops rather than three chained relational joins whose cost multiplies with each additional hop. DocumentDB decouples compute from storage the same way Aurora does, replicating data six ways across three Availability Zones on its custom storage layer while presenting a MongoDB-wire-protocol-compatible query interface on top, which is why it needs to explicitly target specific MongoDB API versions rather than claiming full, always-current compatibility. Timestream's query engine automatically determines which storage tier(s) a query needs to touch based on the time range requested, transparently merging results from the in-memory store and magnetic store without the application needing to know which tier any given data point currently lives in.
Architecture
Neptune runs as a cluster with one writer and up to 15 read replicas sharing a common distributed, self-healing storage volume across 3 Availability Zones — architecturally similar to Aurora's storage layer, but the query engine operates on graph data structures (vertices/edges/properties) rather than relational tables. DocumentDB similarly uses a cluster-with-replicas model with the same Aurora-family distributed storage approach underneath, exposing a MongoDB-API-compatible query layer on top. Timestream stores recently-ingested data in an in-memory store optimized for high-throughput writes and fast recent-data queries, then automatically moves data older than a configured threshold to a magnetic storage tier optimized for cost, with queries transparently spanning both tiers.
Workflow
For any of the three: 1) Confirm the access pattern genuinely matches the specialized shape (deep relationship traversal for Neptune, existing MongoDB compatibility need for DocumentDB, time-range-filtered aggregation over continuous ingest for Timestream) rather than defaulting to a specialized database out of novelty. 2) Provision the managed cluster (Neptune/DocumentDB use a similar cluster-with-replicas model to Aurora; Timestream is closer to DynamoDB's fully-managed, no-cluster-to-size model). 3) Model data in the native shape for that database (graph vertices/edges for Neptune, BSON-like documents for DocumentDB, measure/dimension/timestamp records for Timestream). 4) Query using each database's native query language (Gremlin/openCypher/SPARQL, MongoDB query API, or Timestream's SQL-like query language with time-series extensions).
Example
A social platform uses Neptune to power its 'people you may know' feature, traversing a friends-of-friends graph that would require an expensive, deeply nested self-join chain in a relational database. A team migrating an existing MongoDB-based application to AWS adopts DocumentDB specifically to avoid rewriting its Mongoose/MongoDB-driver-based application code. An industrial IoT platform ingesting sensor telemetry from thousands of machines uses Timestream to store readings, running dashboard queries like 'average vibration reading per machine, last hour, smoothed' using Timestream's built-in time-series functions.
Real-world usage
Neptune is commonly used for fraud-ring detection (tracing suspicious connection patterns between accounts/transactions), recommendation engines, and knowledge graphs. DocumentDB is most commonly adopted by teams specifically migrating an existing MongoDB-based application to AWS as part of a broader cloud migration, rather than chosen fresh for a brand-new project. Timestream is used for IoT telemetry platforms, application/infrastructure monitoring metrics pipelines, and financial market tick-data storage — anywhere ingest volume and time-range queries dominate the access pattern.
Trade-offs
Each of these three narrows the use case in exchange for being excellent at it — Neptune isn't a good fit for simple key-value lookups, DocumentDB isn't a good fit for workloads needing strict multi-document ACID transactions the way a relational database guarantees, and Timestream isn't a good fit for arbitrary ad-hoc non-time-based queries. Choosing one of these three when RDS/DynamoDB would have sufficed adds an extra database technology for the team to operate and understand, for no real benefit.
Visual explanation
Picture three specialists at a general hospital that also has general practitioners (RDS/DynamoDB). Neptune is the specialist who reads relationship charts — who's connected to whom, and how — faster than anyone tracing it by hand through individual case files. DocumentDB is a specialist who happens to use the exact same instruments and shorthand your existing staff (MongoDB drivers) were already trained on. Timestream is the specialist for the ward that only ever deals with continuous monitor readings over time, with a system already built to keep the last hour's readings instantly at hand and archive the rest.
Advantages
- —
Neptune: native graph traversal performance that scales far better with relationship depth than repeated relational joins
- —
Neptune: supports both major graph query paradigms (property graph via Gremlin/openCypher, RDF via SPARQL) in one service
- —
DocumentDB: minimal-to-no application code changes when migrating an existing MongoDB-driver-based application
- —
Timestream: automatic hot/cold storage tiering with no manual archival logic, plus built-in time-series functions (interpolation, smoothing) not natively available in general-purpose SQL
- —
All three: fully managed — no patching, replication, or storage-scaling operational burden, matching every other managed AWS database
Disadvantages
- —
Neptune's query languages (Gremlin, SPARQL, openCypher) have a real learning curve for teams without prior graph database experience
- —
DocumentDB targets specific MongoDB API versions (3.6/4.0/5.0 compatibility) — some newer MongoDB-native features or very recent driver behaviors may not be supported, requiring verification for a given application
- —
Timestream isn't a good fit for non-time-series general-purpose queries — it's genuinely a specialized tool, not a general-purpose database with time-series features bolted on
- —
Adopting any of the three adds a distinct query language/API and operational model the team needs to learn, compared to standardizing on RDS/DynamoDB alone
Common mistakes
- —
Reaching for Neptune because data 'has relationships,' when a handful of straightforward foreign-key joins in RDS would have been simpler and sufficient
- —
Assuming DocumentDB is a drop-in replacement without verifying the specific MongoDB API version and feature set an application actually depends on
- —
Building a hand-rolled time-based partitioning scheme on RDS/DynamoDB for a genuinely time-series-shaped workload, when Timestream would have handled it natively
- —
Treating these three as interchangeable 'NoSQL options' rather than recognizing each targets a distinct, specific data shape
In the AWS Console
- 1
Neptune → Databases → Create database, then Notebooks → Create notebook
Create a Neptune cluster and connect via a notebook instance for Gremlin/openCypher querying.
The Neptune-hosted Jupyter notebook is the fastest way to try Gremlin queries without setting up a separate client.
- 2
DocumentDB → Clusters → Create cluster
Create a DocumentDB cluster and connect using any standard MongoDB driver/connection string.
DocumentDB clusters are VPC-only by default — a bastion host or VPN/Direct Connect is needed to connect from outside the VPC, same as RDS.
- 3
Timestream → Databases → Create database, then Tables → Create table
Create a Timestream database and table, then write and query sample time-series records.
Set the memory-store retention period deliberately — it controls how long data stays in the fast 'hot' tier before moving to magnetic storage.
🎤 Interview questions
What is Amazon Neptune, and what kind of problem is it built for? (Listen for: a fully managed graph database supporting property graph (Gremlin/openCypher) and RDF (SPARQL) models, purpose-built for highly connected data where the relationships between records matter as much as the records themselves — social networks, recommendation engines, fraud-detection ring analysis, knowledge graphs — queries like 'friends of friends within 3 hops' are natural in a graph model and awkward as repeated SQL joins)
Is Amazon DocumentDB actually running MongoDB? (Listen for: no — DocumentDB implements MongoDB API compatibility (specifically targeting MongoDB 3.6/4.0/5.0 API behavior) on top of AWS's own distributed storage engine, similar in spirit to how Aurora reimplements MySQL/PostgreSQL wire compatibility on custom storage; most MongoDB driver code and queries work unmodified, but it isn't literally the MongoDB codebase, so some newer or edge-case MongoDB features aren't supported)
What makes time-series data different enough to need Amazon Timestream instead of RDS or DynamoDB? (Listen for: time-series workloads have a specific access pattern — massive continuous ingest of timestamped data points, queries almost always filtered/aggregated by time range, and a natural need to keep recent data 'hot' for fast queries while aging older data to cheaper storage automatically; Timestream's storage tiering and time-series-specific query functions (interpolation, smoothing) handle this natively instead of requiring manual partitioning/archival logic on top of a general-purpose database)
When would you choose Neptune over modeling relationships in a relational database with join tables? (Listen for: when relationship traversal depth is variable and/or deep — 'find all connections within N hops' becomes an increasingly expensive chain of self-joins in SQL as N grows, while a graph database traverses relationships natively and efficiently regardless of depth)
A team is building an IoT platform ingesting millions of sensor readings per minute, mostly queried as 'average temperature over the last hour' or 'readings from the last 24 hours.' Which AWS database fits best, and why? (Listen for: Amazon Timestream — purpose-built for exactly this ingest-heavy, time-range-query-heavy pattern, with automatic tiering of recent 'hot' data to memory-backed storage and older 'cold' data to cheaper storage, plus built-in time-series query functions)