Capacity Planning with Graph Databases

When I started building the Engineering Intelligence Platform, I had a choice: relational database or graph database. I chose Neo4j, and that single decision shaped everything that followed.

The Relational Trap

Capacity planning in a relational model means lots of join tables. Engineer-to-skill mappings, engineer-to-project assignments, project-to-team relationships, skill-to-requirement matches. Every query that crosses these boundaries becomes a multi-join monster that is slow to write, slow to run, and impossible to maintain.

I tried the relational approach first with PostgreSQL. It worked for simple queries. But the moment someone asked "find me an engineer who knows TypeScript and Neo4j, is not on a critical-path project, and has worked with the payments team before," the query turned into five joins and a prayer.

Why Graphs Win Here

In Neo4j, that same query is a pattern match. Engineers are nodes, skills are nodes, projects are nodes. Relationships carry metadata like proficiency level, assignment dates, and utilization percentage. Traversing three hops in a graph is natural. Traversing three joins in SQL is painful.

The graph model also revealed patterns we never would have found in tables. We could see skill clusters — groups of engineers who shared overlapping expertise and could cover for each other. We could identify single points of failure — engineers who were the only person with a critical skill on a project.

The Hybrid Approach

I still use PostgreSQL for structured operational data: timesheets, project metadata, financial tracking. Neo4j handles the relationship-heavy queries. Qdrant provides vector search for semantic skill matching. Each database does what it does best.

The lesson for PMs who build: choose your data model based on the questions you need to answer, not the technology you already know. The right database makes hard problems trivial.