What does running multiple
databases actually cost you?

Each tool: infrastructure cost = $/ops-sec/yr × ops/sec, summed across selections. Team & integration overhead is computed once per stack, not per tool — see below — then added to get each side’s total. The savings estimate comes from the gap between the stack’s overhead and Couchbase’s, never a discount off any competitor’s price.

Some vendors charge per operation, some rent a server by the hour, some publish their own benchmark. We price each by however that vendor actually sells — never whichever framing looks smaller. For hourly-rented servers: price ÷ assumed sustained throughput. That throughput assumption (typically ~800 sustained ops/sec per vCPU or core) is ours, not the vendor’s, and disclosed in every tooltip that uses it. It’s a rate, not a workload cap: it’s used once to compute a $/ops-sec/yr price, which is then multiplied by whatever traffic level you enter — changing your traffic doesn’t change the underlying rate. The model assumes that rate scales linearly with however many instances it takes to hit your traffic level, with no penalty or bonus for running more of them.

Team & integration overhead = [0.35 × (tools selected)0.7 + 0.25 × ((tools selected)1.5 − 1)] × (your traffic ÷ 5,000)0.2 × engineer cost. Couchbase’s overhead uses the same formula simplified to 0.35 × (your traffic ÷ 5,000)0.2 × engineer cost — always treated as a single platform, no matter how many tools you’ve selected. Engineer cost defaults to $165,000/year (fully loaded) and is editable in Step 3; it applies identically to both sides of the comparison. One more database doesn’t need a whole extra admin — teams share tooling across systems they already run — so the admin portion grows slower than 1-for-1 as you add tools.

adjusted cost = base $/ops-sec/yr × (1 + support % ÷ 100). Premium support is priced differently across vendors. MongoDB, Redis, and Pinecone sell support separately, and none of the three publish a clean percentage — Step 3 lets you enter your own if you have a quote, defaulted to 0%. Elasticsearch publishes its support-tier percentage directly (Gold +5%, Platinum +10%, Enterprise +15%), so that’s applied by default. Oracle and SQL Server are a different case again: their support fee is technically optional, but standard practice for production use — declining it means giving up patches, updates, and support indefinitely, which is why real deployments overwhelmingly renew it every year. That fee (22%/year, ~25%/year respectively) is already folded into their base figures rather than modeled as a separate toggle. Couchbase Capella’s own price bundles support the same way, with no separate charge to add. MongoDB’s two rows share one support field, since both run on the same Atlas account and would only be billed once in reality. A similar adjustment isn’t offered for databases delivered through a hyperscale cloud platform — Amazon DynamoDB, Google Firestore, Amazon RDS for PostgreSQL, Amazon ElastiCache for Memcached, and Google AlloyDB. Support for these services is typically sold at the account level, spans dozens of unrelated products, and is shaped by enterprise discount agreements that vary widely by customer. Isolating one database’s share of that arrangement would require assumptions too speculative to stand behind, so those rows reflect infrastructure pricing only.

Vector search costs swing widely based on recall (search accuracy). AlloyDB benchmarks at 80% recall. MongoDB only publishes a ~98% tier for scalar quantization benchmark, while Pinecone doesn’t publish their recall at all. To keep this honest, we compare these tools against Couchbase’s vector-specific rate ($14/ops-sec/yr), benchmarked at an identical 80% recall. This makes the AlloyDB comparison a true head-to-head. We can’t perfectly align MongoDB or Pinecone until they publish 80% recall data, but using our verified rate keeps the baseline grounded in reality.

annual savings = annual model spend × addressable share × cache hit rate, shown as a range. Reported as its own line, deliberately, since inference costs vary.