When engineering teams realize vector search can't handle multi-hop enterprise logic, the standard response is expensive panic: hire graph consultants, license a dedicated graph database, migrate transactional tables into Neo4j or Neptune.
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 lineage is old and proven: W3C's R2RML standard (2012) defined exactly this mapping for the semantic web era. The recipe: discover the schema through information_schema, map high-value tables to entities, map foreign keys to typed relationships, add the constraint your DB docs already imply (a job change needs a source), and require every answer to cite its nodes.
One Cypher-specific scar to share: MERGE with a role property duplicates edges on role change. The correct pattern is a bare-edge MERGE with ON CREATE / ON MATCH SET for the properties. The database docs don't warn you; the failure teaches it.
The full essay walks the pattern on a live schema, with the Cypher, the governance rules, and the MDM caveat:
https://builder-singh.com/writing/build-knowledge-graph-from-sql-database
Top comments (0)