DocumentDB, Neptune, Keyspaces and Timestream

By the end of this lesson you will be able to

• Say why AWS offers purpose-built databases, and recognise the four data shapes this lesson covers: documents, graphs, wide-column partitions and time series.
• Describe Amazon DocumentDB: a MongoDB-compatible JSON document database whose storage works like Aurora’s (one cluster volume, six copies in three AZs, grows by itself), with up to 15 replicas, failover and reader endpoints; and place elastic clusters, global clusters and the serverless option.
• Explain what a graph database does better than SQL, tell the property graph model (Gremlin, openCypher) from RDF (SPARQL), and describe Amazon Neptune: up to 15 read replicas across AZs, billions of relationships, millisecond traversals, and the use cases the exam names (social networks, fraud detection, knowledge graphs, recommendations).
• Use Neptune Streams correctly: an ordered, duplicate-free change log read over HTTP, used to send notifications, keep OpenSearch, S3 or ElastiCache in sync, or copy to another Region; and know its retention and what Neptune Global Database does instead.
• Explain Apache Cassandra (masterless, wide-column, write-heavy) and Amazon Keyspaces: serverless, CQL, three copies across AZs, on-demand or provisioned capacity, PITR for 35 days, multi-Region replication, and the “existing Cassandra workload” exam answer.
• Describe time-series data and Amazon Timestream: serverless, memory store and magnetic store, SQL with time functions, scheduled queries, the ingest and visualisation architecture, and the 2025 change that steers new customers from Timestream for Live Analytics to Timestream for InfluxDB.
• For each engine, give a real scenario, say why it beats DynamoDB or RDS there, and pick it from exam keywords; spot the wrong picks (a graph as SQL self-joins, time series bloating RDS, ping firehoses in documents).

#Why purpose-built databases

Lesson 16.1 gave you the questions to ask and the decision map: relational for transactions and joins (RDS, Aurora), key-value at any scale (DynamoDB), in-memory (ElastiCache, MemoryDB), objects (S3), warehouse and search for analytics (Redshift, OpenSearch). That map has four more boxes, and they are this lesson. Each one exists because some data has a shape that a general database stores badly:

AWS calls this purpose-built databases: instead of forcing every kind of data into one relational engine, pick the engine whose model matches the data and the questions. A real application often uses several at once. That is fine; each holds the data it is good at.

Try the same idea with one ride on a ride-sharing app. Pick an engine and a question and see which pairs fit:

The pattern to remember: DocumentDB for “fetch this object”, Neptune for “follow the connections”, Keyspaces for “write a firehose, read it back by key”, Timestream for “what happened over time”. Each poor fit in the explorer is a real exam distractor.

#Amazon DocumentDB

#What it is

Amazon DocumentDB (with MongoDB compatibility) is a fully managed JSON document database that speaks the MongoDB API. Your application keeps its MongoDB drivers, its queries (find, insertOne, the aggregation pipeline) and its tools such as mongosh; it just points at a DocumentDB endpoint. AWS does the hardware, patching, backups, replication and failover.

A document is a JSON object (up to 16 MB) stored in a collection. Documents in one collection need not have the same fields, they can nest objects and arrays, and you can index any field, including nested ones. You query by any indexed field, not only by a key.

DocumentDB is AWS’s own engine that implements the MongoDB API, not MongoDB’s source code. It is compatible with MongoDB 3.6, 4.0, 5.0 and, since 2025, 8.0 APIs. Most applications work unchanged, but a few MongoDB features are missing or behave differently, so check the compatibility list before migrating. The notes call it “AWS DocumentDB”; the official name is Amazon DocumentDB (with MongoDB compatibility).

#Aurora’s architecture, for MongoDB

The slides put it in one line: Aurora is AWS’s implementation of MySQL and PostgreSQL, and DocumentDB is the same idea for MongoDB. The deployment concepts match Aurora (lesson 7.3), because compute and storage are separated (the notes say “disconnected”; decoupled is the word):

