What Is Stardog? Inside Its "Hallucination-Free" Claim

---

Stardog is a commercial RDF/OWL knowledge-graph database, founded in 2006, that reasons over data at query time and virtualizes relational sources into a graph without moving them. It also ships an AI layer, Voicebox, marketed as “hallucination-free.” Atlan’s Active Ontology treats that same semantic-modeling job as one of three compounding substrates, not the whole context system.

---

Stardog traces its roots to Clark & Parsia, LLC, a research-driven firm Kendall Clark, Mike Grove, and Evren Sirin built before rebranding through Complexible and arriving at the Stardog name. Stardog’s own company page dates the mission to 2006, when the founders met at the University of Maryland AI Lab. It has real, credentialed depth: deep formal OWL reasoning among knowledge-graph platforms in its competitive band, a true ACID graph store, and enterprise customers going back two decades. It also has documented limits its own marketing does not lead with.

• What it does well: query-time OWL 2, SWRL, and Stardog Rules reasoning with proof-tree explanations, on a real ACID quad store
• Where the marketing gets ahead of the docs: “hallucination-free” is a system-property claim, and Stardog’s own Voicebox docs flag the External LLM Agent’s output with “Note: This may contain Hallucinations”
• Where the line actually sits: what Stardog actually is, who it’s built for, and where its own documentation, not competitor spin, draws the line

Field	Detail
What it is	An RDF/OWL knowledge-graph database with a query-time reasoning engine and a virtualization layer
Founded	2006 (as Clark & Parsia, LLC) by Kendall Clark, Mike Grove, and Evren Sirin, who met at the University of Maryland AI Lab
Core engine	RocksDB-backed RDF quad store; closed-source commercial (public GitHub holds only client drivers and SDKs)
Best for	Formal ontology and reasoning work in regulated industries: financial services, government, life sciences
Named customers	NASA (since 2006), Bosch, Boehringer Ingelheim, NIH, Springer Nature, Raytheon
Pricing	Free tier (1-year renewable license, excludes HA/backups/LDAP/full connectors); Enterprise is quote-gated

---

What is Stardog, and what does it actually do?

Stardog is an RDF and OWL knowledge-graph database with a reasoning engine that draws logical conclusions at query time rather than pre-computing them in a batch job. Kendall Clark, Mike Grove, and Evren Sirin founded the company as Clark & Parsia, LLC, later renamed to Complexible and then Stardog. Stardog’s own company page dates the mission to 2006, when the founders met at the University of Maryland AI Lab. Craig E. Harper, a former ServiceNow and Cherwell Software executive, was appointed CEO in September 2025. The current release is Stardog Platform 12.1.4, shipped September 3, 2026, per Stardog’s release notes.

The core mechanism is a RocksDB-backed RDF quad store, meaning every fact is stored as a triple plus a named-graph identifier, with full ACID transaction guarantees. Reasoning runs at query time against an OWL ontology layered on top of that store, not as a one-time materialization pass, so the graph reflects the current ontology every time it’s queried. Getting that ontology right in the first place is its own discipline, covered in Atlan’s ontology design for AI guide, independent of which engine ends up running it. Stardog’s primary query language is SPARQL, the W3C standard for graph queries. It advertises first-class support for SPARQL, SPARQL* and GraphQL, not SQL.

That puts Stardog in a different category from a property-graph database like Neo4j, which stores nodes and edges without a formal ontology by default, a distinction covered in full in ontology vs knowledge graph. Inside Atlan’s enterprise context layer, this is the same substrate Semantics & Ontology covers: giving data shared, logically consistent meaning instead of leaving every tool to define it alone. Stardog does that job with more formal rigor than most of the category, and worse coverage of the rest of what an enterprise needs from context.

Who founded Stardog

Kendall Clark, Mike Grove, and Evren Sirin founded the company; Stardog’s own current team page credits Mike Grove as SVP of Engineering and Product and Evren Sirin as CTO and co-founder. All three came out of the University of Maryland’s AI lab, a background that shows in how deliberately Stardog approaches the mechanics of constructing a knowledge graph rather than just storing one. Public signals on Kendall Clark’s present-day role are mixed: Stardog’s own current team listing and his own public profile no longer show him in an active operating role at the company. He is credited as a founder; whether he still holds any active role there is not established.

What Stardog’s Quick Facts look like at a glance

