Our Own Storage Layer Does Not Use the Data Model We Are Adjacent To, and That Is a Real Conformance Gap

The gap on this page is ours, it is structural rather than a bug, and nobody outside has raised it with us.

The model, in one idea

Instead of records with columns, everything is a statement of three parts: a subject, a property, and a value. This person, has-email, that address. Nothing else.

The consequence is that data from unrelated sources merges without a schema negotiation. Two systems describing the same subject produce statements that combine into one set, and a query spanning both needs no integration project.

That is a genuinely powerful idea and it is the foundation of the personal-data-store world, where the whole point is that your data is yours and any application can read it if you allow it.

What it costs, which is why most systems do not use it

Query performance, tooling and the number of engineers who have used it.

Relational databases have four decades of optimisation, operational knowledge and hiring pools behind them. A statement store is a different set of trade-offs that most teams do not need and cannot staff.

So the model is chosen when cross-system merging is the requirement, not because it is more principled. Where it is not the requirement, choosing it is a cost paid for nothing.

The distinction this page is really about

"Interoperable at the data-model level" and "an application written for that ecosystem works against you" are different claims, and the first is regularly sold as the second.

A system can use the right model and still be unreachable because the query interface, the authentication or the discovery mechanism differ. A system can use the other model and be perfectly useful for everything except cross-ecosystem merging.

The only test that settles it is running somebody else's client against your server. We have not passed that test because we have not attempted it, and no amount of matching a specification on paper substitutes for it.

What to ask any personal-data-store vendor

"What does your storage layer actually store?" Statements, or rows. This determines whether the ecosystem's promise applies to you at all.

"Has an application you did not write ever run against your server?" The single question that separates real conformance from a claim of it. For us: no.

"Which conformance suite have you run, and what was the result?" For us: none, and we are not claiming otherwise.

"If I leave, what shape is my data in?" The exit question, and it is the one the whole model exists to answer well.

Where this leaves a decision

If your requirement is that existing applications from that ecosystem work against your store on day one, we do not meet it, the gap is structural rather than a defect, and you should evaluate an implementation that has passed a conformance suite.

If your requirement is per-user data ownership with an exit path, that is running today, the gap above is stated rather than papered over, and you now know exactly which promise we are and are not making.