• One cluster volume holds the data, on SSDs, as six copies across three Availability Zones. A write is acknowledged when a majority of the copies has it, so the loss of an AZ loses nothing.
• Storage grows automatically as data grows, and you pay only for what you use, up to 128 TiB per cluster (256 TiB on engine 8.0). The slide’s “grows in increments of 10 GB” describes the same behaviour in older terms; you never provision storage.
• Instances only compute: one primary that reads and writes, and up to 15 replicas that only read. Replicas read the same volume, so they are usually less than 100 ms behind and can be added in minutes whatever the data size.
• Endpoints: the cluster endpoint always points at the current primary (use it for writes), the reader endpoint spreads connections over replicas, and each instance has its own endpoint (avoid it in applications).
• Failover: if the primary fails, a replica (you set priority tiers) is promoted and the cluster endpoint moves to it, usually within well under a minute, with no data loss because storage is shared. With no replica, DocumentDB must create a new primary, which takes much longer.
• Reads from replicas are eventually consistent; the driver’s read preference chooses: primary for read-after-write, secondaryPreferred to offload reads.
• Backups are continuous with point-in-time restore (1 to 35 days), encryption at rest uses KMS (lesson 21.2), and the cluster lives in your VPC.

The slide’s “scales to millions of requests per second” is true with elastic clusters (below), which shard the data. A normal instance-based cluster has one writer and scales reads with replicas.

#Why DocumentDB and not DynamoDB or RDS

#Side notes: elastic clusters, global clusters and serverless

#Amazon Neptune

#Graphs: vertices, edges and properties

A graph stores vertices (also called nodes: people, wallets, phones, products, places) and edges (relationships: knows, used, bought, located in), and both can carry properties (name, amount, date). The point of a graph database is that relationships are stored, not computed: each vertex keeps its edges, so going from a vertex to its neighbours is one cheap step, called a hop, whatever the size of the graph. A query is a traversal: start somewhere and follow edges.

In a relational database the same data lives in tables, and every hop is a join. One or two joins are fine. “Friends of friends of friends” or “any account within six transfers of a flagged one” becomes a stack of self-joins on huge tables whose intermediate results multiply; the query gets slow, hard to write and harder to tune. The notes put it simply: when the relationships are complex and highly connected, relational and general NoSQL databases struggle, and that is where Neptune comes in. (They can store the data; they just answer many-hop questions badly.)

#Property graph or RDF

Neptune supports two graph models, each with its own query languages. The notes mention Gremlin and SPARQL; openCypher is the third, now widely used:

One Neptune cluster can serve a property graph through both Gremlin and openCypher; RDF data is queried with SPARQL.

#What Neptune gives you

• Fully managed graph database, built to store billions of relationships and query them with millisecond latency.
• The same cluster design as Aurora: one primary that writes, up to 15 read replicas, a shared cluster volume replicated across three AZs (it grows automatically, up to 128 TiB), automatic failover to a replica, continuous backup to S3 with point-in-time restore, encryption with KMS, inside your VPC.
• Endpoints over HTTPS (port 8182 by default): /gremlin, /openCypher, /sparql, plus a bulk loader that imports CSV or RDF files from S3.
• Neptune is single-writer and not sharded: it scales reads with replicas and writes with a bigger primary. A firehose of millions of small writes per second is a job for DynamoDB or Keyspaces, not for a graph.

#Where graphs win

The slides’ classic example is a social network: users have friends, posts have comments, comments have likes from users, users share and like posts. The notes and slides list the uses the exam names:

• Social networks: who is connected to whom, “people you may know”, mutual friends.
• Fraud detection in financial transactions: rings of accounts that share devices, addresses or cash-out points.
• Recommendation engines: “customers who bought this also bought”, based on paths through purchases.
• Knowledge graphs (Wikipedia-style, or a company’s products, documents and people), network and IT security maps, drug discovery.

#Why Neptune and not DynamoDB or RDS

DynamoDB has no joins at all; following relationships means one request per hop from application code. RDS can join, but each hop is a join whose cost grows with the data, and deep or variable-depth questions (“within any number of hops”) are painful in SQL. When the relationships are the data, a graph database answers in milliseconds what the others answer in seconds or minutes. When the data is mostly independent records, Neptune is overkill: keep receipts in DocumentDB or DynamoDB and use the graph for the connections.

