A social platform needs to model and query millions of user connections, likes, and follows to power a friend-of-friend recommendation feature, running queries like 'find people two connections away who share three or more mutual friends' with millisecond latency. Which AWS database service and query approach fits this best, and why?
- Amazon DynamoDB with a single global secondary index on the connection type, since key-value lookups are the fastest way to traverse multi-hop relationships
- Amazon Redshift, using SQL joins across a normalized schema of users and connections, since columnar storage and massively parallel processing make deep multi-hop joins fast at any depth
- Amazon Neptune, a purpose-built graph database supporting the Gremlin and openCypher property-graph query languages, optimized for traversing highly connected data with millisecond latency
- Amazon Aurora PostgreSQL, using recursive common table expressions (CTEs) over a foreign-key-linked users/connections schema to walk each hop of the friendship graph
Why C? And why not the others?
Correct answer: C. Amazon Neptune, a purpose-built graph database supporting the Gremlin and openCypher property-graph query languages, optimized for traversing highly connected data with millisecond latency
Amazon Neptune is a purpose-built graph database engine that indexes relationships directly and supports the property-graph query languages Gremlin and openCypher, letting it traverse highly connected data such as multi-hop friend networks with millisecond latency, which is exactly the recommendation query pattern described. The option describing DynamoDB with a global secondary index is wrong because a GSI supports efficient single-hop key-based lookups, but a multi-hop traversal like friends of friends would require the application to issue repeated round-trips and manually stitch the results together, which does not scale the way a native graph engine's relationship index does. The option describing Redshift is wrong because its columnar storage and massively parallel processing are tuned for scanning and aggregating large flat or star-schema datasets, not for recursively walking a graph of relationships hop by hop, which is a fundamentally different access pattern from analytical aggregation. The option describing Aurora PostgreSQL with recursive CTEs is wrong because although Aurora PostgreSQL can technically express a hop-by-hop traversal this way, performance degrades sharply as the relationship graph deepens since each hop requires another self-join over the full connections table, unlike a graph engine whose storage and indexes are built specifically for that traversal pattern.
Source: AWS Neptune documentation: What Is Amazon Neptune?