Field	Detail
What it is	An RDF/OWL knowledge-graph database with a query-time reasoning engine and a virtualization layer
Founded	2006 (as Clark & Parsia, LLC) by Kendall Clark, Mike Grove, Evren Sirin, who met at the University of Maryland AI Lab
Core engine	RocksDB-backed RDF quad store; closed-source commercial (public GitHub holds only client drivers/SDKs)
Best for	Formal ontology/reasoning work in regulated industries (financial services, government, life sciences)
Named customers	NASA (since 2006), Bosch, Boehringer Ingelheim, NIH, Springer Nature, Raytheon
Pricing	Free tier (1-year renewable license, excludes HA/backups/LDAP/full connectors); Enterprise is quote-gated

---

Stardog vs Neo4j: how does a knowledge graph differ from a graph database?

The single most common comparison question about Stardog is really a question about two different data models. Stardog’s model is RDF triples and quads with formal OWL 2 reasoning; Neo4j’s is a labeled-property graph with no ontology layer built in.

That distinction has a practical consequence. Stardog suits use cases that need provable logical inference, entailment, and consistency checking, for example classifying a transaction against a regulatory taxonomy and being able to show the proof. Neo4j suits use cases that need fast graph traversal without a formal semantics layer on top. Neither claim is a knock on the other tool; they’re built for different jobs, the same tradeoff Atlan’s own graph database vs metadata layer piece works through for readers deciding between the two categories generally. Atlan’s own knowledge graph vs graph database explainer covers the general version of this question, for readers who landed here without Stardog specifically in mind. The same single-vendor pattern shows up in two related Atlan deep dives: Amazon Neptune examined as a standalone graph database, and Amazon Neptune held up against a full knowledge graph context layer, the same single-vendor-vs-context-layer pattern applied here to Stardog.

Stardog vs Neo4j at a glance

Dimension	Stardog	Neo4j
Data model	RDF triples/quads (named graphs)	Labeled property graph
Query language	SPARQL 1.1	Cypher
Formal reasoning	OWL 2 profiles (QL/RL/EL, unioned into the default SL) plus SWRL and Stardog Rules, at query time	No built-in formal ontology or reasoning layer
Scale model	Single-node-sized datasets; no sharding, per Stardog’s own documentation	Horizontally scalable via Aura and Fabric

---

Is Stardog’s Voicebox really “hallucination-free”?

Stardog markets Voicebox, its natural-language interface, as “hallucination-free”: a claim that its own documentation complicates in specific, checkable ways. The company’s Safety RAG blog post explains what it means by the term: the system is “hallucination-free” because it never shows users an LLM’s output that isn’t grounded in the knowledge graph, according to Stardog’s own account. That’s a system-property definition, “we don’t surface ungrounded text,” closer to what a well-scoped RAG system promises than to a guarantee that the underlying model never hallucinates internally.

Stardog’s own Voicebox documentation is where that guarantee gets its scope. It distinguishes information generated by RAG, code and external LLMs from data retrieved directly from the knowledge graph, and it flags one agent outright: the External LLM Agent’s entry reads, in Stardog’s own words and capitalisation, “Note: This may contain Hallucinations.” The RAG Agent sits on the same labelled side of that line, retrieving text, table data and document metadata for a question through the usual retrieval-augmented generation pattern over a vector store rather than answering from the graph, per Stardog’s Voicebox documentation. The honest reframe: the guarantee is a labeled-provenance property, Voicebox tells you where an answer came from, and it holds fully only on the direct knowledge-graph query path with the External LLM Agent turned off.

That’s worth sitting with plainly, because it’s also a real strength described in language that oversells it. Voicebox does return the SPARQL query it ran alongside every answer, and it says “Cannot find an answer” rather than fabricating one when the graph has nothing relevant, which is more transparent than most natural-language-to-query tools on the market, a habit that also limits the kind of context drift that erodes trust in less transparent systems over time. The claim just needs a narrower scope than “hallucination-free” implies.

The claim vs. the documentation, side by side

Stardog’s claim	What Stardog’s own documentation says	Source
Voicebox will never generate false responses	Holds only when ungrounded output is never surfaced to the user, a system-property definition, not a guarantee about the LLM itself	Stardog Safety RAG blog
The system is hallucination-free end to end	The External LLM Agent’s docs state its output “may contain Hallucinations”	Stardog Voicebox documentation
Answers are always grounded in the graph	The docs distinguish RAG, code and external-LLM output from data retrieved directly from the knowledge graph	Stardog Voicebox documentation
Governance protects sensitive data by default	Named-graph security ships off by default, and fine-grained (sensitive-property) security is self-described “not production-ready”	Stardog security documentation

