No — and migrating everything into one is the expensive version of this project. Most requests never need a graph: text is retrieval, numbers are a relational query, and only relationships need traversal. What you need at the front is a routing layer. Behind it, treat graphs as disposable projections — the graph that answers one question is rarely the one that answers the next. What can't be disposable is identity: if one projection merges two entity names and another doesn't, every answer crossing them is silently wrong.
The failure mode is a year of platform work before anyone has used anything. It starts with the assumption that the graph is the destination for all your data, when for most requests it is the wrong tool:
So the durable piece at the front is a component that reads a registry and decides which kind of question this is. It is a decision-maker, not a store. Most of the systems underneath it stay exactly where they are.
A graph encodes a set of choices — what counts as a node, which edges are worth keeping, what threshold makes a relationship real. Those choices are fitted to a question. Change the question and the useful structure changes with it, which is why one general-purpose graph tends to serve every use case adequately and none of them well.
Treating them as templated projections — second-order exposure, structural peers, topic momentum, historical analogues — rebuilt on a schedule and discarded when the model changes, makes each one cheap enough to be wrong about. If building a new projection requires a data scientist per projection, the design has failed; it should be configuration.
Disposable graphs become sprawl unless three things underneath them hold still:
The graphs are disposable. Identity, the contract, and lineage are not.
Resolution is the compounding-error stage. A bad merge early doesn't announce itself — it propagates through every later stage, and nothing downstream can tell the difference between a genuine relationship and two entities wrongly treated as one.
A reference ontology helps and does not solve it: it turns clustering into linking, which is a better-defined problem, but it relocates the hard cases rather than eliminating them — entities not in the reference, ambiguity the reference can't settle, granularity mismatches, temporal validity, and the reference's own error rate. The rule that survives either way: never silently merge. Flag unresolved rather than guess confidently wrong.
"Huge task" is only true if you build it as a program. Shrink it instead: one desk, one question that is expensive to answer today and that somebody actually needs answered, the smallest projection that answers it, over the unstructured slice only. Then measure whether it changed what someone does.
Two risks worth naming before you start, because both are near-impossible to retrofit: entitlements — a layer composing evidence across governed systems will happily answer from a source the asker isn't cleared for, because nothing told it not to — and point-in-time correctness, since a continuously rebuilt graph breaks backtests silently. Throw away the instance, keep the recipe and an as-of stamp.
The short answer above is ours, and we've written at length about how we got to it: