Technology Selection
Choosing a technology on the basis of fit, operability and organisational capacity — with a strong prior toward what you already run well.
Definition
Selecting a technology is choosing a long-term operational commitment. The evaluation criteria that matter are frequently not the technical ones.
The criteria, in the order they usually decide
1. Does it fit the workload? Access patterns, consistency requirements, scale, query shapes. A technology that does not fit will be fought forever.
2. Can we operate it? Existing expertise, on-call capability, availability of people who know it. An excellent technology nobody can debug at 3am is a bad choice. This criterion is under-weighted more than any other.
3. What is the total cost over three to five years? Including licences, infrastructure, and — the dominant term — the engineering time to run it.
4. What is the exit cost? A technology that is expensive to leave has to be right, and the evaluation deserves proportionate rigour.
5. Is it a two-way door? A reversible choice can be made quickly and revised. A data store holding years of production data is not reversible in any practical sense.
6. Is it maintained, and by whom? A single-maintainer project or a vendor with an uncertain future is a risk regardless of quality.
The prior toward boring technology
There is a strong argument for preferring what you already run. Each new technology consumes a share of the organisation's finite capacity for operational novelty — the number of things a team can genuinely be good at is small, and spending that budget on a database engine means not spending it on something that differentiates the product.
Boring technology is frequently the more scalable organisational choice, because failure modes are known, expertise exists, and problems have been encountered by others before you.
That argument can be overdone, and the correct response is to make novelty deliberate rather than forbidden: adopt something new when it addresses a real constraint, adopt one thing at a time, and be explicit that you are spending capacity.
How to evaluate well
- Prototype against your actual workload, with realistic data volumes. Vendor benchmarks describe their workload.
- Test the failure modes, not the happy path. How does it behave when a node fails, when disk fills, during an upgrade?
- Talk to someone operating it at your scale, which is worth more than any documentation.
- Read the operational documentation before the feature list. Upgrades, backup, monitoring and troubleshooting is where you will actually live.
Failure scenarios
- Selected on features, operated on regret.
- Prototyped on toy data, so scale behaviour is unknown.
- Adopted because one engineer was enthusiastic, who then leaves.
- Several novel technologies at once, so a problem cannot be attributed and the team is overwhelmed.
- Exit cost never considered, so a renewal or a licence change becomes a crisis.
Interview question
"How would you evaluate a new database for a critical workload, and what would make you reject it despite good benchmarks?"