---

Who uses Stardog, and when does it make sense?

Stardog’s customer base points to a consistent buyer profile: teams in regulated, high-stakes industries that need formal logical inference more than fast developer iteration. Stardog names NASA as its longest-standing customer, a relationship that began in 2006 when the founders custom-built data analytics applications for the agency, and that now supports a knowledge graph spanning SLS, Orion and Exploration Ground Systems, according to Stardog’s own NASA customer page. Bosch, Boehringer Ingelheim, NIH, Springer Nature and Raytheon sit alongside it.

That customer list maps directly to Stardog’s own positioning and the pattern the technical documentation confirms: financial services, government, life sciences, and manufacturing, anywhere provable inference and formal logic matter more than raw developer ergonomics. Stardog publishes a NASA case study of its own on that work, which is stronger evidence than a review-site aggregate.

The trade a buyer makes for that formal rigor is expertise. Stardog rewards teams that already have RDF and ontology skills in-house, and asks a lot of teams that don’t, the exact expertise gap Atlan’s own enterprise knowledge graph pitfalls piece catalogs as the most common reason ambitious graph projects stall.

---

What are Stardog’s documented limitations?

Every platform has caps, and the fair way to state Stardog’s is from its own documentation, not from invented criticism. Three areas stand out, a different set of caps than the ones Atlan’s own piece on extending an ontology beyond a single warehouse works through for teams whose ontology started inside one system.

On scale, Stardog’s high-availability cluster has no sharding: every node in the cluster holds the full dataset, so the architecture scales reads for availability, not data size, and write throughput actually worsens as more nodes are added, according to Stardog’s own cluster documentation. That caps Stardog at datasets a single node can hold, a real constraint for an enterprise-scale graph, and one Atlan’s own guide to building a knowledge graph for AI agents flags as a planning question worth asking before committing to a single-node architecture.

On governance, named-graph security ships off by default, and Stardog’s separate fine-grained security feature, which restricts access to specific sensitive properties, is self-described in Stardog’s own documentation as “not production-ready”: sensitive values can still surface through zero-length paths and full-text search, and the feature only limits reads, not writes, even when enabled. There’s also no SAML support, only OAuth2, OIDC, and LDAP, and no documented encryption at rest, a gap that matters more once a graph feeds AI agents directly rather than a handful of trained analysts, the same access-control question Atlan’s context layer role-based access control piece works through for a governed alternative.

On memory, Voicebox’s History Agent tracks conversational context as short-term memory to support multi-turn conversations, and the #nohistory hint breaks that context, per Stardog’s Voicebox documentation. That is a narrower model than the compounding, cross-session agent memory architecture built to carry context forward on its own.

Limitations at a glance

Area	Documented limit	Source
Scale	No sharding; single-node-sized datasets; write throughput degrades as nodes are added	Stardog high-availability cluster docs
Governance	Named-graph security off by default; fine-grained (sensitive-property) security “not production-ready”	Stardog security documentation
Authentication	OAuth2, OIDC, and LDAP supported; no SAML	Stardog security documentation
Memory	Conversational context is short-term memory for multi-turn chat; #nohistory breaks it	Stardog Voicebox documentation
Engine	Closed-source; public GitHub org holds only client drivers and SDKs, no engine source	Stardog GitHub organization

None of this erases what Stardog does well. A team that needs formal, provable reasoning and can live inside a single-node-sized dataset, with governance configured deliberately rather than assumed, gets real value from Stardog. The gap is between what the marketing implies by default and what a first-time evaluator needs to configure on purpose.

---

How Atlan approaches knowledge graphs and context

A formally reasoned ontology answers “what does this mean, logically” well. It doesn’t, on its own, answer whether the underlying data can be trusted, or how an AI agent should act on what it just learned, and that’s the gap Atlan’s enterprise context layer, not a single ontology substrate alone, is built to close.

Atlan’s Active Ontology treats business semantics as compounding and agent-built: definitions update from how the data is actually used, tracked through a governed review and approval lifecycle, rather than a hand-modeled ontology whose only versioning is a change-detection hash over time. Atlan’s MCP server ships in 75+ production enterprises today, built to work the same way regardless of which model or vendor sits on top, compared with Stardog’s own MCP server, which is real and public. It exposes three read-only Voicebox tools, settings, ask, and SPARQL-query generation, to hosts including Claude Desktop, Claude Code and Cursor. Local setup is self-serve; the Launchpad path is explicitly gated, in Stardog’s words: “For setting this up in your local Launchpad environment, please contact Stardog support.” The same architectural choice, model-agnostic delivery over a single vendor’s interface, is examined in context layer vs knowledge graph, and worked through from Atlan’s own side in business context for AI.

