Engineering · 2026-04-24 · By RedDB team · 9 min read
Why 'best of breed' loses at small scale
The ops cost of running four engines instead of one, measured in person-hours at team sizes of 2, 5, and 15 engineers. Multi-model isn't only a scale concern — it's a small-team unlock.
The “best of breed per workload” line has a comforting shape: pick the perfect tool for each job, glue them together, ship faster than the team that picked one general-purpose engine. It reads as engineering maturity. In practice, at the team sizes where most products live — between two and fifteen engineers — it is a tax that almost nobody finishes paying.
This post tries to put a number on that tax. Not “it feels slower” but person-hours per quarter, per engine, per team size. The numbers below are not from a benchmark; they are the rolling average of what we and our design partners have observed across teams running between two and seven storage engines in production.
The stack we are measuring
The “best of breed” reference stack:
- Postgres for relational rows
- Elasticsearch (or OpenSearch) for full-text search
- A vector store (Pinecone, Weaviate, or pgvector-on-a-second-cluster) for RAG
- Redis for sessions, rate limits, and a queue
Four engines. Each is, in isolation, a strong choice. The question this post is asking: what does the seam between them cost, and how does that cost scale with team size?
The single-engine alternative: one multi-model store (RedDB, or for the sake of argument any system that handles the four shapes under one transaction and one operator surface).
The hidden line items
Before the table, the hidden costs people forget when they sketch the “best of breed” decision:
- Training. Each engine has its own query language, failure modes, tuning knobs, backup procedure. A new hire is not productive on the stack until they can debug all of them. With one engine, “productive on the database” is one onboarding milestone; with four, it is four.
- On-call rotation per system. If you take on-call seriously, every engine in production has runbooks, alerts, and a person who knows it well enough to wake up at 3am. With four engines, either four people each own one (and the bus factor is one across the stack) or every on-call person owns four (and the runbook reading list is long).
- IAM sprawl. Every engine has its own auth model, its own service accounts, its own audit log to wire into the SIEM. Four times the IAM surface is four times the place a misconfigured policy hides.
- Cross-engine consistency code. This is the line item nobody budgets for. When the source-of-truth row in Postgres updates and the search index in Elastic and the embedding in the vector store have to follow, somebody writes — and maintains, forever — the outbox, the queue, the retry policy, the dead-letter handler, the reconciliation job. Per pair of engines. With four engines and three data flows between them, that is three independent pieces of glue, each with its own failure mode.
- Backup correlation. A backup of Postgres taken at 02:00, an Elastic snapshot taken at 02:15, and a Pinecone export from yesterday are not a coherent point-in-time view of your system. Restoring is a science project. With one engine, the backup is the backup.
- Local dev parity. Each engine needs to run on the developer’s laptop or be mocked. With four, the docker-compose file becomes a load-bearing artifact and “it works locally” stops being a useful signal.
None of these costs show up in the per-engine pricing page. All of them show up in the team’s calendar.
The ops cost table
Person-hours per quarter, by engine, by team size. “Engine” here means one production storage system the team owns end-to-end. “Glue” is the cross-engine consistency code and reconciliation work.
| Activity | Per engine, 2-person team | Per engine, 5-person team | Per engine, 15-person team |
|---|---|---|---|
| Patching + version upgrades | 8 h | 12 h | 20 h |
| Backup verification + restore drill | 6 h | 10 h | 16 h |
| Capacity planning + cost review | 4 h | 8 h | 14 h |
| Runbook maintenance + on-call training | 4 h | 10 h | 22 h |
| Incident response (avg, amortized) | 12 h | 18 h | 28 h |
| Schema/index/config change reviews | 6 h | 14 h | 30 h |
| Per-engine subtotal | 40 h | 72 h | 130 h |
And the cross-engine line items:
| Activity | 2-person | 5-person | 15-person |
|---|---|---|---|
| Glue maintenance (per pair of engines) | 8 h | 14 h | 22 h |
| Cross-engine incidents | 10 h | 16 h | 30 h |
| Schema drift reconciliation | 6 h | 12 h | 20 h |
Running the math
Best-of-breed stack: four engines, three glue pairs.
| Team size | Per-engine cost (×4) | Glue cost | Total q/quarter | % of team capacity |
|---|---|---|---|---|
| 2 | 160 h | 72 h | 232 h | ~48 % of one engineer |
| 5 | 288 h | 126 h | 414 h | ~34 % of one engineer |
| 15 | 520 h | 216 h | 736 h | ~20 % of one engineer |
Single-engine stack: one engine, no glue.
| Team size | Per-engine cost | Glue cost | Total q/quarter | % of team capacity |
|---|---|---|---|---|
| 2 | 40 h | 0 h | 40 h | ~8 % of one engineer |
| 5 | 72 h | 0 h | 72 h | ~6 % of one engineer |
| 15 | 130 h | 0 h | 130 h | ~3.5 % of one engineer |
Assumes one engineer-quarter = ~480 productive hours (60 working days × 8 h, lightly discounted for meetings and PRs).
What the table says, in English
At two engineers, the best-of-breed tax is roughly half of one engineer, every quarter, forever. That is a co-founder. Half of one of two people is doing nothing but keeping the seams between engines from tearing. If those two people were trying to find product-market fit, they have just lost a quarter of the company’s total capacity to glue.
At five engineers, it is closer to a third of a person — but a five-person team that gives up a third of a person to undifferentiated ops is one that is not shipping the thing customers are asking for. The team feels it as “we are always firefighting.” That is what the table is measuring.
At fifteen engineers, the percentage drops to a fifth of a person — but the absolute number is 736 hours per quarter, the equivalent of more than four engineer-months annually. At fifteen people, that often pays for the dedicated platform team that the team needed in order to run the stack. The cost has not gone away; it has been institutionalized.
The single-engine column, by contrast, scales sub-linearly. There is no glue, so adding engines to the stack does not add the worst line item. The increase from a two-person to a fifteen-person team is roughly 3× — and most of that is “more engineers means more change reviews,” not more ops surface.
“But we’re not paying that cost”
Three common objections, with what we have seen in practice.
“Our cloud-managed services handle ops.” Partly. Managed Postgres, managed Elastic, managed Redis, managed vector store — each one removes the patching line item and some of the capacity planning. It does not remove the runbooks, the IAM sprawl, the cross-engine glue, the backup correlation, the on-call surface, or the dev-parity problem. Maybe halve the per-engine row. The glue row does not budge, because that is your code, not the provider’s.
“We have one person who owns each engine.” This is the bus-factor-one reframing of the cost, not its elimination. The work is the same; it has been concentrated on individuals whose departure will be load-bearing. It also concentrates expertise where it cannot be reviewed, which is its own incident waiting to happen.
“We do not have all four engines yet.” Then the calculation is the one you should be doing now, before adding the third. The pattern we have seen is that engines are added one at a time, each addition is locally justified (“we just need full-text search”), and the team realizes only at engine four that the integration tax has compounded. Each additional engine adds another glue pair, not a constant.
Where the framing breaks
This is not a universal claim. There are real reasons to run a best-of-breed stack:
- The single-engine option is genuinely worse at one of your shapes. If you need true OLAP — billion-row scans, columnar compression — a multi-model engine is not the right tool. ClickHouse exists for a reason.
- You have a regulatory requirement that names a specific engine. Use the named engine; the auditor’s report is not the place to be clever.
- One of the shapes is so high-volume that it dominates the cost. If 95 % of your read traffic is Redis-shaped (millions of cache hits per second), running Redis separately and keeping it tuned is genuinely cheaper than putting that load on a general-purpose engine.
These are real cases. They are also the cases where, at any team size, the math works out. Most teams do not have them. Most teams have four engines because each was added under local pressure, not because the stack was designed.
Multi-model as a small-team unlock
The framing this piece is most arguing against: “multi-model is for scale.” The table says the opposite. The team that benefits most from one engine instead of four is the two-person team, because the absolute ops cost is the same fraction of a much smaller capacity. A 200-engineer company can run seven engines and not feel it. Two co-founders cannot.
This reframes when to consider multi-model. Not when you grow into it; before you grow. The choice to run one engine instead of four is one of the highest-leverage decisions a small team makes, and almost nobody frames it that way at the moment of decision, because each engine looks free in isolation.
We are not the only multi-model option. Postgres, with its growing extension ecosystem, covers more shapes every year and is a reasonable single-engine answer for many teams — we said as much in When you don’t need RedDB. The point of this post is not “pick RedDB.” It is “pick one engine, whichever one matches your shapes.”
TL;DR
- Person-hours per quarter on the ops/glue surface of a four-engine stack: ~232 h at 2 people, ~414 h at 5, ~736 h at 15.
- Same calculation for a one-engine stack: ~40 h, ~72 h, ~130 h.
- The percentage cost is highest at the smallest team — multi-model is a small-team unlock, not a scale concern.
- Managed services reduce the per-engine row, not the glue row. The glue is your code.
- Where best-of-breed wins: true OLAP, named regulatory requirements, one workload dominates the cost. Most teams do not have these.
Related: When you don’t need RedDB, Multi-model storage: the actual tradeoffs, RAG without a second database.