A graph-database extension got installed, tested, proven correct, and kept running for two weeks on the explicit reasoning that it might be useful later. Then it got removed entirely — not because anything about it was broken, but because two weeks of not needing it turned out to be the actual answer to whether it was worth keeping.
What the pilot actually proved
Before any decision about keeping or removing the extension, a real pilot ran against real production data: a bounded subset of the corpus's link graph, loaded correctly, queried with real graph-traversal syntax, and verified against the equivalent relational data to confirm nothing was lost or misrepresented in the conversion. The pilot wasn't a demo running against toy data — it used the same tables the production system depends on, read-only, writing only into a disposable namespace built for exactly this test.
The two reasons it stayed installed at first
The pilot's own queries came back with reasonable, ordinary-looking execution plans — nothing pathological, nothing that suggested the underlying engine couldn't handle real graph shapes. And the storage footprint, in one comparison, looked smaller than the equivalent relational data. On that basis, the decision at the time was to leave the extension installed rather than remove it immediately: proven to work, not currently needed for anything specific, but plausible enough that a future feature wanting real graph-query capability — variable-length path traversal, neighborhood queries, the kind of thing that's awkward to express in plain SQL — might want it.
What changed two weeks later
Nothing broke. Nothing failed. The decision to keep it got revisited in an ordinary conversation about what was actually still standing unused, and re-examined against what had actually happened since: no feature anywhere in the roadmap had needed graph-query ergonomics in the intervening weeks. The theoretical future need that justified keeping the extension installed remained exactly as theoretical as it had been at the start — just two weeks further from the point where it was first proposed, with nothing concrete having materialized to make it less hypothetical.
The second look at the numbers that justified keeping it
The storage comparison that had originally looked favorable didn't survive being checked again, carefully. The original comparison measured a small, simplified graph node — four fields — against the full relational table it stood in for, which had over twenty columns of its own. A genuinely comparable comparison — the actual edges in the graph pilot against the actual raw bytes of the equivalent relational link data — showed the opposite result: the graph representation came out roughly twice as large, not smaller. The apparent storage advantage had been an artifact of comparing a stripped-down version of one side against the full version of the other, not a real property of the two approaches.
What was left once both justifications were gone
With the storage advantage reversed on a fair comparison, and no real feature need having appeared in the time since installation, the entire remaining case for keeping the extension came down to one honest, narrower claim: read-query ergonomics for a kind of question — deep graph traversal — that nothing currently being built actually asks. That's a real property, and a real thing the extension does better than plain SQL. It's also not, on its own, worth the ongoing cost of carrying working infrastructure — provisioning code, deployment roles, pilot scripts — for a need that stayed hypothetical the entire time it was evaluated.
Removing it cleanly, because it had been kept correctly
The actual removal went smoothly precisely because nothing about the pilot phase had cut corners: the pilot's graph lived in its own disposable namespace the whole time, confirmed empty of any real production writes before being dropped. The extension's own internal catalog held only its own bookkeeping objects, no application data. A setting that was supposed to have been changed as part of the original install turned out never to have actually been applied — meaning the removal didn't even require restarting the database, a materially lower-risk operation than anyone had assumed going in when the removal was first planned.
What "prove it, then remove it" actually looks like
The two-week gap between installing something and deciding it wasn't needed isn't a story about wasted effort. The pilot answered a real question — does this actually work correctly against our real data — that had to be answered before any decision about keeping it could be trusted either way. Keeping something installed on a plausible-sounding future need, and then actually checking two weeks later whether that need ever showed up, is a genuinely different discipline than either ripping something out reflexively the moment it's not immediately useful, or leaving it in indefinitely because removing it feels like admitting the initial idea didn't pan out. Both the installation and the removal here were the correct call, made for real, checked reasons, at two different points where different information was available.