That’s a scope difference, not a knock on Stardog, and the two are currently complementary rather than competing: Stardog goes deeper on formal logic than any comparably sized platform, and Atlan goes wider across the rest of what an enterprise’s AI agents need, trusted data, governed delivery, and compounding context that updates itself. Nothing else in this competitive band unions the OWL 2 QL, RL and EL profiles into a single default reasoning profile alongside SWRL and user-defined rules, with proof-tree explanations, the way Stardog’s inference engine does, and that’s worth crediting plainly, the same way a narrow vector database deserves credit for what it does well relative to a full context layer. A reader deciding between the two, or whether they need both, gets the direct comparison in Stardog vs Atlan, not here.

What a real customer said, unprompted

“Atlan is much more than a catalog of catalogs. It’s more of a context operating system…Atlan enabled us to easily activate metadata for everything from discovery in the marketplace to AI governance to data quality to an MCP server delivering context to AI models.”

Sridher Arumugham, Chief Data & Analytics Officer, DigiKey

That’s a different substrate than the one Stardog’s ontology work covers on its own, the same graph-vs-catalog distinction unpacked in Atlan’s knowledge graph vs data catalog piece, described independently by a customer using it in production, which is a different kind of evidence than a vendor’s own claim about itself.

---

FAQs about Stardog

1. What is Stardog used for?

Stardog is used to build formally reasoned knowledge graphs over enterprise data, mainly in regulated industries like financial services, government, and life sciences. Teams use it to model business entities as RDF, run OWL-based logical inference over them, and query across relational sources through its Virtual Graphs feature without moving the underlying data.

2. Is Stardog open source?

No. Stardog’s core engine is closed-source commercial software. Its public GitHub organization holds only client drivers, SDKs, and the historical Pellet reasoner, not the engine, reasoner, or storage layer itself.

3. Is Stardog free, or does it require a paid license?

Stardog offers a free, renewable one-year license that permits commercial use but excludes high availability, caching, backups, LDAP, and full connector access. Stardog Enterprise, with those features included, is quote-gated custom pricing.

4. What companies use Stardog?

Stardog names NASA as its longest-standing customer, a relationship that began in 2006, alongside Bosch, Boehringer Ingelheim, NIH, Springer Nature and Raytheon. Its buyer base skews toward regulated, high-stakes industries rather than developer-led adoption.

5. What is Stardog Voicebox?

Voicebox is Stardog’s natural-language interface that translates plain-English questions into SPARQL queries against a knowledge graph, then returns an answer along with the query it ran. Stardog markets it as “hallucination-free.”

6. Is Stardog a graph database or a knowledge graph platform?

Both. Stardog is an RDF quad store, a genuine graph database with full ACID transactions, plus a formal OWL/SWRL reasoning engine and tooling layered on top, which is what makes it a knowledge graph platform rather than just a storage engine.

7. Does Stardog’s “hallucination-free” claim hold up under its own documentation?

Partly. The claim holds on the direct knowledge-graph query path, where Voicebox only surfaces answers grounded in the graph. Voicebox’s own documentation distinguishes information generated by RAG, code and external LLMs from data retrieved directly from the knowledge graph, and flags the External LLM Agent with “Note: This may contain Hallucinations.”

8. Does Stardog compete with Atlan?

Not currently. Stardog’s formal ontology and reasoning engine and Atlan’s context layer occupy adjacent, complementary territory rather than a head-to-head one. Readers weighing both directly can see the full comparison in Stardog vs Atlan.

---

Sources

1. Stardog company overview, Stardog
2. NASA’s knowledge graph, Stardog
3. Stardog appoints former ServiceNow executive Craig Harper as chief executive officer, Stardog
4. Stardog Semantic AI Platform, Stardog
5. Inference engine documentation, Stardog
6. Safety RAG: improving AI safety by extending AI’s data reach, Stardog
7. Stardog Voicebox documentation, Stardog
8. NASA, Stardog customers
9. NASA case study, Stardog
10. Stardog Cloud MCP server, Stardog on GitHub
11. High availability cluster documentation, Stardog
12. Fine grained security documentation, Stardog
13. Named graph security documentation, Stardog
14. Stardog pricing, Stardog
15. Stardog Platform release notes, Stardog