A team wants to add a graph database for a "people you may know" feature. The system currently runs on one PostgreSQL instance. Evaluate.

What is being tested

Whether you can price the fixed operational cost of an additional datastore against a benefit that may be obtainable without it.

First, what does the feature actually need?

"People you may know" is typically two-hop traversal with ranking: friends of friends, scored by mutual connections, filtered by what is already connected. That is not deep traversal. Two hops in a relational database is a self-join, and with a well-indexed edge table it is entirely tractable at moderate scale.

The question to ask is: how many hops, how many users, and what latency? A recursive six-hop query over hundreds of millions of edges is a genuine graph problem. Two hops over ten million edges is a query optimisation problem.

The cost of an additional store

Each store carries a fixed operational burden that does not shrink with usage:

• Backup and, more importantly, tested restore.
• Upgrade and patching cycles.
• Monitoring, alerting, capacity planning.
• On-call expertise — someone must know why this engine is behaving oddly at 3am.
• Security review, access control, audit.
• No transactions across stores. Consistency between the relational store and the graph becomes application code, and the two will diverge. Something must detect and repair that, permanently.

That burden is roughly fixed while the benefit scales with workload size, which is why the same decision that is correct at Netflix's scale — where viewing history, recommendations, telemetry and configuration genuinely have different access patterns, volumes and consistency requirements — is frequently wrong for a company with ten engineers.

What to propose instead

1. Try it in PostgreSQL first. An edge table with indexes in both directions and a recursive CTE or a two-step join. Measure it. If it meets the latency requirement, the discussion is over and you have saved a permanent cost.

2. If it is too slow, ask why. Often the fix is precomputation rather than a different engine: "people you may know" does not need to be computed synchronously. A nightly or hourly batch job producing a suggestions table gives sub-millisecond reads from the existing database, and the suggestions being a few hours stale is undetectable to users.

3. If real graph workloads accumulate, then adopt a graph store — with the reasoning recorded and a clear statement of what it owns and what it does not.

The framing for the conversation

Not "no". Ask: what specifically cannot be served by what we have, and what have we measured? Then price the alternative honestly, including the on-call burden and the reconciliation code, so the decision is made on total cost rather than on query elegance.

The general default

One relational database until a specific workload demonstrably cannot be served by it, then exactly one additional store for that workload. Modern relational engines cover JSON, full-text, geospatial and queue-like workloads adequately at moderate scale, which pushes the threshold much further out than most teams assume — and every store not adopted is capacity retained for the scaling problem that does eventually arrive.