Making sense of everything: A personal knowledge graph experiment

The question kept nagging at me: what connects my invoices, blog posts, calendar events, and time tracking? Each system worked fine on its own, but the connections between them were invisible. That's the problem I'm trying to solve.

My Current Limitations

Right now, everything sits in relational databases. Tables, rows, foreign keys. It works. It's reliable. But when I want to answer questions like:

"What blog posts relate to this client project?"
"Which ideas keep coming up across different contexts?"
"What patterns exist in how I spend my time?"

I'm stuck writing complex JOIN queries or doing mental gymnastics to connect the dots myself.

Relational databases are brilliant at storing data. They're less brilliant at showing me how everything connects.

That's where graph databases come in.

What is a Personal Knowledge Graph?

A knowledge graph isn't just about storing data: it's about understanding relationships.

Consider this example:

A blog post mentions a client.
That client has an invoice.
The invoice relates to a project.
The project appears in calendar events.
Those events connect to time tracking entries.
The time entries link back to blog ideas I wrote about while working.

In a relational database, these connections exist as foreign keys buried in tables. In a graph database, the connections are first-class citizens. They're visible, queryable, and explorable.

The goal isn't to store more data. It's to surface patterns and connections I wouldn't otherwise see.

That's powerful.

The Technical Stack I'm Considering

Graph Database Options

I've been researching options, and Neo4j keeps coming up as the standard choice.

Why Neo4j?

Mature ecosystem: It's been around, battle-tested, and well-documented.
Cypher query language: Intuitive for querying graphs (more on this later).
Built-in visualization tools: See your graph, don't just query it.
Active community: Lots of examples, plenty of support.

But there are alternatives worth considering:

Memgraph: Faster for real-time queries, fully Cypher-compatible.
PostgreSQL with Apache AGE: Adds graph capabilities to an existing relational DB.

I'm leaning toward Neo4j for now. It's the path of least resistance, and I'd rather prove the concept works before optimizing for edge cases.

Why the Graph Augments, Not Replaces

The key insight: I'm not replacing my current systems.

The graph database sits alongside them as a lens. A way to explore connections without disrupting how things already work.

My invoices stay in the invoicing system. My blog posts stay in the content management system. My calendar stays in my calendar app.

The graph just mirrors the relationships between them.

Entity Extraction Approach

To build this graph, I need to identify entities across different data sources. That's where entity extraction comes in.

I'm planning a hybrid approach:

AI-powered extraction:

Use GPT/Claude to identify entities in unstructured text.
"Find all mentions of clients, projects, and topics in these blog posts."
Extract entities from calendar event descriptions.
Pull themes and keywords from notes.

Rule-based extraction:

Structured data (invoices, time entries) already has clear entities.
Use simple parsing rules to extract client names, project codes, dates.
Tag relationships based on explicit links (e.g., invoice → client → project).

The hybrid approach gives me flexibility. AI handles the messy, unstructured stuff. Rules handle the clean, predictable data.

The Hybrid Architecture

The architecture I'm considering:

┌─────────────────┐
│  Memory Bank    │ ← Source of truth
│  (Articles,     │    (existing system)
│   Notes, etc.)  │
└────────┬────────┘
         │
         │ Periodic Sync
         ↓
┌─────────────────┐
│  Graph Database │ ← Discovery lens
│  (Neo4j)        │    (new layer)
└────────┬────────┘
         │
         │ Insights
         ↓
┌─────────────────┐
│ Content Pipeline│ ← Feed ideas back
│ (Blog, Ideas)   │
└─────────────────┘

The memory bank remains the source of truth. I'm not moving data into the graph. I'm syncing relationships.

The graph serves as a lens for discovery. Do you want to see everything related to a specific project? Query the graph. Do you want to spot patterns in content themes? Query the graph.

Insights feed back into the content pipeline. When the graph surfaces interesting connections, those become blog ideas, project insights, or workflow improvements.

It's a cycle. Not a replacement.

Practical Use Cases

What would I actually do with this?

1. "Show me everything related to Project X"

One query returns:

All invoices for that client.
Time tracking entries.
Calendar events.
Blog posts that mention it.
Related ideas I've captured.

Instead of searching five different systems, I get a complete picture.

2. Spotting emergent patterns in content themes

Which topics keep appearing across:

Blog post ideas.
Notes from articles I've saved.
Conversations in calendar events.
Projects I'm working on.

The graph can show me clusters of related concepts I didn't consciously connect.

3. Identifying workflow bottlenecks

If I see a pattern where:

Time entries are high.
But deliverables are low.
And calendar events are fragmented.

The graph might reveal I'm context-switching too much between small tasks.

4. Discovering idea clusters worth exploring

Sometimes unrelated ideas connect in unexpected ways. The graph can surface those connections and suggest:

"These three blog drafts all relate to the same underlying theme."
"This client project connects to a topic you've been researching."

