Neptune is a graph database engine, a managed platform AWS database service, and (like Aurora) provides solid-state virtual storage facilities (improves database performance, reliability, and availability).  Neptune also enables high availability by synchronizing database updates to read replicas and replicating data across availability zones.
A Neptune graph database (a NoSQL approach) differs from SQL-based relational engines. Neptune is based on graph data structures (i.e., vertices, edges, properties) instead of relational concepts (i.e., tables, columns, foreign keys) and accommodates apps with highly connected datasets using GQLs, such as Gremlin and SPARQL . GQLs are well-suited for apps navigating complex network relationships (numerous, many-to-many entity relationships) such as those found in contemporary recommender engines (e.g., friend of friend, similar products purchased, attractions visited, etc.).
Graph databases concepts include vertices (aka nodes ), edges , and properties -- comparable to relational concepts (table rows, foreign keys, columns) and data modeling concepts (entities, relationships, attributes). Graph databases supporting these concepts are called labelled property graphs (LPGs). LPGs emphasize edges as named (i.e., labelled) components (rather than relationships inferred by RDBMS foreign keys and table joins). For complex OLTP and OLAP applications, edges enable direct linkage for efficiently traversing vertices.
Gremlin console commands -- rudimentary graph traversal steps for CRUD data operations include:  addV (Add Vertex), addE (Add Edge), Property (Add Property), Has (for filtering, analogous to a SQL SELECT), Drop (analogous to a SQL DELETE).
SPARQL accesses data stored in RDF format and SPARQL’s syntax for querying and updating RDF data is closer to SQL. The RDF graph model (aka a triplestore ) stores linked data in the form of data triples derived from statements consisting of a subject + predicate + object . In an RDF graph, the subject and object are vertices connected by an edge. The predicate is an edge and names the relationship between the subject and object. The object is either a discrete entity or a simple literal value (e.g., a string, date, integer, etc.) which also is stored as a vertex. Except for literals, objects in a triple statement can be the subject or object in other triple statements (enabling traversal). Objects as literal values are property values where the predicate is tantamount to being a property name as well as an edge.
Analogous to adding a property to an edge in an LPG, it is also possible to add information about an RDF predicate via a technique called RDF Reification . This involves adding information about an entire triple statement (e.g., the date the statement was made, the reason for the statement, etc.). Adding information about a triple statement is tantamount to adding information about the predicate. RDF Reification requires adding metadata triple statements (the reification quad) describing the statement itself and introduces more vertices and edges than would be required for an LPG.
The SPARQL commands for creating, reading, updating, and deleting triple statements (CRUD) include: SELECT (comparable to SQL SELECT) , INSERT DATA (comparable to the SQL INSERT) , INSERT WHERE (based on search criteria specified in a WHERE clause), DELETE DATA (comparable to SQL DELETE), DELETE WHERE (based on search criteria specified in a WHERE clause), and DELETE/INSERT WHERE (for changing data) .
Neptune, like Aurora, supports database clustering . A Neptune cluster consists of a primary DB instance (for read and write operations) and as many as 15 read replica DB instances (updates are automatically synchronized from the primary). Neptune replicas offload data retrieval requests. Neptune automatically switches to a read replica if the primary DB instance crashes. Also similar to Aurora, a Neptune cluster can support one or more log types indicating the types of log files that can be published (by all DB instances in the cluster) to Amazon CloudWatch Logs.
A Neptune cluster, like an Aurora cluster, is a kind of DB cluster which in turn is a kind of cluster. A Neptune cluster inherits a KMS customer master key (i.e., a CMK for data encryption), IAM roles, and cluster snapshots because it is a kind of DB cluster. A Neptune cluster indirectly inherits (because a DB cluster is a kind of cluster) many security groups, a subnet group, a parameter group, an engine version, and is a source for event notifications. After a Neptune cluster is created, conventional tools and utilities running on client EC2 instances are used for connecting to graph databases. Examples of such utilities include the Gremlin Console, the RDF4J Console for SPARQL access, and native Neptune endpoints enabling HTTP/REST queries for Gremlin and SPARQL.
Unlike Aurora, Neptune does not support backtracking, serverless clusters, option groups, Performance Insights metrics data, and cross-region replication.