The RDF vs property graph question usually starts too late, at database selection. The useful question is earlier: what meaning must the graph carry, and who needs to agree on it?
Both models are graphs, but they make different promises. RDF is a way to make statements about resources using triples. In RDF 1.1, the things that can appear in a graph are IRIs, literals, and blank nodes, and each statement has the subject-predicate-object shape. A property graph is closer to the graph most engineers draw on a whiteboard: nodes, relationships, labels or types, and key-value properties. Neo4j's graph database glossary describes nodes as entities, relationships as connections, and properties as data held on nodes or relationships. ISO/IEC 39075:2024, GQL, now standardizes a language for creating, querying, maintaining, and controlling property graphs.
That small modelling difference is where the trade-off starts.
RDF earns its keep when meaning crosses boundaries
RDF is strongest when identifiers and semantics need to survive outside one application boundary. The IRI is not a storage detail. It is the mechanism that lets two teams, two systems, or two public datasets point at the same thing without first sharing a table schema or an internal integer id.
That matters when the graph is expected to outlive the current product surface. A compliance control, a policy clause, a piece of evidence, a supplier, and a regulation may come from different systems. If those things have stable identifiers, later systems can add statements without asking the original database owner to redesign the entity.
RDF also earns its keep when vocabulary is part of the work. RDF Schema describes properties in terms of classes through domain and range mechanisms, rather than treating the class as a closed object with a fixed list of fields. OWL adds a richer ontology layer for machine-interpretable class and property meaning. SHACL then gives a validation layer for checking RDF data graphs against shapes. In practice, that separates three jobs that often get blurred: describe what terms mean, infer what follows, and validate whether the data satisfies the shapes a system expects.
The cost is that RDF asks the team to take naming seriously. You have to care about vocabularies, namespaces, graph boundaries, and the difference between an identifier and a label. SPARQL is built around graph patterns over RDF datasets, which can feel indirect if the product problem is just "find the nearest connected accounts and rank them by recent activity." RDF repays the ceremony when the graph is a shared language. It feels heavy when the graph is only an application data structure.
Property graphs earn their keep when traversal is the product
Property graphs are often the better fit when the value is in operational traversal and local context. A relationship can have properties directly on it: since when, with what confidence, under which role, at what weight. The model maps naturally to questions like "which parts are affected by this supplier change?" or "what path connects this customer to this incident?"
The ergonomics are the point. Engineers can usually read a property graph model without first learning a vocabulary discipline. Nodes represent entities. Relationships connect them. Properties carry local facts. Query languages such as Cypher, and now GQL, are shaped around matching paths through those structures.
That makes property graphs a good choice where the owning team controls the schema and needs fast iteration. If a relationship changes from DEPENDS_ON to SUPPLIES_PART_TO, the effect is usually local. If a risk score moves from a node to a relationship, the model can follow the application without convening a vocabulary discussion.
The trade-off shows up when the graph becomes a shared semantic contract. Labels and relationship types can look precise while still being local conventions. Two teams may both have Asset nodes and OWNS relationships, but that does not mean they agree on what an asset is, what ownership implies, or whether the same real-world thing has the same identity in both graphs.
The decision test
I find the choice easier when framed as three questions.
First: will the graph be integrated more than it is traversed? If the graph has to join across external datasets, standards, public identifiers, or independently owned domains, RDF has an advantage. If the graph mostly powers application queries within one product boundary, a property graph may get to the useful model faster.
Second: is the schema a contract or an implementation detail? In RDF, the vocabulary is often a public or semi-public contract. You can publish terms, map to other vocabularies, validate with SHACL, and add statements without changing the original source. In a property graph, the schema is often closer to application code.
Third: do relationships need first-class operational properties? RDF can model metadata about statements, so "RDF cannot represent edge properties" is too blunt. But property graphs are often more direct when relationship properties are central to the query. If every edge carries time, weight, actor, source, and lifecycle state, property graphs may keep the model readable.
The wrong move is to choose RDF because it sounds more principled, or to choose a property graph because it looks simpler in the first diagram. RDF is for shared meaning under change. Property graphs are for direct, operational connection under product pressure. Some systems need both: RDF for the language of the domain, property graphs for the paths the product has to walk quickly.
The architecture question is not which graph is more graph-like. It is where the meaning has to live.