That's the real value. Insights I wouldn't have spotted otherwise.

The Proof of Concept Approach

I'm not diving in blindly. I'm taking a practical, iterative approach.

Week 1: Export sample data, design initial schema

Pull a subset of real data (10-20 blog posts, some invoices, calendar events).
Design the initial graph schema (nodes, relationships).
Keep the schema simple for initial iteration.

Week 2: Load into Neo4j, write initial queries

Set up a local Neo4j instance.
Import the sample data.
Write 3-5 Cypher queries that answer real questions.

Week 3: Evaluate and decide

Does the graph reveal insights I couldn't previously access?
Is it worth the overhead of maintaining sync?
What would it take to scale this up?

If the answer to "Does this give me new insights?" is no, I'll stop here. No point building infrastructure for its own sake.

If the answer is yes, then I'll build out the sync tooling and expand the dataset.

Graph Schema Design

My initial thinking on the schema.

Nodes (Entities):

BlogPost: Published posts and drafts.
Idea: Blog ideas, notes, half-formed thoughts.
Client: People or companies I work with.
Project: Specific work engagements.
Tag: Topics, themes, keywords.
CalendarEvent: Meetings, blocks of time.
TimeEntry: Tracked work time.
Invoice: Financial records.

Relationships (Connections):

RELATES_TO: Generic connection between entities.
MENTIONS: One entity explicitly references another.
INSPIRED_BY: An idea came from another entity.
PART_OF: Hierarchical relationships (project → client).
TAGGED_WITH: Entity has a specific tag.
SCHEDULED_FOR: Time-based connections.

Properties (Metadata):

Both nodes and relationships can have properties:

Nodes: title, created_at, status, content_summary.
Relationships: strength (how strong is the connection?), created_at, context (why are they connected?).

Example Query

A simple Cypher query to get started:

MATCH (p:BlogPost)-[r:MENTIONS]->(c:Client)
WHERE c.name = "Acme Corp"
RETURN p.title, r.context, p.published_at
ORDER BY p.published_at DESC

This finds all blog posts that mention a specific client, along with context about why they're connected.

That's the kind of query that would take multiple database joins in a relational setup. In a graph, it's one line.

Challenges and Considerations

I'm going into this eyes open. There are real challenges.

Data quality: Garbage in, garbage out

If my entity extraction is sloppy, the graph will be useless. Misspelled client names, inconsistent tags, vague relationships. All of that degrades the value.

I'll need to be disciplined about:

Consistent naming conventions.
Clear relationship definitions.
Regular cleanup and validation.

Maintaining sync between systems

The graph is only useful if it stays up to date. That means:

Building a sync process (daily? weekly?).
Handling updates and deletions.
Dealing with conflicts when data changes.

This is infrastructure overhead. It has to be worth it.

Query performance at scale

Neo4j is fast for graph queries, but as the dataset grows:

How many nodes can I realistically handle?
Do I need to index specific properties?
Will complex multi-hop queries slow down?

I won't know until I test with real data.

When is a graph database overkill, and when is it genuinely useful?

Not every problem needs a graph database. Sometimes a JOIN query is fine.

I need to stay honest about:

Is this actually providing new insights?
Or am I building complexity for its own sake?

The proof of concept will answer that.

Why This Matters

This isn't just about exploring new technology (though that's certainly a component).

Better content creation through understanding connections

When I can see how ideas relate across blog posts, notes, and projects, I write better content. I spot themes earlier. I develop ideas more fully.

Workflow optimization by seeing bottlenecks

If the graph shows me patterns in how I spend time vs what I deliver, I can optimize my process. Less time on busywork, more on high-value work.

Creative insights from unexpected patterns

The best ideas often come from unexpected connections. The graph surfaces those connections automatically.

Building a true second brain, not merely storage

Right now, my systems are just storage. This would turn them into something more: a living map of how everything connects.

That's the ultimate goal.

Next Steps

My immediate plan:

This week:

Export a sample dataset (blog posts, invoices, calendar events).
Design the initial schema in a diagram.

Next week:

Set up Neo4j locally.
Import the sample data.
Write 5 test queries to validate the concept.

Week after:

Evaluate the results.
Decide if it's worth scaling up.
Document what I learned (whether it works or not).

I'll be documenting the process as I go. If it works, I'll share how I built it. If it doesn't, I'll share why it didn't.

Either way, the learning is the point.

Conclusion

This is an experiment, not a finished solution.

I don't yet know if a graph database will genuinely improve my workflow, or if it's solving a problem I don't truly have.

But I'm curious enough to find out.

The beauty of documenting this publicly is that I get to learn in the open. If you're exploring similar ideas (building personal knowledge graphs, experimenting with entity extraction, trying to make sense of scattered data) I'd love to hear what you're trying.

Let's figure this out together.

Interested in following along? I'll be sharing updates as I build this out. You can reach out on LinkedIn or Twitter if you're experimenting with similar ideas.