Your platform group standardised on one relational database six years ago. It works - 40 services and one on-call rotation that knows it deeply. A team now needs hybrid keyword-and-vector retrieval and proposes a second store. The standard says no. What did the standard buy and what is the bill that just arrived?

What was gained, quantified

Operating attention is the scarce resource and standardisation concentrates it. A stateful system holding production data carries a standing duty list: version upgrades, backup verification, restore rehearsal, capacity headroom, failure runbooks, and a retention policy. Budget roughly 0.3 to 0.5 of an engineer's continuing attention per stateful system once it is load-bearing.

With one store and 40 services, that bill is paid once. The rotation has seen this database's failure modes enough times to recognise them in minutes, which is worth more than any runbook. Six years of one store is six years of compounding diagnostic speed - the genuine and frequently undervalued return.

What was paid, and when the bill arrives

Two things, and only one of them is obvious.

The obvious cost is option value. The group can no longer take a cheap bet on a technology, because every bet is a permanent second system.

The cost that actually hurts is the evaluation muscle. Ask the measurable question: how long did the last three technology evaluations take, and how many candidates did each consider? A healthy standard produces fewer evaluations, not slower ones. If the group has not run one in three years, nobody currently employed has done the work of choosing, and the first new workload class arrives with the decision defaulting to whichever of two bad paths is louder: bolt it onto the standard, or adopt whatever a team already prototyped at home.

The bill arrived now because the request is a different workload class, not a bigger version of the same one. Approximate nearest-neighbour search over embeddings is not row-oriented transactional access. The standard has nothing to say about it, and that is the signal.

The decision rule

Scope a standard to a workload class, not to a technology count. Same class - transactional rows, reporting aggregates, a work queue - and the standard holds, and holds hard. Different class, and extending the standard is the expensive mistake: a store doing approximate search badly costs the same standing operating attention as a purpose-built one, plus worse results, plus a fight about whether the results are the store's fault.

It flips the other way below roughly 15 services, or with an on-call rotation of fewer than six people, where a second system genuinely cannot be carried and the right answer is to accept worse retrieval quality and say so out loud.

How to keep the option to reverse

Repay the judgement debt on a schedule rather than under pressure: two engineers, two weeks, three candidates, and a written falsifier for the one you pick - the measurement that would say you were wrong. Run it before a team needs the answer, not during their quarter. Two engineer-weeks a year is under 2% of a 40-service platform group's capacity and it is the cheapest insurance against a decision being made by default.

When this is the wrong answer

When the requirement is latency or scale on the same workload class. "The database is slow" almost never justifies a second technology, and the standard is doing its job by refusing. Query plans, indexes and schema changes resolve the large majority of those requests, and a team that reaches for a new store to avoid reading an execution plan is asking the standard to absorb a skills gap.