A historic ferry-landing archive is a graph of boats, slips, and crews, and staff also want notes like this repair paragraph. Which AWS store fits relationship-first knowledge that still needs vector retrieval?
Select an answer to reveal the explanation.
Short Explanation
Think of boats, slips, and crews as a graph, plus notes like this repair paragraph. Amazon Neptune. A dashboard and a flat CSV drop those relationships.
Full Explanation
Amazon Neptune fits relationship-first knowledge where boats, slips, and crews form a graph and staff still need vector retrieval over narrative repair notes. Neptune models edges and multi-hop paths (which crew worked which slip, which vessel ties to which repair lineage) while also supporting vector search patterns for unstructured note text. The ferry-landing archive is fundamentally about relationships; a graph store keeps those links first-class instead of flattening them away.
A QuickSight dashboard charts metrics—it is not a graph of boats and slips and cannot traverse crew relationships or retrieve note embeddings as a knowledge store. Amazon Polly produces speech audio; it does not persist crew relationships or answer graph queries. A single flat CSV with no relationships discards the multi-hop structure that makes the archive useful and cannot honestly claim to be a graph-plus-vector knowledge base.
Exam caveat: pick Neptune when the primary access pattern is relationship traversal (or graph analytics) with optional vectors on node/edge properties; if the workload is mostly keyword search over documents with light metadata, OpenSearch may be the simpler fit.
Operational check: load a small subgraph of boats–slips–crews plus a handful of repair paragraphs, run a multi-hop path query and a vector similarity lookup on a known repair note, and verify both return coherent results before migrating the full historic landing archive.