How would you evaluate a new database for a critical workload, and what would make you reject it despite good benchmarks?

What is being tested

Whether your evaluation criteria are dominated by operability rather than by performance.

What would make you reject it despite good benchmarks

1. Nobody can operate it. No expertise in the team, no availability in the market, and a small community. An excellent database nobody can debug at 3am is a bad choice, and this criterion is under-weighted more than any other.

2. Poor failure behaviour. Benchmarks measure the happy path. What happens when a node fails, when disk fills, during a version upgrade, when a network partition occurs? A system with excellent throughput and a manual, undocumented recovery procedure is disqualified.

3. Weak operational tooling. No good backup and restore story, no online schema changes, poor observability, upgrades requiring downtime. This is where you will actually live, and it is documented last in every product.

4. Immature or uncertain governance. A single maintainer, a vendor whose future is unclear, a licence that has changed once and may change again.

5. Unacceptable exit cost for a decision this irreversible. A primary data store holding years of production data is a one-way door in any practical sense.

6. It does not fit the access pattern. Good benchmarks on someone else's workload say nothing about yours.

How to evaluate properly

• Prototype against your actual workload, with realistic data volumes and realistic skew. Vendor benchmarks describe the vendor's workload, and uniform synthetic data avoids the hot-key problems that break production.
• Test failure modes deliberately: kill a node under load, fill a disk, run an upgrade, partition the network. This finds more than any throughput number.
• Read the operational documentation before the feature list. Upgrades, backup, monitoring, troubleshooting.
• Talk to someone operating it at your scale. Worth more than all the documentation, and usually obtainable.
• Model the cost at projected scale, including licensing and the run effort.

The prior toward boring technology

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. 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.

What a strong answer adds

Asking whether the incumbent genuinely cannot serve the 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 the evaluation frequently ends there, having saved a permanent operational cost.