#Neptune Streams

Neptune Streams is a change log of the graph. Once enabled (cluster parameter neptune_streams = 1), every change (vertex or edge added, property changed, triple removed) is written to the stream in the same transaction as the change itself. What it guarantees:

• Real-time and ordered: records are available as soon as the transaction commits, strictly in the order changes happened, including the order inside one transaction.
• No duplicates and nothing missing: each change appears exactly once.
• Read over an HTTP REST API: a reader sends an HTTP GET to /propertygraph/stream (Gremlin and openCypher data) or /sparql/stream (RDF), starting from a commit number, and pages through the records. It can read from the writer or the replicas.
• Retention: records are purged after 7 days by default, adjustable from 1 to 90 days (neptune_streams_expiry_days). Disabling streams makes the log unreadable at once.
• It adds I/O and storage cost and slightly slows writes. It does not trigger Lambda by itself: you run a poller (AWS provides a ready-made one that runs Lambda on a schedule).

The use cases, from the slide:

1. Send notifications when certain changes happen (a wallet linked to a flagged device → alert the fraud team).
2. Keep the graph data synchronised in another store: S3 for archives, OpenSearch for full-text search (a graph is not a search engine), ElastiCache for a cache.
3. Replicate across Regions into another Neptune cluster.

#Side notes: Neptune Serverless, Neptune Analytics, Global Database

#Amazon Keyspaces (for Apache Cassandra)

#Apache Cassandra in one minute

Apache Cassandra is an open-source, highly distributed wide-column NoSQL database. What makes it popular:

• Masterless: every node is equal and can accept reads and writes, data is spread over a ring of nodes by a hash of the partition key and copied to several of them. There is no single point of failure.
• Built for writes: writes are appended to a log and memory, so very write-heavy workloads at petabyte scale, across several data centres, are its home ground: IoT data logging, time-series tracking, messaging, activity feeds.
• Wide-column data model: a table has a partition key (decides which partition, and so which nodes, hold the row) and optional clustering columns (sort the rows inside a partition). You design one table per query, with data duplicated (denormalised) as needed, because there are no joins.
• CQL (Cassandra Query Language) looks like SQL: create table, insert, select … where ride_id = ….

The cost is operational: someone must run the cluster, patch and replace nodes, run repairs, tune compaction, add nodes before every peak and take backups.

#What Keyspaces manages for you

Amazon Keyspaces (for Apache Cassandra) is a managed, serverless, Cassandra-compatible database. No cluster to set up, no nodes to manage, no software to upgrade: you create keyspaces and tables and use CQL with the Cassandra drivers and cqlsh you already have, pointed at the Keyspaces endpoint (port 9142, TLS required, authentication with IAM through the SigV4 plugin or with service-specific credentials).

• Highly available: every write is stored three times across multiple AZs (writes always use LOCAL_QUORUM; reads can be LOCAL_QUORUM, ONE or LOCAL_ONE).
• Fast at any scale: single-digit millisecond latency, thousands of requests per second per table and more, virtually unlimited storage. Tables scale up and down automatically with traffic.
• Capacity: on-demand (pay per read and write, for unpredictable traffic) or provisioned with auto scaling (for predictable traffic, cheaper). You can switch a table’s mode once per day.
• Backups and security: encryption at rest (AWS-owned or your KMS key) and in transit always on; point-in-time recovery you enable per table, to any second of the last 35 days; TTL to expire rows; IAM and VPC endpoints.
• Multi-Region replication (2023): an active-active keyspace in several Regions, each Region reading and writing locally, changes usually replicated within a second, conflicts settled by timestamp (last writer wins). CDC streams (2025) publish row changes for other systems to consume.
• Not every Cassandra feature exists (no materialized views or user-defined functions, for example), so check compatibility first.

The notes say Keyspaces means not worrying about backups. More precisely: there is nothing to run, but you must turn PITR on; it is a setting, not a default.

