Neptune
Managed graph database (Gremlin, openCypher, SPARQL).
Problem it solves: Multi-hop joins are slow in relational stores.
Where it sits: Behind services.
When to use
- Relationship-heavy queries.
When not to use
- Simple key lookups.
Failure modes
- Supernodes create hotspots.
Metrics to watch
- Traversal latency
Alternatives
- Adjacency lists in KV
Configuration in Labs (illustrative defaults)
- Capacity per instance (req/s) = 2000 — Maximum requests one instance completes per second before it saturates.
- Write capacity (primary) (writes/s) = 500 — Writes the single primary can absorb per shard. Replicas do not add write capacity.
- Read replicas (count) = 1 — Each replica adds one instance of read capacity. Replication lag is not modelled numerically.
- Base service time (ms) = 10 — Processing time per request at zero load. Queueing adds to this as utilisation rises.
Vendor examples (pattern only): AWS managed service. Simulated as a generic “Graph store”.