What Actually Separates "Ontology Companies"
Firms lumped together as "ontology companies" sell genuinely different things. Palantir sells an enterprise platform that includes the action paths an agent executes; Neo4j sells the graph database engine itself; Microsoft and Google sell graph capability embedded in their own clouds; Siemens sells an equipment digital twin; RelationalAI sells a relational knowledge graph that runs inside Snowflake. Compare across that gap and the only question left standing is an unanswerable "which company is best."
The landscape below splits five tiers (P1–P5) by what a company sells, not by a ranking. The point for anyone selecting a PoC candidate: a fair comparison only happens within the same tier.
The P1–P5 Landscape: Tier Placement
Tiers are product-category groupings, not a quality ranking — compare PoC candidates within the same tier.
From Landscape to Vendor Selection: A Roadmap
Planning doesn't start with "find the best company" — it starts with pinning down which tier your problem actually belongs to. If an agent needs to act (write, execute), narrow to P1; if graph query performance itself is the bottleneck, P2; if a capability already built into your cloud is enough, P3; if equipment or infrastructure data is the center of the problem, P4. Set the PoC evaluation bar in numbers before entering a tier — for example, p95 query response under 2 seconds, schema-change lead time under one business day.
Four failure patterns recur. Comparing products from different tiers on price alone (a P1 enterprise platform and a P2 graph engine are not purchases of the same kind of thing to begin with). Running a PoC only on vendor-supplied sample data, which never reflects your own data's real complexity. Not checking a hyperscaler's built-in graph service (P3) for constraints — how much schema you can actually write, feature gaps by region — before signing. And confusing a startup's (P5) roadmap announcement with what the product can actually do today.
Design the recovery branch assuming vendor lock-in as the default risk. Write queries in a standard language (SPARQL, GQL, Cypher) where possible to lower dependence on vendor-specific syntax, and validate the data-migration path (export format, speed) during the PoC stage rather than after signing.
On the operational side, run the same golden-set PoC against at least two vendors within the same tier, keep pricing structure (license, usage, enterprise contract terms) in a standardized comparison sheet, and track whether each vendor's claimed figures are company-disclosed or third-party estimates.
For the ongoing loop, treat this landscape itself as something to refresh quarterly. A vendor's tier itself can shift — if a hyperscaler's built-in graph service (P3) expands into ontology and agent actions, it moves closer to P1. Recheck each vendor's latest official announcements every quarter and reassess tier placement.
Quick Reference
Reading an ontology industry landscape pays off only when it's read as categories, not a ranking. Pin down which tier your own problem belongs to first, and compare PoC candidates only within that tier — that's what keeps you from measuring companies that sell fundamentally different things on the same yardstick.
References
Neo4j funding and ARR announcement — Neo4j official news
Microsoft Fabric IQ roadmap — Directions on Microsoft
Ask AI about this article
The assistant has read this article. Ask anything — it answers from the text and says so when something isn't in it.
Loading the chat…