#Why Keyspaces and not DynamoDB

Both are serverless, key-partitioned NoSQL services with single-digit millisecond latency, on-demand or provisioned capacity, PITR and multi-Region replication. The difference is the API: Keyspaces speaks CQL, so an existing Cassandra application moves with its code, drivers and data model intact. A new application with no Cassandra history usually chooses DynamoDB, which has the deeper AWS integration (Streams to Lambda, DAX, global tables, the serverless patterns of chapter 15). Against self-managed Cassandra on EC2, Keyspaces removes all the node operations.

#Amazon Timestream

#What time-series data is

Time-series data is a sequence of measurements, each stamped with a time: a meter’s kWh every minute, a server’s CPU every 10 seconds, a sensor’s temperature, page clicks as they happen. Its habits are different from business records:

• it arrives fast and continuously, and is almost only appended, rarely updated;
• it is queried by time window: the last hour, per 5 minutes, today against last week;
• recent data is hot and read constantly; old data is read rarely and should be cheap, then deleted.

A relational table can hold it, but at millions of rows a day the indexes, storage and deletes become a full-time job, and window queries slow down. A time-series database is built around these habits.

#Timestream for Live Analytics

Amazon Timestream for Live Analytics (the original Timestream, which the notes and slides describe) is a fully managed, serverless time-series database:

• No servers or capacity to manage: it scales up and down by itself, storing and analysing trillions of events per day. AWS claims up to 1,000 times faster and one tenth of the cost of relational databases for time-series work.
• Data model: a record has a time, dimensions that describe the source (meter_id, area) and one or more measures (kwh); multi-measure records keep several measures of one moment in one row.
• Storage tiering (the notes’ auto-tiering): recent data in the memory store, built for fast writes and point-in-time queries; when it is older than the memory retention, it moves automatically to the cost-optimised magnetic store, built for analytical queries over long periods. One query reads both. You set both retentions per table (memory from 1 hour to 1 year, magnetic from 1 day to 200 years); after the magnetic retention, data is deleted.
• Late-arriving data older than the memory retention is rejected unless magnetic store writes are enabled on the table.
• SQL with built-in time-series functions: bin(), ago(), interpolation to fill gaps, smoothing, trend and pattern analysis in near real time.
• Scheduled queries compute rollups (hourly averages, daily totals) into another table automatically, so dashboards read small tables.
• Encryption in transit and at rest always on (KMS keys for the magnetic store).

The notes’ uses: IoT sensor data (temperature, pressure), DevOps metrics (CPU and memory over time), e-commerce clickstream; the slides add operational applications and real-time analytics.

#The 2025 change: Live Analytics or InfluxDB

#The architecture: where the data comes from and goes

The slide’s architecture page, as a list:

• Into Timestream: AWS IoT Core (an IoT rule action writes device messages directly), Kinesis Data Streams (lesson 13.5) or Amazon MSK through Amazon Managed Service for Apache Flink (which aggregates the stream and writes the results; the slide uses its old name, Kinesis Data Analytics for Apache Flink), Lambda (any application event), Prometheus and Telegraf for infrastructure metrics.
• Out of Timestream: Amazon QuickSight for business dashboards, Grafana for operational dashboards, Amazon SageMaker for machine learning on historical series, and any JDBC client through the Timestream JDBC driver.

#Why Timestream and not RDS or DynamoDB

RDS can store readings, but leaves tiering, rollups and expiry to you, and its indexes grow with every insert. DynamoDB can store them by device and time (with TTL to expire them), but has no SQL aggregation across devices and time windows. Timestream does exactly those three things natively: cheap ageing storage, time functions, scheduled rollups.

#The four side by side

#What goes wrong

#Purpose-built databases in system design

