I set out to climb "graph engineering." It was the ladder I'd been standing on for 25 years.

A developer with 25 years in enterprise infrastructure argues that graph engineering is essentially a new name for entity-relationship thinking, a core discipline of enterprise architecture. The developer claims that concepts like dependency maps, impact analysis, and failure domains are graph traversal in disguise, and that while the database technology is new, the way of seeing is not. The developer acknowledges that some aspects, such as who builds the graphs, are genuinely new.

Part 1 of this series left one rung unclimbed. Rung 12, graph-based orchestration, was the frontier where I assumed the real engineers lived. Before I climb anything, I do my homework, so I set out to answer a prior question first: what does "graph" actually buy you? The term is everywhere right now graph engineering, GraphRAG, knowledge graphs, graph databases , and it arrives wrapped in the specific tone vendors use when they want you to feel behind. Somewhere in the second hour of reading, I stopped taking notes on what was new and started keeping a different list: what wasn't. Strip the vendor language and graph engineering is this: you structure knowledge as entities and typed relationships instead of flat documents, so that a system an AI, a search engine, a query can traverse the connections rather than just keyword-match the text. A customer isn't a row; it's a node with edges to orders, tickets, and other customers. A function isn't a string in a file; it's a node with edges to everything that calls it. Once knowledge has that shape, you can ask questions that flat storage can't answer well: not "which documents mention X" but "what is two hops downstream of X, and what breaks if it goes away?" That's the whole idea. The three flavors you'll see hyped are GraphRAG knowledge graphs feeding LLM retrieval , code graphs call chains and dependency structure for AI coding agents , and entity graphs for search schema.org structured data feeding Google's Knowledge Graph . Read that definition again, slowly, and if you've spent time in enterprise infrastructure you may feel the same recognition I did. I spent twenty-five years in enterprise infrastructure virtualization, storage, cloud, data centers and the last stretch of it running an operations organization from the executive seat. Here is what that work actually consists of, underneath the job titles. It consists of dependency maps: which application sits on which server, which server sits in which cluster, which cluster depends on which storage array and which network path. Every serious infrastructure organization keeps some version of this — a CMDB, a topology diagram, an impact matrix — because the alternative is finding out the dependencies exist during the outage. It consists of impact analysis, which is the question "if this component fails, what stops working three layers up?" I want you to notice the shape of that question. It is a reachability query. It is graph traversal. When an architect walks the room through the blast radius of a change, she is doing at a whiteboard exactly what a graph database does with an index. It consists of entity-relationship modeling: the literal ERD, drawn for decades before anyone attached "engineering" to "graph." It consists of failure domains, which are subgraphs. It consists of the org chart you redraw during an incident to figure out who owns the broken edge. We did not call the dependency map a knowledge graph — we called it Tuesday. I want to be precise about the claim I'm making, because there's an overreach version of this article and I don't intend to write it. I am not claiming that maintaining topology diagrams makes anyone a graph engineer, and the people who build Neo4j clusters and tune traversal performance for a living are doing real, specialized work I have not done. The claim is narrower and, I think, more useful: graph engineering is a new name for entity-relationship thinking, and entity-relationship thinking is the load-bearing discipline of enterprise architecture. The database is new to me. The way of seeing is not — it's the thing the career was made of. Because the honest version of this article has to include it: some of it is genuinely new, and pretending otherwise would be its own kind of hype. What's new is who builds the graph. Constructing these things used to be the expensive part — armies of analysts hand-curating entities and relationships, which is why so many CMDB projects died of staleness. Large language models changed that: they can now extract entities and relationships from unstructured text at scale, which means the graph can be built and maintained by machines. That one is real, not marketing. What's new is who traverses it. GraphRAG letting an LLM walk a knowledge graph at question-answering time instead of fuzzy-matching document chunks measurably improves the multi-hop questions that plain retrieval fumbles, the "how is A connected to C through B" class of question. On enterprise corpora of millions of documents, or codebases of hundreds of thousands of lines spread across dozens of services, this earns its infrastructure. That last clause is the pivot of this whole piece, so let me say it plainly: the technique is real, and it is scale-gated. Every impressive graph result I found lives where the corpus is enormous, the hops are many, and the alternative is armies of humans. Which raises the question I actually needed answered — what happens at my scale? I have a code knowledge-graph tool wired into my agent sessions — full graph queries, call-chain tracing, the works. It arrived with the same energy as the rest of the hype cycle: always use the graph first, says its own protocol. This week I checked what it had actually indexed, and the answer was a single project. And of everything on this machine, the one it holds is my command center, the folder that is almost entirely markdown. The tool built to trace call chains through half a million lines of enterprise code sat down at my estate and indexed a pile of prose. That's not a failure; it's a finding. My repositories are small enough that an agent reading files and searching text handles them without ceremony; the graph never gets the chance to earn its overhead. The scale gate swings both ways, and at solo scale it swings shut. But here's the part that made me laugh, and then made me write this article. The graph that does run my operation — the one doing real work every single day — isn't in a database at all. Readers of Part 1 know my estate runs on durable memory: context files in every repository, facts in markdown files, an index the agent loads at the start of every session, session records with closed doors no future session may reopen. What I didn't say in Part 1, because I didn't have the vocabulary yet, is what that system is structurally. The memory files are nodes. The links between them are edges: most files carry references to their related files by name. The index is the entry point, and the traversal engine is whichever model shows up that morning: it loads the index, follows the links relevant to the day's work, and ignores the rest. When a fact changes, one node gets edited and everything pointing at it stays consistent, which is precisely the maintenance property people buy graph databases to get. That's entities, typed relationships, and traversal: a knowledge graph. It's written in the world's most boring format, it costs nothing, it survived a model upgrade without blinking models are cattle, the files are the pet , and I built it by instinct, because a career of watching knowledge die in flat documents teaches you to link things or lose them. At enterprise scale you need the database. At my scale, the discipline is the product, and the discipline is free. I used to sit on the buying side of the table when vendors pitched, so here is the rule I'd give any small operator who is currently being made to feel behind about graphs. It has three lines. If your revenue depends on search, you should already be doing the one graph flavor that pays at small scale: structured data. Schema.org markup on your site is you feeding the world's largest knowledge graph, Google's, and telling it exactly what your business, products, and pages are. It's unglamorous, it's a solved practice, and it moves the only graph that sends small businesses money. If you have millions of documents, dozens of services, or questions that hop across many systems, the new tooling is real — evaluate it. This is where GraphRAG and code graphs live honestly. If a vendor can't show you the multi-hop question your current stack fails at, they're selling you the enormity of the technology instead of a problem you have. Everything else is an infrastructure hobby. A graph database serving a corpus that fits in a filing cabinet is a motorcycle for hauling a wallet. Link your files, keep an index, maintain the discipline of entities and relationships in whatever boring format survives — and spend the difference on something that ships. Buy the discipline before the database. If you already have the discipline, check whether you need the database at all. Part 1's scoreboard had a bullet I called the graduation evals: I formally evaluated the no-code builder everyone recommends for people like me and found I was already doing everything it offered; I read up on "loop engineering" and found I'd been doing it before I knew the term. Both produced the same strange, quiet pride — progress measured by a side-by-side verdict, not a feeling. This is the third one, and it's the biggest, because this time the verdict covered more than the past seven months. It reached back through the whole career. The industry drew a frontier, I packed for the expedition, and the frontier turned out to be a territory I'd been mapping since before the term existed. Rung 12 still stands, for the record. Graph-based orchestration , agents coordinated through graph structures, is its own climb, I haven't made it yet, and it will get its installment when there are results to report rather than intentions. The house rule holds: measured, not promised. But when I climb it, the posture will be different. The rung I was afraid of sits on a ladder I've been standing on for twenty-five years.