How to build a knowledge graph from the SQL database you already have

When engineering teams realize vector search can't handle multi-hop enterprise logic, the standard response is expensive panic. Vendor playbooks say you must hire graph consultants, license a dedicated graph database, and migrate transactional tables into Neo4j or Amazon Neptune. Months pass, budget burns, and core operational data stays locked in PostgreSQL, MySQL, or SQL Server.

Here's the operational reality: the graph you need is already latent in your schema. Foreign keys, primary keys, and junction tables aren't database artifacts. They're semantic entities and directed edges designed years ago. You don't need a rip-and-replace overhaul. You need an automated mapping layer that projects your SQL schema into a semantic graph.

The relational trap: why Text-to-SQL fails AI agents

Many enterprise architecture teams attempt to solve graph reasoning by feeding database schemas to LLMs and executing generated SQL via Text-to-SQL. In production, this approach collapses under real-world schema complexity.

Relational tables store raw facts efficiently, but obscure relationship semantics. When an AI agent answers a multi-hop query, such as 'Which accounts with open high-severity support tickets have key stakeholders who changed companies in the last 90 days?', Text-to-SQL requires five-table JOINs across ambiguous keys. The LLM loses context, hallucinates join conditions, or generates queries that trigger catastrophic table scans.

A graph representation exposes these connections natively. Instead of joining five tables at query time, the system traverses pre-indexed semantic edges without runtime JOIN planning.

The 3-step RDB-to-graph mapping protocol

Start from information_schema: list every table, then every foreign key constraint. That catalog query is the honest first move, and it tells you the size of the projection before you write a line of graph code. This approach has a standards lineage too: the W3C called the direct mapping R2RML, and the vendor tools of the last decade wrapped it. The difference now is why you are doing it: not reporting, but agents that need edges they can walk and cite.

Translating relational schemas into a semantic knowledge graph follows three deterministic rules. You can run this transformation dynamically or as a lightweight background sync.

• Step 1: Entities from Primary Keys. Every core table maps to a Graph Node Label (for example, `customers` becomes `:Customer`). The primary key becomes the immutable `entity_id`, and table columns map directly to node properties.
• Step 2: Semantic Edges from Foreign Keys. Every foreign key constraint maps to a Directed Edge. Column names or schema rules supply active verbs: `orders.customer_id` becomes `(:Customer)-[:PLACED_ORDER]->(:Order)` rather than an anonymous integer match.
• Step 3: Junction Tables as First-Class Relationships or Nodes. Many-to-many join tables (`account_contacts`) transform into property-rich relationships. Fields like `role`, `is_primary`, and `start_date` attach directly to the edge `(:Contact)-[:WORKS_AT {role: 'VP Engineering'}]->(:Account)`.

In Relmint, the lab's signal-based sales intelligence platform, we used this protocol to map complex executive movement across corporate accounts without touching the core relational write-path.

Production implementation: Pydantic and Cypher projection

Below is a practical Python pattern showing how relational rows project into Cypher graph assertions using structured Pydantic models:

• class EntityNode(BaseModel): label: str; entity_id: str; properties: dict[str, Any]
• class SemanticEdge(BaseModel): source_id: str; target_id: str; relation: str; properties: dict[str, Any]
• Transformation Logic: def project_fk_to_edge(fk_row) -> SemanticEdge: return SemanticEdge(source_id=f'contact:{fk_row.contact_id}', target_id=f'account:{fk_row.account_id}', relation='STAKEHOLDER_AT', properties={'role': fk_row.title, 'is_active': True})
• Generated Cypher: MERGE (c:Contact {id: $source_id}) MERGE (a:Account {id: $target_id}) MERGE (c)-[r:STAKEHOLDER_AT]->(a) ON CREATE SET r.role = $role, r.is_active = true ON MATCH SET r.role = $role

This mapping engine converts relational change data capture (CDC) events into graph updates without touching the transactional workload.

Querying the dual system: SQL for accounting, graph for AI

The goal isn't replacing SQL. SQL stays the system of record: exact aggregations, core reporting, and the compliance trail. The knowledge graph serves as an intelligence index sitting alongside your primary operational store.

In modern Postgres environments, extensions like Apache AGE let you query graph structures directly inside your database instance using openCypher syntax. Alternatively, streaming relational CDC events via Debezium into a lightweight graph index gives AI agents zero-latency multi-hop reasoning capabilities.

We deployed this dual-architecture in FundHouse to reconcile complex corporate hierarchies and in Alfred to give GTM agents instant access to account relationship histories.

Architectural summary and next steps

Before signing off on a costly graph database migration, audit your existing relational schemas. Most of the semantic graph structure required to power your enterprise AI strategy is already sitting in those schemas.

• Audit foreign key constraints and define active verb labels for each key relationship.
• Expose junction table metadata as edge attributes rather than flattening them.
• Deploy a lightweight projection layer or Postgres graph extension rather than an expensive standalone graph cluster.
• Require AI agents to query explicit graph edges rather than executing ungrounded Text-to-SQL joins.

Go deeper: Relmint case study