• Polyglot persistence. One application, several databases, each holding what it is good at. The Dhaka shop: orders in Aurora (transactions), the catalogue in DocumentDB (documents), sessions and carts in DynamoDB or ElastiCache, “customers also bought” in Neptune (graph), delivery-bike location pings in Keyspaces, site metrics and clickstream in Timestream, reports in Redshift (lesson 17.2) and search in OpenSearch (lesson 17.3).
• One source of truth per fact. When the same data lives in two stores, decide which one is the truth and copy one way: Neptune Streams, DocumentDB change streams, DynamoDB Streams or Keyspaces CDC streams feed the others. Never write to two databases from the application and hope both succeed.
• Design from the questions. Documents for “show this object”, graphs for “follow connections”, wide-column for “write a lot, read by key”, time series for “what happened over time”. If the question list is long and ad hoc, a relational database or a warehouse may be better.
• Know the scaling model. DocumentDB and Neptune: one writer, many readers (or sharding with DocumentDB elastic clusters). Keyspaces and Timestream: serverless, scale writes too.
• Migration paths. MongoDB → DocumentDB (DMS, mongodump), Cassandra → Keyspaces (cqlsh copy, dsbulk, dual writes), time series → Timestream for InfluxDB; the migration chapter covers DMS (lesson 23.3).

#Try it yourself

Create one of each and run the query each one is good at. Output is shortened; names, endpoints and numbers are examples. Delete everything at the end: DocumentDB and Neptune instances bill by the hour.

1. 1. A DocumentDB cluster for the catalogue

   aws docdb create-db-cluster --db-cluster-identifier shop-catalog \
     --engine docdb --engine-version 5.0.0 \
     --master-username shopadmin --master-user-password 'choose-a-strong-one' \
     --vpc-security-group-ids sg-0abc1234example --db-subnet-group-name shop-db-subnets
   
   aws docdb create-db-instance --db-instance-identifier shop-catalog-1 \
     --db-cluster-identifier shop-catalog --engine docdb --db-instance-class db.t4g.medium
   

   "DBClusterIdentifier": "shop-catalog",
   "Endpoint": "shop-catalog.cluster-c1ab2cd3ef4g.ap-southeast-1.docdb.amazonaws.com",
   "ReaderEndpoint": "shop-catalog.cluster-ro-c1ab2cd3ef4g.ap-southeast-1.docdb.amazonaws.com",
   "Status": "creating"
   

   From an EC2 instance in the same VPC, connect with mongosh and TLS (download the CA bundle global-bundle.pem first), then insert two products of different shapes and query a nested field:

   mongosh "mongodb://shopadmin@shop-catalog.cluster-c1ab2cd3ef4g.ap-southeast-1.docdb.amazonaws.com:27017/?tls=true&tlsCAFile=global-bundle.pem&replicaSet=rs0&readPreference=secondaryPreferred&retryWrites=false"
   

   db.products.insertOne({ _id: "p-7001", type: "phone", name: "Walton Primo X", specs: { ram: 8, storage: 128 }, price: 18500 })
   db.products.insertOne({ _id: "p-8120", type: "saree", name: "Jamdani", fabric: "cotton", length_m: 5.5, price: 7200 })
   db.products.createIndex({ "specs.ram": 1 })
   db.products.find({ "specs.ram": { $gte: 8 } })
   // [ { _id: 'p-7001', type: 'phone', name: 'Walton Primo X', ... } ]
   

   Note retryWrites=false: DocumentDB does not support retryable writes.

2. 2. A Neptune cluster and a friend-of-friend query

   aws neptune create-db-cluster --db-cluster-identifier wallet-graph --engine neptune \
     --serverless-v2-scaling-configuration MinCapacity=1,MaxCapacity=8 \
     --vpc-security-group-ids sg-0abc1234example --db-subnet-group-name graph-subnets
   
   aws neptune create-db-instance --db-instance-identifier wallet-graph-1 \
     --db-cluster-identifier wallet-graph --engine neptune --db-instance-class db.serverless
   

   From inside the VPC, send openCypher over HTTPS to port 8182 (with IAM authentication enabled you would sign the request, for example with awscurl):

   curl -s https://wallet-graph.cluster-c1ab2cd3ef4g.ap-southeast-1.neptune.amazonaws.com:8182/openCypher \
     -d "query=CREATE (h:Person {name:'Hasan'})-[:KNOWS]->(r:Person {name:'Rina'})-[:KNOWS]->(m:Person {name:'Mitu'})"
   
   curl -s https://wallet-graph.cluster-c1ab2cd3ef4g.ap-southeast-1.neptune.amazonaws.com:8182/openCypher \
     -d "query=MATCH (:Person {name:'Hasan'})-[:KNOWS]->()-[:KNOWS]->(fof) RETURN fof.name"
   

   {"results":[{"fof.name":"Mitu"}]}
   

