Knowledge Graphs — vs Other Approaches
There are many ways to give an AI agent access to structured domain knowledge. This page explains where SyntheticBrew Knowledge Graphs fit, what other approaches exist, and when each one is the right tool.
The short version: SyntheticBrew Knowledge Graphs are declarative-first (customers describe their domain in JSON Schema, not extracted from text), open-source (BSL 1.1), GitOps-native (bundles in git, applied via brewctl), and MCP-first (auto-generated MCP tools per entity type). No one else makes that combination in one product.
vs Vector RAG (Knowledge Bases in SyntheticBrew)
Section titled “vs Vector RAG (Knowledge Bases in SyntheticBrew)”| Aspect | Vector RAG (Knowledge Bases) | Knowledge Graphs |
|---|---|---|
| Data shape | Unstructured text (chunks of prose) | Typed entities with fields and relationships |
| Retrieval | Cosine similarity, top-k ranking | JSONB filter, exact match, full recall |
| Hallucination risk | Higher on structured data (IDs, codes, enums) | Near-zero on entity payloads (LLM cannot invent IDs) |
| Update pattern | Append documents, re-embed | Bulk apply via brewctl, atomic |
| Tools agent uses | knowledge_search(query) | list_<type>(filters), get_<type>(id) |
| Sweet spot | Manuals, articles, narrative content | Catalogs, taxonomies, registries, controlled vocabularies |
These are complementary, not competing. Use Knowledge Bases for narrative search and Knowledge Graphs for structured retrieval, on the same agent. See the Knowledge Graphs concept for the boundary.
vs LlamaIndex Property Graph Index
Section titled “vs LlamaIndex Property Graph Index”LlamaIndex Property Graph Index is the closest open-source equivalent — a property graph built around entity types and relationships, with schema-controlled extraction (SchemaLLMPathExtractor) for whitelisting which types and relations the LLM may produce.
Key differences:
| Aspect | LlamaIndex Property Graph | SyntheticBrew Knowledge Graphs |
|---|---|---|
| Workflow | Extraction-first — LLM reads documents and extracts entities | Declarative-first — customer authors entity bundles directly |
| Schema control | Whitelist for LLM extraction (still subject to drift) | 100% deterministic; entities only enter the graph through validated apply |
| Schema language | Python types / Pydantic | Portable JSON Schema (Draft 2020-12) with x-* annotations |
| GitOps | Build and re-build pipelines in code | brewctl kg apply from a directory; idempotent diff |
| Agent tool surface | Custom retrievers per integration | Auto-generated MCP tools per entity type |
| Multi-tenant | Per-namespace storage backends | First-class per-tenant scope baked into the engine |
Use LlamaIndex when you start from a corpus of unstructured text and want to auto-extract a graph. Use SyntheticBrew when you already know your domain and want a declarative bundle the engine validates and serves to agents directly.
vs Cognee
Section titled “vs Cognee”Cognee positions itself as “memory for AI agents” — an ECL pipeline (Extract, Cognify, Load) that ingests data and builds a knowledge graph automatically, with recent support for grounding in existing OWL/RDF ontologies.
Key differences:
| Aspect | Cognee | SyntheticBrew Knowledge Graphs |
|---|---|---|
| Primary frame | Memory layer for agents — what the agent has seen | Domain ontology — how the agent’s world is structured |
| Data source | 38+ connectors, mostly extraction-based | Customer-authored bundles, declarative |
| Ontology authoring | Optional grounding through external OWL/RDF | Native JSON Schema with x-* annotations |
| Hosting | Open-source library + managed Cloud | Open-source engine (CE/EE/Cloud) — bundles served by the same engine that runs the agent |
Use Cognee when “memory of what the agent saw” is your primary concern and you want extraction pipelines to populate the graph for you. Use SyntheticBrew when your domain is already known and you want a clean separation between conversation memory (Memory capability) and domain ontology (Knowledge Graphs).
vs Neo4j + LangChain GraphRAG
Section titled “vs Neo4j + LangChain GraphRAG”The Neo4j + LangChain partnership provides a pattern: hold the graph in Neo4j and access it from LangChain agents via Cypher queries (often LLM-generated through GraphCypherQAChain).
Key differences:
| Aspect | Neo4j + LangChain | SyntheticBrew Knowledge Graphs |
|---|---|---|
| Storage | Neo4j graph database | Postgres JSONB with generic GIN |
| Query language | Cypher (often LLM-generated) | Auto-generated MCP tools (no query generation by LLM) |
| Setup complexity | Manage Neo4j cluster + integration code | Single Postgres in the engine you already run |
| Hallucination surface | LLM-generated Cypher can be wrong | No LLM query generation; tools are typed |
| Schema authoring | Manual via Cypher CREATE | Declarative JSON Schema |
| License | Neo4j commercial / community + LangChain MIT | Engine BSL 1.1 (free self-host) |
Use Neo4j when you need true graph traversal (multi-hop Cypher patterns, shortest paths, centrality algorithms) over large interconnected datasets. Use SyntheticBrew when you want typed, deterministic retrieval over a curated set of entities without the operational cost of a separate graph database.
vs Palantir AIP / Foundry Ontology
Section titled “vs Palantir AIP / Foundry Ontology”Palantir Ontology is the conceptual original: a “digital replica of an organization” where AI agents navigate first-class objects, links, and actions. It is the closest enterprise analogue to Knowledge Graphs.
Key differences:
| Aspect | Palantir Ontology | SyntheticBrew Knowledge Graphs |
|---|---|---|
| Target market | Large enterprises | Mid-market and self-host developers |
| License | Commercial, enterprise contracts | Open-source BSL 1.1 |
| Pricing | Custom enterprise (typically $1M+) | Free self-host; Cloud tiers (Free / Personal / Pro) |
| Self-host | No | Yes (CE binary, Helm chart) |
| Setup time | Months (services-led deployment) | Hours (brewctl + helm) |
| Concept | Ontology with attached actions / models / decisions | Ontology of entities + auto-MCP tools (read-only in MVP) |
Positioning: Knowledge Graphs are “Palantir Ontology for the rest of us, open source” — same concept, much narrower scope, mid-market accessible.
vs Apollo GraphQL MCP Server
Section titled “vs Apollo GraphQL MCP Server”Apollo’s MCP Server converts existing GraphQL operations into MCP tools, so an agent calling MCP tools effectively executes GraphQL queries.
Key differences:
| Aspect | Apollo MCP Server | SyntheticBrew Knowledge Graphs |
|---|---|---|
| Input | Existing GraphQL schema and resolvers | New JSON Schema bundles |
| Use case | You already have a GraphQL API | You want a declarative ontology without a GraphQL backend |
| Data backing | Whatever your GraphQL resolvers return (DB, microservices, …) | The engine’s Postgres |
| Tool generation | One MCP tool per GraphQL operation | Three MCP tools per entity type (list_X, get_X, list_X_ids) |
Use Apollo MCP Server when you have a mature GraphQL API and want to expose it to agents. Use SyntheticBrew Knowledge Graphs when you do not have (or do not want to build) a GraphQL backend, and your domain fits the “small-to-medium catalog of typed entities” sweet spot.
When NOT to use Knowledge Graphs
Section titled “When NOT to use Knowledge Graphs”Knowledge Graphs are not the right primitive when:
- Cardinality > 10,000 per entity type — use an external MCP server backed by your existing system
- Records change more than once per day — use an external MCP server (Knowledge Graphs are GitOps-managed)
- You need multi-hop graph traversal (shortest path, PageRank, cycle detection in queries) — use Neo4j
- You only have unstructured text — use Knowledge Bases (vector RAG)
- You need true entity-to-entity ACID transactions — use a traditional database, not Knowledge Graphs
See the hybrid pattern guide for combining Knowledge Graphs with external systems.
Summary
Section titled “Summary”| Want | Use |
|---|---|
| Declarative typed catalogs for agents, open-source, GitOps-native | SyntheticBrew Knowledge Graphs |
| Auto-extract a graph from documents | LlamaIndex Property Graph Index or Cognee |
| Multi-hop graph traversal at scale | Neo4j + LangChain GraphRAG |
| Enterprise ontology with deep integration services | Palantir AIP |
| Expose existing GraphQL API to agents | Apollo MCP Server |
| Search narrative documents semantically | Vector RAG (Knowledge Bases) |
| Per-conversation user memory | Memory capability (Mem0 / Zep style) |