Two different graph databases got evaluated for the same search engine, three weeks apart, by way of two completely independent efforts. Neither one made it into production. The second attempt's own closing writeup ends up explaining, cleanly, why the first one never had a chance either — even though nobody set out to prove that when either evaluation started.
The first attempt, built to be abandoned
Before any of the later Postgres-based graph work happened, a separate graph database was deployed as a deliberately bounded, cheap-to-abandon prototype on its own dedicated box — fed by a one-off, bounded export of the link data rather than any live connection to the real system, with explicit tear-down criteria written into the plan before a single query against real data was ever run. That's a real, disciplined way to evaluate a technology: decide in advance what would count as "this isn't working" before spending real effort finding out. By the time it mattered, the prototype was torn down having never loaded a single real node into it at all.
The second attempt, further along, still abandoned
Three weeks later, working with the corpus now living entirely in Postgres, a different graph technology — an extension that runs inside Postgres itself rather than a standalone system — got a much more thorough evaluation: a real pilot loaded against real production data, correctness verified through actual graph-query syntax, performance measured directly. This one got much further than the first attempt ever did. It also ended the same way: fully removed, roughly two weeks after being proven to work correctly.
The question that connects both outcomes
Looking back at both evaluations together, after the fact, surfaces one real, underlying reason neither one turned into anything lasting: a graph database's actual advantage over an ordinary relational database is fast, index-free traversal across many connected hops — following a chain of relationships node to node without a database join at every step. That's a real, specific capability, and it's genuinely valuable for the kinds of questions it's built for: how are these two things connected across several intermediate steps, which pages fall within a few hops of this one, which clusters of nodes form a tightly connected community.
What this particular system actually needed instead
None of that describes the actual query shapes this search engine's ranking pipeline runs. The core ranking computation is a global, iterative calculation across the whole graph at once — already solved, well before either graph-database attempt started, by a dedicated compute engine built specifically for that one job. Everything else that touches the link graph day to day — counting inbound links, gathering anchor text, checking whether a page has been discussed elsewhere — is a single-hop lookup: find everything pointing directly at one target. A single-hop lookup gets no benefit from a system optimized for chaining many hops together; ordinary relational indexing handles it just as well, and both graph-database attempts confirmed exactly that once anyone actually measured.
Why building a graph database anyway would have cost more than it looked like
Running a second, separate stateful data system alongside the one already holding the real data isn't free even when the technology itself works correctly. Either the two systems get written to at once, accepting the real risk that they drift out of agreement with each other, or one gets synced from the other on a schedule, accepting staleness and one more moving part to operate and eventually debug at 2am. Both costs are real and ongoing, independent of whether the graph technology itself performs well in isolation — and neither cost buys anything if the actual workload never needed multi-hop traversal in the first place.
The honest answer, written down before the question comes back
Rather than letting this become a debate to relitigate from scratch the next time someone reasonably suggests reaching for a graph database, the conclusion from both evaluations got written into the project's own documentation directly, in plain terms: no, a dedicated graph engine wouldn't do this workload better, here's specifically why, and if a real feature ever does need multi-hop traversal, the cheaper path is reviving the already-proven Postgres extension rather than standing up an entirely new system cold. Two independent evaluations, two different technologies, the same real answer both times — recorded once, so the next person asking the same reasonable question doesn't have to run either evaluation again to get it.