Neo4j GRAPH TYPE: A Pragmatic Comparison with the RDF/SHACL World

What a typed property-graph schema actually buys you in production

I get excited about database features. Not the flashy ones — the ones that make running Neo4j in mission-critical production actually safer and better. The features that turn “we hope the application got it right” into “the database guarantees it.” Those are the ones I want.

GRAPH TYPE is one of those. And predictably, the RDF aficionados had their first instinct locked and loaded — reply underneath every post with some version of:

“RDF had this for decades. ”

What’s interesting is that this reaction is itself part of the story. Because when people say “RDF had this”, they’re usually collapsing several different layers of the RDF stack into a single label: RDF itself, RDFS, OWL, SHACL, and whatever validation or enforcement capabilities happen to be provided by a particular triplestore. Those are very different things. RDF, RDFS, and OWL never provided database-style integrity constraints in the way people often assume they did. Untangling those layers is the reason this post exists.

I’ve spent years putting graphs into environments where a bad write isn’t a bug ticket, it’s a call at 2am. So let me answer that comment properly — not as a Neo4j cheerleader, but as someone who has to live with the consequences of whatever schema strategy I choose. Because the people typing “this is just RDF” are answering a genuinely different question than the one I face in production.

Why graph types actually matter to me

Schema-optional is the reason most of us reached for property graphs in the first place. You model as you discover. No migration ceremony. You’re productive on day one.

Here’s what nobody puts in the tutorial: in a long-lived, mission-critical system, schema-optional quietly becomes schema-absent. Part of that is a software-engineering problem — without proper tooling and discipline, drift creeps in. But the deeper reason is structural: you start with one application that owns the schema in its code, and you end with multiple apps, producers, and pipelines all writing to the same graph. Once there’s no single app, “the app enforces the schema” stops being true, and the responsibility has to move to the one thing every writer shares — the database core.

Three years in, you’ve got Customer nodes with no email, dates stored as strings because one ingestion job in 2023 didn’t cast them, and a relationship type that was only ever supposed to connect two labels now wired into a third — because someone was in a hurry, and the database didn’t care.

The “fix” we all reached for was constraints. One CREATE CONSTRAINT per rule, added reactively, the morning after each incident. After enough incidents you have dozens of them scattered across database metadata, the definition of an entity smeared across whatever apps and interfaces happen to model it — each its own version, none of them authoritative — and its enforcement living nowhere the database can see. The only complete picture of your data model is in the head of whoever’s been there longest. That’s not a schema. That’s tribal knowledge with a backup problem.

And it gets worse with time, for a reason that has nothing to do with trends and everything to do with how systems actually grow: the number of sources writing to your graph only ever increases. More engineers, each with their own mental model. More ingestion pipelines, evolving independently. More services pointed at the same database. More one-off scripts run by hand at 2am to fix the last mess. And the more sources there are, the less attention any single one gets — the first integration was reviewed line by line; the tenth got merged on a Friday. Not one of them is a reliable gatekeeper, and “the application layer is careful” was never a real guarantee, it was a hope that held right up until it didn’t.

By the time you decide to impose order, you discover the second trap: you can’t even add the constraints, because the violating data is already in there. So now you’re cleaning up history before you’re allowed to enforce the present.

Mission-critical means I want invariants, not vibes. GRAPH TYPE is the first time I can declare the whole model in one place and have the engine make it true on every write:

ALTER CURRENT GRAPH TYPE SET {
  (c:Crew => :Person {
    id   :: STRING,
    name :: STRING NOT NULL
  }) REQUIRE c.id IS KEY,
  (s:Ship => {
    registryCode :: STRING,
    class        :: STRING NOT NULL
  }) REQUIRE s.registryCode IS KEY,
  (:Crew)-[:ASSIGNED_TO => { since :: DATE }]->(:Ship)
}

Three things in there earn it a place in my production toolbox:

• => :Person enforces a label implication — a Crew node cannot exist without also being a Person. That rule used to live in code, or in nobody’s code.
• The relationship is typed with its own properties and constrained endpoints. ASSIGNED_TO can only go Crew → Ship. I’ve cleaned up enough relationships pointing at the wrong thing to know what that’s worth.
• It’s enforced in the write path. The violating transaction dies. There is no window where bad data sits in my store waiting for someone to notice.