3. 3. Turn on Neptune Streams and read the change log

   aws neptune create-db-cluster-parameter-group --db-cluster-parameter-group-name graph-streams \
     --db-parameter-group-family neptune1.4 --description "streams on"
   aws neptune modify-db-cluster-parameter-group --db-cluster-parameter-group-name graph-streams \
     --parameters "ParameterName=neptune_streams,ParameterValue=1,ApplyMethod=pending-reboot" \
                  "ParameterName=neptune_streams_expiry_days,ParameterValue=14,ApplyMethod=pending-reboot"
   aws neptune modify-db-cluster --db-cluster-identifier wallet-graph \
     --db-cluster-parameter-group-name graph-streams
   aws neptune reboot-db-instance --db-instance-identifier wallet-graph-1
   

   After a new write, read the stream from the first commit:

   curl -s "https://wallet-graph.cluster-c1ab2cd3ef4g.ap-southeast-1.neptune.amazonaws.com:8182/propertygraph/stream?iteratorType=TRIM_HORIZON&limit=2"
   

   {"lastEventId":{"commitNum":12,"opNum":2},"lastTrxTimestamp":1793256300000,"format":"PG_JSON",
    "records":[{"eventId":{"commitNum":12,"opNum":1},"op":"ADD","data":{"id":"...","type":"vl","key":"label","value":{"value":"Person","dataType":"String"}}}, ...],
    "totalRecords":2}
   

   A reader stores commitNum as its checkpoint and next time asks for iteratorType=AFTER_SEQUENCE_NUMBER&commitNum=12.

4. 4. A Keyspaces table for ride pings

   aws keyspaces create-keyspace --keyspace-name rides
   
   aws keyspaces create-table --keyspace-name rides --table-name pings \
     --schema-definition 'allColumns=[{name=ride_id,type=text},{name=ts,type=timestamp},{name=lat,type=double},{name=lon,type=double}],partitionKeys=[{name=ride_id}],clusteringKeys=[{name=ts,orderBy=DESC}]' \
     --capacity-specification throughputMode=PAY_PER_REQUEST \
     --point-in-time-recovery status=ENABLED
   

   Connect with cqlsh (the cqlsh-expansion package adds TLS and the SigV4 plugin) and use plain CQL:

   pip install cqlsh-expansion
   cqlsh-expansion cassandra.ap-southeast-1.amazonaws.com 9142 --ssl --auth-provider SigV4AuthProvider
   

   CONSISTENCY LOCAL_QUORUM;
   INSERT INTO rides.pings (ride_id, ts, lat, lon) VALUES ('r-5001', '2026-10-29 18:04:12', 23.7949, 90.4043);
   INSERT INTO rides.pings (ride_id, ts, lat, lon) VALUES ('r-5001', '2026-10-29 18:04:16', 23.7941, 90.4055);
   SELECT ts, lat, lon FROM rides.pings WHERE ride_id = 'r-5001';
   --  ts                              | lat     | lon
   --  2026-10-29 18:04:16.000000+0000 | 23.7941 | 90.4055
   --  2026-10-29 18:04:12.000000+0000 | 23.7949 | 90.4043
   SELECT * FROM rides.pings WHERE lat > 23.79;
   -- InvalidRequest: ... use ALLOW FILTERING
   

   The second query has no partition key, so Keyspaces refuses it: exactly the design rule from the animation.

