Amazon Neptune - Graph Database for AI Applications
A comprehensive reference for Amazon Neptune: graph data modeling, knowledge graphs, fraud detection patterns, and integration with AI/ML workflows.
Amazon Neptune is a fully managed graph database service that supports both property graph (using Apache TinkerPop Gremlin) and RDF graph (using SPARQL) models. For AI projects, Neptune excels at representing and querying complex relationships: knowledge graphs for RAG systems, fraud detection networks, recommendation engines based on social connections, and identity resolution across disparate data sources.
Official documentation: https://docs.aws.amazon.com/neptune/ Pricing: https://aws.amazon.com/neptune/pricing/ Service quotas: https://docs.aws.amazon.com/neptune/latest/userguide/limits.html
Core Concepts
Cluster - A Neptune cluster consists of a primary writer instance and up to 15 read replicas. Storage is managed automatically and scales up to 128 TB. The architecture is similar to Amazon Aurora, providing high availability with automatic failover.
Property Graph - The most common model for application workloads. Nodes (vertices) represent entities, edges represent relationships, and both can have key-value properties. Queried using Gremlin traversal language or the newer openCypher query language.
RDF Graph - Resource Description Framework model, queried using SPARQL. Better suited for ontology-driven data models, linked data, and scenarios where data interoperability across organizations matters (common in healthcare, government, and research).
Neptune ML - A built-in integration with SageMaker that enables graph neural network (GNN) training directly on Neptune data. Neptune ML exports graph data, trains GNN models in SageMaker, and deploys them as Neptune query endpoints. This enables ML predictions (link prediction, node classification, node regression) through graph queries.
Knowledge Graphs for RAG
One of the most valuable AI applications of Neptune is building knowledge graphs that enhance retrieval-augmented generation. While vector search retrieves documents based on semantic similarity, a knowledge graph retrieves based on structured relationships. Combining both approaches produces more accurate and complete answers.
The pattern works as follows: extract entities and relationships from documents using NLP (Bedrock or Comprehend), store them as nodes and edges in Neptune, and at query time, traverse the graph to find relevant entities and their connections. Pass this structured context to the foundation model alongside vector-retrieved passages.
For example, in a financial services context, a question about “exposure to Company X” benefits from graph traversal that follows ownership chains, subsidiary relationships, and counterparty connections that vector search alone would miss.
Fraud Detection Patterns
Graph databases are exceptionally effective for fraud detection because fraud often involves coordinated networks of entities. Patterns that are invisible in tabular data become obvious in a graph: multiple accounts sharing the same device fingerprint, phone number, or IP address within a short time window.
A typical fraud detection query in Gremlin traverses from a suspicious transaction to the account, then to shared attributes (email domain, device, address), then to other accounts sharing those attributes, looking for clusters of connected entities with suspicious characteristics. Neptune’s optimized graph storage makes these multi-hop traversals fast even at scale.
Neptune Serverless
Neptune Serverless automatically scales compute capacity based on workload. It eliminates the need to provision instance sizes and handles traffic spikes without manual intervention. For AI projects with variable query patterns (heavy during model training data extraction, light during inference), serverless can significantly reduce costs compared to provisioned instances.
Neptune Serverless scales in Neptune Capacity Units (NCUs) between a configured minimum and maximum. Set the minimum low for development environments and higher for production workloads with latency requirements.
Query Language Choice
Gremlin is the standard for property graph traversals. It uses an imperative, step-by-step traversal syntax. Most application developers find it intuitive for path-finding and neighborhood queries.
openCypher provides a more declarative SQL-like syntax for property graphs. It is often easier to read and write for developers coming from a SQL background. Neptune supports openCypher natively.
SPARQL is the choice for RDF data models. Use it when your data model is ontology-driven or when you need to integrate with linked data standards.
Pricing
Neptune charges for instance hours (or NCUs for serverless), storage, I/O operations, and data transfer. For graph workloads, the instance size is the primary cost driver. Start with a smaller instance for development and right-size based on query latency requirements. Neptune ML incurs additional SageMaker costs for model training.
Need help implementing this?
Turn this knowledge into a working prototype. Our structured workshop methodology takes you from idea to deployed AI solution in three sessions.
Explore AI Workshops