That’s the operator’s reason it matters. Now the architect’s question: given that the RDF stack has done schema and validation for twenty years — why not just use it?

Why not RDF (RDFS and OWL)

Because RDFS and OWL were built to infer. I need something built to reject. Those are opposite jobs, and you can’t fake one with the other.

RDFS and OWL run under the Open World Assumption with no unique names, and their reasoning is monotonic — adding a fact can only ever add conclusions, never invalidate existing conclusions. That makes standard OWL semantics poorly suited to serving as a database-style validation gate, because validation often requires exactly the opposite move: determining that a newly asserted fact violates an integrity rule and should be rejected.

You don’t have to take the theory on faith. Watch what these actually do.

RDFS domain/range looks like a constraint and isn’t one:

:worksAt rdfs:domain :Person .
:Globex  :worksAt    :Acme .

I meant worksAt to require a person on the left. I then assert that Globex, a company, worksAt Acme. A database rejects that. RDFS does the opposite: it concludes :Globex a :Person. The “constraint” silently rewrote my data to make the violation disappear. In a mission-critical system, that’s not a safety net.

OWL is worse, in the most instructive way:

:hasCaptain a owl:FunctionalProperty .   # at most one captain
:Enterprise :hasCaptain :Kirk .
:Enterprise :hasCaptain :Picard .

My engine rejects the second write — cardinality violation, exactly what I want. OWL, in the open world with no unique names, returns a different verdict entirely: it infers :Kirk owl:sameAs :Picard. A ship can’t have two captains, so they must be the same person.

This isn’t a flaw. For reasoning over open, federated knowledge, that behavior is correct and genuinely powerful — it’s why OWL owns the domains it owns. But the day you point it at “stop my application from writing garbage,” you’ve made a category error. You can layer validation and rejection mechanisms around OWL, and many RDF platforms do exactly that. But those mechanisms live outside standard OWL entailment itself, because OWL’s primary purpose is reasoning about what follows from the data, not deciding whether a transaction should be accepted.

The RDF community knows this. It’s why SHACL exists. So the real question was never OWL. It’s: Why not SHACL?

In fact, the existence of SHACL is itself evidence that RDF, RDFS, and OWL never solved database-style validation on their own.

Why not SHACL?

This is the one I take seriously, because SHACL is standing exactly where I’m standing. W3C Recommendation since 2017. Closed-world. Non-monotonic. A real validation language:

To be clear, I’m comparing GRAPH TYPE to SHACL as standards, not to the capabilities of any particular RDF vendor. Several triplestores already integrate SHACL validation into their transaction pipeline and can reject non-conforming updates at commit time. More importantly, SHACL deliberately separates constraint definition from enforcement strategy. The same SHACL shapes can be used for transactional enforcement, CI validation, compliance reporting, or scheduled quality checks. My argument is not that SHACL cannot enforce constraints. It’s that GRAPH TYPE chooses to couple schema definition and enforcement in a way that SHACL intentionally does not.

:CrewShape a sh:NodeShape ;
  sh:targetClass :Crew ;
  sh:property [ sh:path :id ;   sh:datatype xsd:string ; sh:minCount 1 ; sh:maxCount 1 ] ;
  sh:property [ sh:path :name ; sh:datatype xsd:string ; sh:minCount 1 ] .

If I’m being honest, SHACL is the closest thing in any ecosystem to what GRAPH TYPE does. So “why not SHACL” can’t be hand-waved. Here’s my answer, from the operator’s chair, on the four fronts that actually decide it for me.

1. A validation report is not a transactional gate. This is the one I feel most. SHACL, by spec, defines a validation function: hand it a data graph and a shapes graph, get back a conformance report. That’s a check you run — in CI, in a pipeline, on a schedule. It tells you what’s already broken.
By itself it doesn’t stop the bad write from committing. SHACL standardizes the expression of constraints, not a particular enforcement strategy. The same SHACL shapes can be used as a transactional gate that rejects invalid writes, as a validation process in CI, as a scheduled compliance check, or as a reporting mechanism that surfaces violations without blocking updates. Those are all valid uses of SHACL. GRAPH TYPE takes a different approach. In Neo4j’s implementation, schema definition and enforcement are coupled: the constraint becomes part of the engine’s write-time behaviour rather than a separate artifact whose execution model is decided independently. For a system taking continuous writes, that’s the difference between data quality as a recurring batch job and data quality as a property of the database. I don’t want to discover invalid data. I want it to be impossible to commit.