5. 5. Timestream: write readings and query by time window

   In an account that already uses Timestream for Live Analytics:

   aws timestream-write create-database --database-name smartmeter
   aws timestream-write create-table --database-name smartmeter --table-name readings \
     --retention-properties MemoryStoreRetentionPeriodInHours=24,MagneticStoreRetentionPeriodInDays=365 \
     --magnetic-store-write-properties EnableMagneticStoreWrites=true
   
   aws timestream-write write-records --database-name smartmeter --table-name readings \
     --records '[{"Dimensions":[{"Name":"meter_id","Value":"m-1001"},{"Name":"area","Value":"Mirpur"}],
                  "MeasureName":"kwh","MeasureValue":"0.42","MeasureValueType":"DOUBLE",
                  "Time":"1793257500000","TimeUnit":"MILLISECONDS"}]'
   
   aws timestream-query query --query-string \
     "SELECT area, bin(time, 5m) AS t, avg(measure_value::double) AS kwh FROM smartmeter.readings WHERE time > ago(1h) GROUP BY area, bin(time, 5m) ORDER BY t"
   

   "Rows": [ { "Data": [ {"ScalarValue": "Mirpur"}, {"ScalarValue": "2026-10-29 19:05:00.000000000"}, {"ScalarValue": "0.42"} ] } ]
   

   In a new account the first command fails, because Live Analytics no longer accepts new customers. There you create a managed InfluxDB instance instead:

   aws timestream-influxdb create-db-instance --name meters --db-instance-type db.influx.medium \
     --allocated-storage 20 --password 'choose-a-strong-one' \
     --vpc-subnet-ids subnet-0abc1234example --vpc-security-group-ids sg-0abc1234example
   

6. 6. Clean up

   aws docdb delete-db-instance --db-instance-identifier shop-catalog-1
   aws docdb delete-db-cluster --db-cluster-identifier shop-catalog --skip-final-snapshot
   aws neptune delete-db-instance --db-instance-identifier wallet-graph-1
   aws neptune delete-db-cluster --db-cluster-identifier wallet-graph --skip-final-snapshot
   aws keyspaces delete-keyspace --keyspace-name rides
   aws timestream-write delete-table --database-name smartmeter --table-name readings
   aws timestream-write delete-database --database-name smartmeter
   

#Summary

Key takeaways

• Purpose-built databases match the engine to the data’s shape: documents, graphs, wide-column, time series. The full decision map is lesson 16.1; real systems use several.
• DocumentDB = managed MongoDB-compatible JSON document database with Aurora’s architecture: one cluster volume, 6 copies in 3 AZs, grows automatically (to 128 TiB, 256 TiB on 8.0), one primary + up to 15 replicas, cluster and reader endpoints, fast failover. Elastic clusters shard, global clusters cross Regions, serverless is new. Keyword: MongoDB → DocumentDB.
• Neptune = managed graph database: billions of relationships, millisecond traversals, 15 read replicas across 3 AZs. Property graph with Gremlin / openCypher, RDF with SPARQL. Social networks, fraud, knowledge graphs, recommendations. SQL self-joins are the slow alternative.
• Neptune Streams = ordered, duplicate-free change log in the same transaction, read over HTTP REST; notify, sync to OpenSearch / S3 / ElastiCache, copy across Regions. Retention 7 days by default (1–90). Global Database is the managed cross-Region DR.
• Keyspaces = serverless, managed Apache Cassandra: CQL, port 9142 with TLS, 3 copies across AZs, single-digit ms, on-demand or provisioned, PITR 35 days, multi-Region active-active. Keyword: existing Cassandra → Keyspaces. No joins: one table per query.
• Timestream = serverless time-series database: memory store → magnetic store automatically, SQL with time functions (interpolation, smoothing), scheduled queries, trillions of events a day; fed by IoT Core, Kinesis, MSK + Flink, Lambda, Prometheus / Telegraf; read by QuickSight, Grafana, SageMaker, JDBC. Keywords: IoT, metrics over time, clickstream, time-stamped.
• 2025: Timestream for Live Analytics closed to new customers (20 June 2025); new projects use Timestream for InfluxDB. The exam answer is still “Timestream”.

Self-check: DocumentDB, Neptune, Keyspaces and Timestream30 questions