Graph engineering: model the edges first

A company asks why customers churn. The data exists — support tickets, usage events, invoices, the CRM — and every one of those lives in a table that knows what it is and nothing about what it is connected to. Answering the question means a join written by hand, then another, then a query nobody can maintain, and at the end a number whose provenance one person understands.

The question was never hard. The model was wrong. Churn is not a property of a customer; it is a pattern across the relationships a customer is part of — who they talk to, what they stopped using, which invoice they disputed, which champion left. If the relationships are not first-class in the model, every question about them is an archaeology project.

What first-class edges buy you

The shift is small to describe and large in effect. Instead of storing entities and inferring connections at query time, you store the connections as things in their own right, with their own attributes: when they formed, how strong they are, what evidence supports them, when they were last confirmed.

• Questions become traversals. "Which accounts have a support burden concentrated in one seat that has gone quiet?" is a walk, not a nine-table join.
• Depth stops being expensive to write. Two hops and five hops are the same shape of query, which is what makes second-order questions worth asking at all.
• Evidence travels with the claim. An edge that carries its source makes every downstream answer auditable, which is the difference between a dashboard people trust and one they check.
• New data sources connect instead of restructuring. Adding a channel means adding edges, not renegotiating a schema everything else depends on.

The tables tell you what exists. The edges tell you what is happening.

You probably do not need a graph database

Graph engineering is a modelling discipline, not a product category, and for most businesses Postgres is a perfectly good graph store. An edge table with source, target, type, weight, evidence and timestamps, a couple of well-chosen indexes, and recursive CTEs for traversal will carry you a very long way — and it keeps the graph next to the transactional data instead of in a second system that has to be kept in sync.

Reach for a dedicated graph engine when traversals are deep and unbounded, when the shape of the query is genuinely unknown ahead of time, or when the graph is the primary workload rather than a lens over it. Those are real cases. They are just rarer than the vendor material suggests, and adopting one early costs you every tool your team already knows.

Where this meets AI

The current default for grounding a model in company data is to embed documents and retrieve by similarity. It works well for "what does our policy say about X" and poorly for anything requiring more than one hop, because similarity has no notion of connection. Ask a vector store which customers resemble the three that churned last quarter and you get documents that use similar words.

A graph gives an agent something better than passages: it gives it a structure to walk, with the relationships already named. In practice the two compose — retrieval to find the entry point, traversal to gather the neighbourhood that actually answers the question. That combination is the single largest quality improvement we have made to grounded agents, and it is a data modelling change rather than a model change.

Starting without a rewrite

Nobody should stop what they are doing to build a graph. The approach that works is to start from one question the business already cares about and cannot currently answer, and model only the edges that question needs.

1. Write the question down in the words the business uses. Not the query — the question.
2. Name the entities in it, and then name the relationships. The relationships are the part usually missing from your schema; that absence is the finding.
3. Build only those edges, from the sources you already have, as a view or a materialised table beside your existing data.
4. Answer the question. Then ask what the next one is — it will nearly always reuse most of the edges you just built.

Three or four iterations of that and there is a graph in the middle of the business, built entirely out of questions somebody wanted answered. That is a different artefact from a graph built to be complete, and it is the only kind we have seen get used.