Amazon Neptune is AWS’s fully managed graph database, and its product page now leads with a single headline use case: Graphs for AI, meaning GraphRAG and long-term agent memory delivered through Amazon Bedrock Knowledge Bases. Underneath that pitch are two distinct products. Neptune Database handles transactional graph storage with Gremlin, openCypher, and SPARQL; Neptune Analytics is the in-memory engine behind GraphRAG and vector search, and it answers openCypher only. AWS also ships an Amazon Neptune MCP Server for both. This page covers what that positioning actually means, and what it doesn’t solve.
Most explainers of “what Neptune is used for” still describe it as one general-purpose graph database, a framing AWS itself moved past when Graphs for AI became the lead use case on the product page. That gap is where this page sits: not another AWS-docs rehash, and not a Neptune-versus-everything shootout, but the mechanics AWS keeps siloed across separate pages, plus the tradeoffs its own marketing page never states.
- Two products, one brand name: Neptune Database (transactional) and Neptune Analytics (in-memory GraphRAG and vector search) get described as a single product in most third-party explainers
- Real production evidence: Wiz, Trend Micro, and Coinbase all run Neptune in production for security, support, and clustering workloads, not just AWS demo scenarios
- Real limitations AWS documents but doesn’t advertise: no built-in OWL reasoner, Neptune Analytics capacity that does not autoscale, and VPC-only, IAM-only access
- A freshness gap most coverage misses: AWS shipped an Amazon Neptune MCP Server in May 2025, and almost no third-party explainer mentions it
- The governance question underneath: a graph that improves AI accuracy still needs something deciding what an agent is allowed to retrieve from it
- A related but different question: what a knowledge graph is and what a graph database like Neptune stores are related, but not identical, questions
Below: what Neptune is used for, how its two products differ, whether it can power GraphRAG, real production deployments, how its architecture compares to the alternative most often raised, its limitations, and where a governed context layer fits above the graph.
| Field | Detail |
|---|---|
| What it is | AWS’s fully managed graph database service, actually two products: Neptune Database and Neptune Analytics |
| Current positioning | “Graphs for AI”, GraphRAG and long-term agent memory via Amazon Bedrock Knowledge Bases, listed ahead of Customer 360, fraud detection, and cybersecurity on the product page |
| Query languages | Neptune Database: Gremlin (TinkerPop 3.3), openCypher v9, and SPARQL 1.1. Neptune Analytics: openCypher only |
| Agent access | Amazon Neptune MCP Server, shipped 2025-05-28: openCypher and Gremlin against Neptune Database, openCypher against Neptune Analytics, plus schema discovery |
| Scale | 100k+ queries per second, unlimited vertices and edges, up to 128 TiB storage per cluster, up to 15 read replicas |
| Production use | Wiz’s Security Graph (hundreds of billions of relationships; 40% faster investigations from the Bedrock AI layer built on top of it), Trend Micro’s Companion AI (20% better answer quality), Coinbase’s user-clustering system |
| Deployment model | Fully managed by AWS. Neptune Database runs on provisioned instances or Neptune Serverless (1 to 128 NCUs); Neptune Analytics is provisioned in m-NCU and does not autoscale |
What is Amazon Neptune used for?
Amazon Neptune is AWS’s fully managed graph database, and the headline use case on its product page is now “Graphs for AI”: GraphRAG and long-term agent memory, listed ahead of the three use cases that used to define it, Customer 360, fraud detection, and cybersecurity.
AWS’s own product page now leads with Graphs for AI instead of the older “general graph database for connected data” framing, and names four official use cases in this order: Graphs for AI, Customer 360, Fraud Detection, and Cybersecurity. AWS has published no announcement dating that reordering, so treat the order as current fact rather than a datable pivot. The capability underneath shipped earlier: Bedrock Knowledge Bases GraphRAG entered preview in December 2024 and went generally available on 7 March 2025.
No independent, non-AWS source has reframed “what Neptune is used for” around this shift yet. Most third-party tutorials and certification-prep content still describe Neptune as a general-purpose graph database, the same framing AWS itself has already moved past. That gap is structural, not a matter of any one article being outdated: AWS controls the definitional query, so anyone answering it starts from AWS’s own copy.
A graph engine like Neptune decides how data connects. What it doesn’t decide, on its own, is which of those connections an agent is allowed to use, a distinction that matters more as “Graphs for AI” becomes the reason teams adopt Neptune in the first place. What a context graph adds on top of a graph database is exactly that missing layer, and it’s a question worth asking before the graph is already in production.
What’s the difference between Neptune Database and Neptune Analytics?
“Amazon Neptune” is really two separate products under one brand: Neptune Database for transactional graph storage, and Neptune Analytics for the in-memory, vector-search-enabled layer that GraphRAG workloads actually run on. Most explainers of “what Neptune is used for” collapse that distinction, which is exactly where readers get confused about how GraphRAG on Neptune actually works.
Neptune Database is the original product: an OLTP-style transactional graph store, purpose-built for high-throughput read and write graph workloads like fraud detection, recommendation, and Customer 360. It supports Gremlin, openCypher, and SPARQL, according to AWS’s Neptune Features page. Neptune Analytics is the newer, purpose-built analytics engine: memory-optimised, with vector search running inside graph traversals, designed for the graph-traversal-plus-similarity-search pattern GraphRAG needs, similar in spirit to how a vector database handles similarity search on its own, per AWS’s Neptune Analytics documentation. One difference the two-products framing usually hides: Neptune Analytics imports RDF but does not answer SPARQL queries, so every query against it is openCypher.
That distinction matters for the AI-agent framing specifically. Amazon Bedrock Knowledge Bases’ GraphRAG capability runs on Neptune Analytics, not the transactional Neptune Database product: AWS’s general-availability announcement states that Bedrock “automatically generates and stores vector embeddings in Amazon Neptune Analytics”[5]. It is a detail AWS keeps siloed across separate documentation pages rather than stating plainly in one place. A reader who only knows “Amazon Neptune” as one thing has no way to know which half of it their GraphRAG pipeline is actually running on.
Both products still sit on the storage side of a bigger distinction: the difference between a knowledge graph and a graph database, where the database stores and traverses connections and the knowledge graph adds semantic meaning on top. Neptune Database and Neptune Analytics both answer “how do I store and query a graph.” Neither answers “what does this connection mean, and who’s allowed to see it,” which is the layer this page returns to after the mechanics are settled. How that graph actually gets built in the first place, from source documents into vertices and edges, is a separate step from which product stores it; knowledge graph construction for AI already covers that step in detail, including an AWS Neptune plus Comprehend construction pattern.
| Aspect | Neptune Database | Neptune Analytics |
|---|---|---|
| Purpose | Transactional (OLTP) graph storage | In-memory analytics and GraphRAG substrate |
| Query languages | Gremlin, openCypher, SPARQL 1.1 | openCypher only; RDF imports, but no SPARQL queries |
| Data model | Property graph and RDF | Property graph, optimized for traversal plus similarity search |
| Typical use case | Fraud detection, Customer 360, recommendation engines | GraphRAG, agent long-term memory, graph analytics at scale |
| Scaling model | Provisioned instances or Neptune Serverless (1 to 128 NCUs), up to 15 read replicas | Provisioned in m-NCU (16 to 24,576); AWS states autoscaling is not supported |
Two products, one governance question
See how enterprises are thinking about the layer that governs context across every graph, warehouse, and lakehouse a team runs.
Get the AI Context StackCan Amazon Neptune power GraphRAG and AI agent memory?
Yes. Amazon Bedrock Knowledge Bases offers a fully managed GraphRAG capability that runs on Neptune Analytics, Neptune ships its own MCP server for agents that need to query the graph directly, and teams pair Neptune with memory frameworks like Mem0 to give agents long-term, graph-structured memory.
The managed path is simple by design: point a Bedrock Knowledge Base at an S3 location, and Bedrock handles chunking and builds the GraphRAG retrieval workflow on Neptune Analytics, no separate graph-database setup required, according to AWS’s own GraphRAG build guide. Brad Bebee, General Manager of Amazon Neptune at AWS, frames the underlying reason graph retrieval matters at all: “If you think about vector similarity search as compared to graph search, in a vector, similarity is defined by mathematical distance in a really high dimensional space… You create a knowledge base using Amazon Bedrock, and you simply give it S3 location with documents; it does the chunking and builds the retrieval augmented generation workflow,” he told The Stack.
Beyond the managed GraphRAG path, teams pair Neptune with Mem0 to give agents company-wide, persistent memory structured as a graph rather than a flat vector store, per AWS’s machine learning blog. That pattern sits inside the broader question of what agent memory actually needs to persist across sessions, and how agent memory architectures choose between graph-structured and vector-only approaches; the best AI agent memory frameworks working with Neptune, including Mem0, sit inside that broader landscape rather than replacing it. Teams weighing vector store versus graph database for that memory layer, or comparing AI memory, RAG, and knowledge graphs more broadly, land on a similar answer either way: the storage pattern matters less than what governs what gets retrieved from it.
The piece most coverage of Neptune still misses is the delivery protocol. AWS shipped an Amazon Neptune MCP Server on 28 May 2025, in every region Neptune runs in: openCypher and Gremlin against Neptune Database, openCypher against Neptune Analytics, plus schema discovery and natural-language querying. AWS’s product page now also leads agent memory with integrations to the Strands Agents SDK alongside third-party memory tools. So the engine speaks MCP natively, which sharpens rather than settles the question above it. An MCP server exposes what the graph holds. It does not carry what a connection means to the business, who owns the upstream asset, or which agent should be allowed to see it.
Whatever graph an agent’s memory runs on, something still has to decide what that agent is allowed to retrieve from it. That’s a separate layer from the graph engine itself, and it’s the layer this page comes back to once the production evidence and the tradeoffs are both on the table.
What are Amazon Neptune’s real-world use cases?
Beyond AWS’s own framing, three named production deployments show what “Graphs for AI” actually looks like in practice: Wiz’s cloud-security graph, Trend Micro’s Companion AI assistant, and Coinbase’s user-clustering system.
Wiz’s Security Graph, built on Neptune, analyzes “hundreds of billions of relationships,” according to AWS’s Database Blog, co-authored with Wiz CTO Ami Luttwak. The often-cited 40% figure sits one layer up from the graph itself: it’s the reduction in investigation time Wiz reports from the Bedrock-powered AI remediation guidance it built on top of that Neptune-backed graph, not from Neptune’s traversal alone, per AWS’s Wiz case study. Trend Micro’s Companion AI assistant saw a 20% improvement in answer quality after adopting Neptune with Bedrock. Shawn Tsai, Senior Architect at Trend Micro, put it this way in AWS’s published case study: “By using Amazon Neptune along with Amazon Bedrock, we can turn vast security data and knowledge gained over the years into actionable insights and democratize security best practices.”
Coinbase took a different route: it migrated its user-clustering system to Neptune Database specifically to handle interconnected data at scale, a Customer-360-adjacent use case rather than an AI-agent one, per AWS’s Database Blog. That detail matters because it shows the Graphs for AI positioning sits alongside Neptune’s older use cases rather than replacing them; Coinbase’s use case has nothing to do with GraphRAG at all.
Trend Micro’s result is the one that connects most directly to Neptune’s own claim of improving AI agent accuracy: better-connected data producing a measurably better answer is one concrete version of the broader argument that ungoverned context, not the model, is usually behind why AI agents fail in production and drive AI agent hallucination. But production evidence at three companies isn’t the same as a guarantee it will work the same way at a fourth, and that’s precisely where the honest tradeoffs later in this page come in.
Not sure what your agents can already reach?
Run a quick assessment on how governed your current context layer is before scaling agent workloads on top of a graph.
Take the Maturity AssessmentWhat’s the difference between Amazon Neptune and Neo4j?
The two differ most in architecture. Neptune’s compute and storage are decoupled and fully managed by AWS, while Neo4j and its managed AuraDB use index-free adjacency with a more tightly coupled engine, and that architectural choice shows up in real, measurable tradeoffs rather than a simple better-or-worse answer.
Neptune’s decoupled compute and storage model is what deep AWS-ecosystem integration, S3, Glue, SageMaker, Bedrock, is built on top of; Neo4j’s more tightly coupled, JVM-based engine trades some of that elasticity for different latency characteristics. On raw speed, there is no independent benchmark worth quoting. The figures that circulate comparing the two trace back to competitor comparison pages and anonymous forum posts, with no named tester, no methodology and no date. The only citable performance statement is AWS’s own: a Neptune engine release delivering “up to 9 times faster and 10 times higher throughput for openCypher query performance.” That is a vendor number about its own engine versions, not a cross-vendor comparison, and it should be read as one.
This page doesn’t re-run the full feature-by-feature comparison. Two sibling pages already own that depth: Knowledge Graph Tools Compared covers the broader landscape, Neo4j, Stardog, Neptune, and GraphDB among them, and Neo4j GraphRAG vs. LlamaIndex vs. LangChain Graph Transformer covers the construction-library side of the Neo4j GraphRAG stack in detail. For teams evaluating Neo4j specifically for agent context graphs, that comparison goes deeper than this page needs to.
Teams actually building a graph from scratch, rather than choosing between vendors, are better served starting with how to build a knowledge graph for AI agents, which references Neptune as one storage option among several, or with the distinction a context graph draws from a knowledge graph before picking a database at all.
What are Amazon Neptune’s limitations?
One tradeoff AWS’s Graphs for AI framing leaves implicit: Neptune stores and queries RDF, but it does not reason over it. Anything requiring OWL inference has to run outside the database.
Neptune stores RDF triples and answers SPARQL 1.1, but it does not reason over them. AWS states that Neptune includes no built-in OWL reasoner, and that ontology inference, class subsumption and property inheritance, has to run externally in an engine like HermiT, Pellet or ELK, or be pre-materialized as inferred triples before the data is loaded, per AWS Prescriptive Guidance. There is no partial reasoning tier underneath that. A team expecting standard RDF reasoning out of the box builds that step itself.
Two operational constraints belong next to it, both documented by AWS. Neptune Analytics, the edition GraphRAG runs on, is provisioned capacity measured in m-NCU, and AWS states plainly that autoscaling is not supported for Neptune Analytics graphs. And Neptune is reachable only inside a VPC, over TLS 1.2, authenticated through IAM: AWS’s own limits page says Neptune “does not support user name/password-based access control.”
Getting data out, by contrast, is a documented path rather than a dead end. Neptune supports native export plus the neptune-export service and command-line tool, both writing to S3, with cluster cloning to keep the export consistent. The lock-in that remains is architectural, VPC-only access and IAM-only authentication, rather than a data-egress problem. None of this is a reason to avoid Neptune.
It’s a reason to know, before committing, that the semantic enforcement a semantic layer provides and the reasoning depth an ontology needs both sit above what Neptune natively delivers. AWS documents the same architecture in its own Prescriptive Guidance, recommending Neptune as the authoritative RDF store with inferred triples pre-materialized before load. That’s the same gap ontology-first design and ontology-versus-knowledge-graph thinking both address directly, and one that shows up again in how a metadata knowledge graph extends a raw graph database with the business context Neptune itself doesn’t track.
| What AWS’s positioning says | What the fuller picture is | Source |
|---|---|---|
| SPARQL 1.1 support for RDF graphs | No built-in OWL reasoner. Ontology inference must run externally or be pre-materialized as inferred triples before load | AWS Prescriptive Guidance, May 2026 |
| Neptune Analytics as the GraphRAG substrate | Provisioned in m-NCU, 16 to 24,576, and AWS states autoscaling is not supported for Neptune Analytics graphs | AWS Bedrock user guide |
| Fully managed, elastic graph performance | No independent cross-vendor benchmark exists. AWS’s own engine-release claim is up to 9x faster openCypher performance, vendor-published | AWS Database Blog |
| Deep AWS ecosystem integration | Export is documented and supported, through native export and the neptune-export service and CLI, both writing to S3. The binding constraint is VPC-only, IAM-only access |
AWS Neptune Developer Guide |
How Atlan approaches governance for graphs like Amazon Neptune
Neptune’s missing reasoner, the gap that lets it answer SPARQL without reasoning over what it stores, is one concrete example of a broader pattern: a graph database’s query languages describe how nodes connect, not what those connections mean to the business or who should be allowed to act on them. Those are two separate open questions Neptune’s marketing doesn’t answer, not one. The first is semantic: whether the graph carries the business meaning a person or an agent needs to interpret a connection correctly. The second is governance: what decides which parts of that graph an agent is allowed to retrieve from, and under whose policy. Neither is a Neptune-specific flaw; both sit above any graph engine, why AI agents need an enterprise context layer covers why, and it’s why the enterprise context layer sits above the graph rather than replacing it.
Atlan’s Enterprise Data Graph connects assets, lineage, business glossary terms, policies, and ownership into one governed graph that sits above whatever storage and traversal engine a team runs, Neptune or anything else. The business glossary layer addresses the semantic question, giving nodes and edges business definitions a raw graph database doesn’t carry on its own; it isn’t a substitute for an OWL reasoner, and doesn’t claim to be. A team can run Neptune underneath Atlan’s Enterprise Data Graph the same way a storage-and-traversal engine sits beneath a governed context-delivery layer.
The governance question is handled separately, through access policies and ownership rather than through the glossary. Atlan’s MCP server pattern delivers that governed context to AI agents the same way regardless of which underlying graph engine, including Neptune, a team runs, which is the same infrastructure question behind how to implement an enterprise context layer for AI and what context engineering actually means in practice. Teams asking whether their knowledge graphs are actually ready for that layer face the same test AI readiness versus knowledge graphs lays out, independent of which graph database sits underneath.
The two solve different halves. Neptune is graph storage and traversal infrastructure; Atlan governs what context gets delivered from it, the same relationship teams hit once they move past a single agent into a full AI agent harness. No customer has published a case study naming Neptune specifically, so the two accounts below speak to the same governed-context pattern in general, business glossary and MCP-delivered context at enterprise scale, rather than to Neptune by name.
See the context layer in action
Watch how Atlan governs the retrieval layer that graph databases like Neptune feed into, whatever query language sits underneath.
Watch the Demo SeriesThe graph engine question Amazon Neptune’s 2026 pitch doesn’t answer
Amazon Neptune’s 2026 story is really two products under one name: Neptune Database for transactional graph storage, and Neptune Analytics for the in-memory, vector-search substrate that GraphRAG and agent memory actually run on through Amazon Bedrock Knowledge Bases. The move from “general graph database” to “Graphs for AI” on AWS’s own product page is backed by real production evidence at Wiz, Trend Micro, and Coinbase, and AWS now ships an MCP server so agents can reach both editions directly. What the pitch leaves out is also documented by AWS: no built-in OWL reasoner, Neptune Analytics capacity that does not autoscale, and access confined to a VPC with IAM authentication only.
None of that makes Neptune the wrong choice. It means a graph that improves AI accuracy still needs a separate layer deciding what an agent can retrieve from it, a question that sits above the graph engine, not inside it, regardless of which vendor built the graph.
Put a number on the governance gap
See what a governed context layer above Neptune, or any graph, is worth before you scale agent workloads on top of it.
Calculate Your ROIFAQs about Amazon Neptune graph database
1. What is Amazon Neptune used for?
Amazon Neptune is AWS’s fully managed graph database, and its product page now leads with “Graphs for AI”, GraphRAG and long-term AI-agent memory via Amazon Bedrock Knowledge Bases. It’s also used for Customer 360, fraud detection, and cybersecurity graphs. Production examples include Wiz’s Security Graph, Trend Micro’s Companion AI assistant, and Coinbase’s user-clustering system.
2. Is Amazon Neptune a NoSQL database?
Yes, Neptune is a NoSQL, purpose-built graph database, not a relational database. It stores data as vertices and edges (property graph) or as RDF triples. Neptune Database supports Gremlin, openCypher, and SPARQL rather than SQL; Neptune Analytics is openCypher-only and does not answer SPARQL queries.
3. What is the difference between Amazon Neptune and Neo4j?
The two differ mainly in architecture: Neptune uses a decoupled, fully managed compute and storage model, while Neo4j and AuraDB use index-free adjacency with a more tightly coupled engine. No independent benchmark settles the latency comparison. AWS publishes its own claim of up to 9 times faster openCypher performance on a recent engine release, which is a vendor number, not a neutral one.
4. Does Amazon Neptune support SPARQL?
Yes. Neptune Database supports SPARQL 1.1 Query and Update for RDF graphs, alongside Gremlin and openCypher, in one managed service. Neptune Analytics imports RDF but answers only openCypher. Neptune stores triples without reasoning over them: AWS states it includes no built-in OWL reasoner, so ontology inference has to run externally or be pre-materialized before load.
5. What is Neptune Analytics vs. Neptune Database?
Neptune Database is the original transactional graph store, built for high-throughput fraud detection, recommendation, and Customer 360 workloads. Neptune Analytics is the newer, memory-optimised engine with native vector search, purpose-built for GraphRAG and graph analytics at scale, and it’s what Amazon Bedrock Knowledge Bases’ GraphRAG capability actually runs on underneath. It is provisioned in m-NCU rather than autoscaled: AWS states that autoscaling is not supported for Neptune Analytics graphs.
6. Can Amazon Neptune be used for GraphRAG?
Yes. Amazon Bedrock Knowledge Bases offers a fully managed GraphRAG capability running on Neptune Analytics: point it at an S3 location and Bedrock handles chunking and builds the retrieval-augmented-generation workflow automatically. AWS also ships an Amazon Neptune MCP Server, so an agent framework can query either edition and discover its schema over MCP. Teams pair Neptune with the Strands Agents SDK and with memory tools like Mem0 for graph-structured, persistent agent memory.
7. What are Amazon Neptune’s biggest limitations?
Three are documented by AWS itself. Neptune has no built-in OWL reasoner, so ontology inference runs externally or gets pre-materialized before load. Neptune Analytics is provisioned capacity and does not autoscale. And access is VPC-only over TLS 1.2, with IAM authentication and no username-and-password path, which is a real constraint on how the graph gets reached from outside AWS.
Sources
- Amazon Neptune product page, AWS
- Semantic layer for agentic AI: technology tradeoffs and alternatives, AWS Prescriptive Guidance (May 2026)
- Amazon Neptune Features, AWS
- What is Neptune Analytics?, AWS Docs
- Announcing general availability of Amazon Bedrock Knowledge Bases GraphRAG with Amazon Neptune Analytics, AWS, 2025-03-07
- Amazon Neptune: An overlooked AI accuracy game-changer? Interview with Brad Bebee, GM of Amazon Neptune, The Stack
- Company-wise memory in Amazon Bedrock with Amazon Neptune and Mem0, AWS Machine Learning Blog
- Build GraphRAG Applications with Amazon Neptune and Amazon Bedrock, AWS Builder Center
- The world is a graph: how Wiz reimagines cloud security using a graph in Amazon Neptune, AWS Database Blog
- Reimagining cloud security using Amazon Neptune graph database with Wiz, AWS case study
- Building an agentic AI solution using Amazon Neptune with Trend Micro, AWS case study
- How Coinbase provides trustworthy financial experiences through real-time user clustering with Amazon Neptune, AWS Database Blog, 2024-11-18
- Amazon Neptune MCP Server, AWS What’s New, 2025-05-28
- Amazon Neptune limits, AWS Docs
- Exporting data from Neptune, AWS Docs
- New Amazon Neptune engine version delivers up to 9x faster openCypher query performance, AWS Database Blog