2. Three languages and a drifting artifact, versus one. With the RDF approach my data is RDF, my queries are SPARQL, and my validation lives in SHACL (itself expressed in RDF). That’s a perfectly coherent stack, but it does mean schema and validation exist as separate artifacts from the database definition itself. In practice, those artifacts can drift unless they’re actively governed. The shapes graph is a separate document that can drift from the data it governs if it isn’t actively managed. GRAPH TYPE is written in the language I already query with, enforced by the engine I already run, inspected with SHOW CURRENT GRAPH TYPE, evolved with SET / ADD / ALTER / DROP. The schema isn’t a file describing the store. It is the store’s declared type. One fewer thing that can silently fall out of sync is one fewer 2am call.

3. SHACL validates the RDF data model — including everything RDF made hard. To use SHACL I first have to accept triples, URIs as identity, and the big one: no native properties on edges. An attributed relationship like ASSIGNED_TO { since: date } is not a primitive in traditional RDF. Historically that meant reification patterns or named-graph approaches; more recently RDF-star (now being incorporated into RDF 1.2) provides a much more natural representation. Even so, relationship properties remain more direct and central in the property-graph model. In GRAPH TYPE, typing an attributed, endpoint-constrained relationship is a primitive:

(:Crew)-[:ASSIGNED_TO => { since :: DATE }]->(:Ship)

I’m not modelling around the data model. The model already had the concept.

4. It’s standardized for the model I actually chose. This is what ends the “reinvention” charge for me. GRAPH TYPE isn’t a proprietary dialect — it’s the schema layer of GQL, ISO/IEC 39075, the first new ISO query language since SQL. SHACL standardizes validation for the RDF stack. GQL graph types standardize it for the property-graph stack. So the choice isn’t “rigor in RDF vs. cowboy hacks in Neo4j.” It’s two standardized answers, one per data model. And it means I can get rigorous, standardized schema enforcement without abandoning the data model, query language, and engine I run in production. That, more than any single keyword, is why SHACL isn’t my answer: SHACL represents a different architectural choice. It treats constraints as a portable definition that can be enforced, validated, reported on, or translated into implementation-specific mechanisms across multiple systems. GRAPH TYPE, by contrast, makes those constraints part of the graph database’s native schema and enforcement model. For my use case, I prefer the latter.

The reframe

Strip the tribalism and there are three different questions wearing similar syntax:

• RDFS / OWL: what else is necessarily true in this open world? — inference.
• SHACL: does this graph conform to these shapes, when I run the check? — validation, layered over RDF.
• GRAPH TYPE: what is this database physically allowed to contain, on every write? — a typed schema as an engine-native invariant of the property-graph model and its ISO standard.

“Why not RDF? Why not SHACL?” was never a dismissal of either. The accurate answer is the one I’d give in an architecture review: when the problem is operational data integrity on an attributed property graph I already run in production, GRAPH TYPE gives me schema definition and enforcement directly inside the database engine. SHACL represents a different philosophy. It treats constraints as a portable definition that can be enforced, validated, reported on, or translated into implementation-specific mechanisms across multiple systems. That’s a powerful idea, particularly when the same business rules must be applied consistently across graphs, relational databases, warehouses, and integration pipelines. For my use case, though, I want the guarantees closest to the database itself. That’s why GRAPH TYPE is the better fit.

Both worlds reached the same conclusion in the end: a flexible graph still needs enforceable structure. RDF got there by standardizing a validation layer on top: SHACL. Property graphs got there by standardizing schema and validation as graph types in GQL. Same lesson, two idioms, each true to the world it was built for.

None of this means RDF and SHACL are the lesser tool. For federated knowledge, shared ontologies, semantic interoperability, and reasoning, they’re the right choice and the property-graph world has nothing close. But that’s a different problem than the one I’m solving — and for mine, GRAPH TYPE wins.

So I don’t pick by camp. I pick by the world the problem lives in. And the world mine lives in — mission-critical, transactional, increasingly written to — is the one GRAPH TYPE was built for.

If you think the open-world/closed-world split isn’t the real dividing line here, that’s the conversation I actually want to have. Comments are open.

---

Neo4j GRAPH TYPE: A Pragmatic Comparison with the RDF/SHACL World was originally published in Neo4j Developer Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.