SysPad › Lessons › database lessons › Neptune

How Neptune works

Managed graph database for highly connected data (Gremlin, openCypher, SPARQL). Cluster of a writer plus read replicas over shared storage. Multi-hop traversals are heavier than key lookups - tune query time and replicas.

Some questions are really about connections: friends of friends, the path between two accounts, what tends to be bought together. In a relational database those become brutal chains of self-joins. Neptune stores the relationships themselves as first-class data, so the question becomes a short walk along edges.

What you will learn

Why do "relationship" questions explode into expensive joins in a relational database?
What are nodes and edges, and why is a friends-of-friends query just a 2-hop walk?
Which query language do you actually use, and why are there several?
When is a graph database overkill?

When the relationships ARE the data

A graph is made of nodes (entities: people, products, accounts) and edges (the relationships between them: follows, bought, transferred-to). The connections are stored explicitly, not inferred by matching keys.

So traversing relationships is fast and natural: each hop follows an edge, instead of re-scanning and re-matching a table.

Why traversal beats joins

"Friends of friends" is two hops. In SQL that’s the table joined to itself twice; ten hops would be ten self-joins, and performance falls off a cliff as the graph grows.

In Neptune each hop just walks the edges out of the current nodes, so deep, variable- length relationship queries stay tractable.

⚓ Powers social graphs, recommendation engines, fraud detection (rings of linked accounts), knowledge graphs, and network/IT topology.

Two graph models, three languages

Neptune supports the property graph model, queried with Gremlin or openCypher, and the RDF model (semantic web / linked data), queried with SPARQL.

Property graphs suit most application use cases (social, fraud, recommendations); RDF suits standards-based knowledge graphs and data integration.

Property graph or RDF, how do I choose?

Reach for the property graph (Gremlin/openCypher) for app features like recommendations and fraud rings, it’s the pragmatic default. Choose RDF/SPARQL when you need W3C semantic-web standards, shared ontologies, or to merge data from many sources by global identifiers.

Managed, durable, and read-scalable

Like Aurora and DocumentDB, Neptune separates compute from a shared distributed storage layer with six copies across three AZs, and supports up to 15 read replicas with low lag for scaling read-heavy traversals.

Flashcards

In a graph database, how is "Alice follows Bob" represented?: As an edge (the "follows" relationship) directly connecting the Alice and Bob nodes, stored, not recomputed by a join.
Why does a 6-hop "connection between two accounts" query crush a relational database?: It becomes six self-joins; cost explodes with depth. A graph just walks six edges, keeping deep traversals tractable.
You’re building fraud-ring detection on a property graph. Which query languages apply?: Gremlin or openCypher (property graph). SPARQL is for the RDF model instead.
Name three workloads where a graph database is the natural fit.: Social networks, recommendations, fraud detection, knowledge graphs, network/IT topology, anywhere relationships are the primary query.
How does Neptune keep data durable and scale reads?: Aurora-style shared storage: six copies across three AZs, plus up to 15 low-lag read replicas for read-heavy traversals.

Sources

Open the SysPad canvas · Official Neptune documentation