What Is a Knowledge Graph? (Plain English)

A knowledge graph is a database that stores information as entities (nodes) connected by relationships (edges). Think of it as a map of how things relate to each other, rather than a spreadsheet of isolated facts.

The difference matters when you need to answer questions like "Which clients share board members with companies we're auditing?" or "What regulatory changes affect our top 20 clients in the pharmaceutical sector?" Traditional databases force you to write complex JOIN queries that get exponentially slower as relationships multiply. Knowledge graphs make these queries fast and natural.

In a SQL database, relationships are afterthoughts. You store them as foreign keys in separate tables, then reconstruct them with JOINs at query time. This works fine for simple lookups but breaks down when you need to traverse multiple levels of connection.

In a knowledge graph, relationships exist as actual objects with their own properties. The relationship "John reports to Sarah" can carry metadata like start date, reporting percentage, and approval authority. You can query relationships directly without reconstructing them from scattered table references.

Example: Finding all conflicts of interest in a client portfolio.

SQL approach: Write recursive CTEs, join across 6+ tables, wait 45 seconds for results, hope you didn't miss an edge case.

Graph approach: Write a pattern match that says "find clients connected through shared board members or investment holdings," get results in under 2 seconds.

Most firms don't need a knowledge graph. Vector search handles 80% of knowledge management use cases. You need a graph when relationships between entities matter as much as the entities themselves.

Use Case 1: Multi-Hop Relationship Queries

You need to traverse 3+ levels of connection regularly.

Concrete example: A law firm tracking corporate ownership structures. Client A owns 30% of Company B, which owns 45% of Company C, which has a pending lawsuit against Client D. You need to flag this conflict before accepting new work.

In a graph: One query pattern, sub-second response.

In SQL: Recursive query that times out or requires pre-computed materialized views you'll forget to update.

Use Case 2: Schema Evolution Without Migration Hell

Your data model changes frequently and unpredictably.

Concrete example: A consulting firm building a competitive intelligence system. You start tracking companies and their executives. Then you add products, patents, regulatory filings, news mentions, and social media activity. Each addition requires new entity types and relationship types.

In a graph: Add new node types and edge types without touching existing data. No schema migration scripts.

In SQL: Write ALTER TABLE statements, update foreign key constraints, rebuild indexes, pray nothing breaks.

Use Case 3: Heterogeneous Data Integration

You're combining structured data, documents, and external APIs

into one queryable system.

Concrete example: An accounting firm building a client risk assessment tool. You need to combine:

• Client financial data from your practice management system
• Industry news from RSS feeds
• Regulatory filings from SEC EDGAR
• Internal audit notes from SharePoint
• Relationship data from LinkedIn

In a graph: Each source becomes nodes and edges. Query across all of them with one pattern match.

In SQL: Build a complex ETL pipeline, normalize everything into a rigid schema, lose context in the process.

Nodes (Entities)

Nodes represent things. Each node has:

• A unique identifier (usually a URI or UUID)
• A type (Person, Company, Document, Transaction)
• Properties (name, date, amount, status)

Example node in property graph format:

(:Person {
  id: "emp_1847",
  name: "Sarah Chen",
  title: "Partner",
  practice_area: "Tax",
  bar_admission: ["NY", "CA"],
  start_date: "2018-03-15"
})

Edges (Relationships)

Edges connect nodes and carry meaning. Each edge has:

• A source node
• A target node
• A relationship type
• Optional properties

Example edge:

(:Person {id: "emp_1847"})-[:REPORTS_TO {
  start_date: "2022-01-01",
  reporting_percentage: 100,
  approval_authority: "up_to_50k"
}]->(:Person {id: "emp_0234"})

Query Languages

Cypher (Neo4j): Most readable, best for pattern matching.

MATCH (client:Client)-[:INVESTED_IN]->(company:Company)
      <-[:BOARD_MEMBER]-(person:Person)-[:BOARD_MEMBER]->
      (other:Company)<-[:INVESTED_IN]-(other_client:Client)
WHERE client.id <> other_client.id
RETURN client.name, other_client.name, person.name, company.name

SPARQL (RDF stores): Standard for semantic web, verbose but powerful.

Gremlin (TinkerPop): Works across multiple graph databases, steeper learning curve.

Step 1: Model Your Domain (2-4 hours)

Draw your entity types and relationship types on a whiteboard. Don't overthink it.

For a law firm:

• Entities: Client, Matter, Attorney, Court, Judge, Opposing_Counsel, Document
• Relationships: REPRESENTS, ASSIGNED_TO, FILED_IN, PRESIDED_BY, OPPOSES, CITES

Start with 5-8 entity types and 8-12 relationship types. You'll add more later.

Step 2: Choose Your Database (1 hour)

Neo4j: Best overall choice. Mature, fast, excellent documentation. Use the free Community Edition for up to 34B nodes.

Amazon Neptune: Use if you're already on AWS and want managed infrastructure. Supports both property graphs (Gremlin) and RDF (SPARQL).

Azure Cosmos DB (Gremlin API

): Use if you're committed to Azure. Less mature than Neo4j but improving.

Don't use: ArangoDB, OrientDB, or JanusGraph unless you have specific requirements they uniquely solve.

Step 3: Load Initial Data (4-8 hours)

Write scripts to transform your existing data into nodes and edges. Use the database's bulk import tools, not individual INSERT statements.

Neo4j example using LOAD CSV:

LOAD CSV WITH HEADERS FROM 'file:///clients.csv' AS row
CREATE (:Client {
  id: row.client_id,
  name: row.name,
  industry: row.industry,
  revenue: toInteger(row.revenue)
})

Step 4: Add Relationships (2-4 hours)

Create edges between your nodes. This is where the value emerges.

LOAD CSV WITH HEADERS FROM 'file:///matters.csv' AS row
MATCH (c:Client {id: row.client_id})
MATCH (a:Attorney {id: row.attorney_id})
CREATE (c)-[:HAS_MATTER {
  matter_id: row.matter_id,
  start_date: date(row.start_date),
  status: row.status
}]->(a)

Step 5: Write Your First Queries (1-2 hours)

Start with simple pattern matches, then add complexity.

Find all clients of a specific attorney:

MATCH (a:Attorney {name: "Sarah Chen"})<-[:HAS_MATTER]-(c:Client)
RETURN c.name, c.industry

Find potential conflicts (clients with shared board members):

MATCH (c1:Client)-[:HAS_BOARD_MEMBER]->(p:Person)<-[:HAS_BOARD_MEMBER]-(c2:Client)
WHERE c1.id < c2.id
RETURN c1.name, c2.name, p.name

Step 6: Integrate with Your Application (4-8 hours)

Use the official driver for your language. Don't write raw HTTP requests.

Python example with Neo4j:

from neo4j import GraphDatabase

driver = GraphDatabase.driver("bolt://localhost:7687", auth=("neo4j", "password"))

def find_conflicts(client_id):
    with driver.session() as session:
        result = session.run("""
            MATCH (c:Client {id: $client_id})-[:HAS_BOARD_MEMBER]->(p:Person)
                  <-[:HAS_BOARD_MEMBER]-(other:Client)
            RETURN other.name AS conflicted_client, p.name AS shared_person
        """, client_id=client_id)
        return [dict(record) for record in result]

Mistake 1: Treating a graph database like SQL with different syntax. Don't normalize everything into tiny nodes. It's fine to store properties directly on nodes instead of creating separate nodes for every attribute.

Mistake 2: Creating a "god node" that connects to everything. If you have a node with 100,000+ edges, you've modeled something wrong. Break it into more specific relationship types.

Mistake 3: Ignoring indexes. Create indexes on properties you'll query frequently, especially node IDs and relationship types.

Mistake 4: Loading data without a plan for updates. Decide upfront whether you'll do full reloads, incremental updates, or event-driven sync.

Vector search finds semantically similar content. Knowledge graphs find structurally related entities.

Use vector search when: You need to find documents or passages similar to a query, even if they use different words.

Use a knowledge graph when: You need to traverse explicit relationships between entities across multiple hops.

Use both when: You want semantic search results filtered by relationship constraints. Example: "Find documents about tax law similar to this memo, but only from matters where we represented pharmaceutical companies."

Build a knowledge graph when you regularly ask questions that require traversing 3+ levels of relationships, when your data model evolves faster than you can write migration scripts, or when you're integrating heterogeneous data sources that share entities but not schemas.

Don't build a knowledge graph just because it sounds sophisticated. Most firms get more value from vector search plus a well-designed SQL database. But when you hit the relationship complexity wall, graphs are the only practical solution.

Start with Neo4j Community Edition, model 5-8 entity types, load a subset of your data, and write 10 real queries you need to answer. If those queries are faster and simpler than your current approach, expand from there. If not, you probably don't need a graph.