Graph Data Model

A graph data model organizes information around entities and the relationships between them. Entities are represented as nodes, also called vertices, and relationships are represented as edges. In a property graph, nodes and edges can carry properties: a customer node might have a customer identifier, while a PURCHASED edge might record a timestamp. Edge direction and relationship type express meaning, such as a person working for an organization.

The model is especially useful when the connections are central to the question. For example, a fraud investigation might connect accounts, devices, payment cards, and addresses. A query can identify accounts that share a device with an account already associated with fraud, then follow additional connections to find suspicious clusters. This is a traversal: moving through relationships from one entity to another.

Two important graph representations are property graphs and Resource Description Framework, or RDF. Property graphs commonly describe labeled nodes and typed edges with properties. RDF represents statements as subject-predicate-object triples and is often used for knowledge integration and semantic applications. Query languages depend on the representation and database; examples include openCypher and Gremlin for property graphs and SPARQL for RDF.

In the cloud, a managed graph database can handle infrastructure tasks such as backups, availability, and software maintenance while exposing graph query interfaces. Engineers still need to design entity identifiers, relationship types, access controls, and query boundaries. An application might retain purchase records in its operational database and copy selected entities and relationships into a graph database for recommendations. This introduces synchronization work and potentially delayed graph updates.

Graph databases are commonly classified as NoSQL databases, but NoSQL is a broad category rather than a single data model. For AWS certification questions, distinguish Amazon Neptune, a managed graph database service, from Amazon DynamoDB, a key-value and document database service. DynamoDB can represent relationships through adjacency-list patterns, but it does not provide the same native graph traversal capabilities. Merely having related records does not make a database a graph database.

A graph model is not automatically better than a relational model. Relational databases can represent relationships using foreign keys and query them with joins or recursive queries. Graph databases are often a good fit when variable-depth paths and changing relationship patterns dominate the workload. Simple key lookups, tabular reporting, and large aggregations may fit other database models more naturally.

Performance depends on query shape, data distribution, indexing, and implementation. Following connections from a highly connected node can produce an enormous intermediate result, so engineers should constrain relationship types, traversal depth, and starting entities. Flexible structure also does not eliminate the need for validation or governance. Finally, a graph model does not imply eventual consistency or the absence of transactions; those guarantees depend on the chosen database service and configuration.