Graph queries - traversing relationships between entities - can be handled by both Neptune (a purpose-built graph database) and OpenSearch (which has graph-adjacent capabilities through nested documents and aggregations). The right choice depends on how central graph traversal is to your workload. Note that Amazon Neptune now comes in two engines: Neptune Database for transactional graph workloads, and Neptune Analytics, a memory-optimized engine for graph algorithms and vector similarity search.

Overview

AspectAmazon NeptuneOpenSearch
TypePurpose-built graph databaseSearch and analytics engine
Data ModelProperty graph or RDFDocument-oriented (JSON)
Query LanguagesGremlin, SPARQL, openCypherOpenSearch DSL, SQL
Graph TraversalNative, multi-hopLimited (nested, joins)
Full-Text SearchBasicAdvanced
Vector SearchYes, via Neptune Analyticsk-NN plugin (Faiss, NMSLIB, Lucene)
ScalingRead replicasSharding + replicas

Graph Data Modeling

Neptune supports two graph models. Property graphs store vertices and edges with properties, queried via Gremlin or openCypher. RDF graphs store triples (subject-predicate-object), queried via SPARQL. Both models excel at representing and traversing complex relationships.

OpenSearch uses JSON documents. You can model relationships through nested objects, parent-child relationships, or denormalized documents. However, these are not true graph relationships. Multi-hop traversals (find all users connected to user A through three degrees of connection) are not feasible in OpenSearch.

Query Capabilities

Neptune handles complex graph queries efficiently: shortest path, connected components, centrality measures, pattern matching, and recursive traversals. A query like “find all entities within 3 hops of entity X that match criteria Y” is straightforward and performant.

OpenSearch excels at search, filtering, and aggregation across documents. It can answer “find all documents related to entity X” through term queries and aggregations, but cannot natively traverse relationship chains. Graph-like queries require multiple round-trips or denormalized data structures.

AI and Knowledge Graph Use Cases

Neptune is the natural choice for knowledge graphs that power AI applications. Entity resolution, recommendation engines based on relationship traversal, fraud detection through network analysis, and ontology-based reasoning all leverage Neptune’s graph capabilities. Neptune ML trains Graph Neural Networks (GNNs) with the Deep Graph Library (DGL), powered by Amazon SageMaker, to make predictions on graph data. Neptune Analytics adds native vector similarity search alongside the graph, so you can combine graph traversal for domain context with nearest-neighbor search over embeddings (for example, embeddings generated by models in Amazon Bedrock) in a single store. This is the foundation of GraphRAG: Amazon Bedrock Knowledge Bases reached general availability of a managed GraphRAG capability in March 2025 that uses Neptune Analytics to store both vector embeddings and an entity-relationship graph, blending vector similarity with graph traversal for higher retrieval accuracy.

OpenSearch serves AI use cases centered on search and retrieval: RAG pipelines, semantic search, log analysis, and anomaly detection. Its k-NN, Neural Search, and ML Commons plugins support dense and sparse embedding-based similarity queries, and hybrid lexical plus semantic search. The practical distinction is no longer “only OpenSearch has vectors”: it is that OpenSearch is built around document search and ranking, while Neptune’s vector search is built around augmenting graph traversal.

Combining Both

Some architectures use Neptune for relationship data and OpenSearch for search and vector capabilities. A knowledge graph in Neptune stores entity relationships. OpenSearch indexes the same entities for full-text search and vector similarity. A query layer combines results from both services. Since Neptune Analytics gained native vector search, a single store can now also serve both graph traversal and vector similarity, which is what the managed GraphRAG integration in Amazon Bedrock Knowledge Bases does under the hood. The two-service split still makes sense when you need OpenSearch’s advanced full-text ranking, log analytics, or its broader hybrid search tooling.

When to Choose Neptune

Choose Neptune when your core use case is relationship traversal - knowledge graphs, social network analysis, fraud detection networks, recommendation engines based on graph patterns, or identity resolution. Neptune is essential when you need multi-hop queries, path analysis, or graph algorithms.

When to Choose OpenSearch

Choose OpenSearch when your primary needs are search, filtering, and aggregation rather than relationship traversal. If your “graph” requirements are limited to finding related documents or entities without deep traversal, OpenSearch’s document model is sufficient and avoids the operational overhead of a separate graph database.

Practical Recommendation

If you need to answer questions about relationships between entities (who is connected to whom, what is the shortest path, which entities form clusters), Neptune is the right tool. If you need to find entities by attributes, content, or vector similarity, OpenSearch is the right tool. For AI applications that need both relationship reasoning and semantic search, you have two paths: run both services with a shared entity identifier scheme, or use Neptune Analytics (directly, or through the GraphRAG capability in Amazon Bedrock Knowledge Bases) to combine graph traversal and vector search in one store.

See Also

Sources and Further Reading