The question is usually posed as an engineering comparison and answered as one, which is why the answers are unsatisfying. The engines are all good. Postgres, Oracle, SQL Server, Db2, MySQL and MariaDB all implement ACID transactions, cost-based optimisation, MVCC or an equivalent, write-ahead logging, replication and point-in-time recovery. None of them will lose your data because of a defect in the storage engine.
So the licence fee is not buying correctness. It is buying a bundle of other things, and whether that bundle is worth the money depends entirely on which parts of it you would otherwise have to provide yourself.
What the money actually buys
A contract with a response time. At three in the morning, with a corrupt index and a business that cannot take orders, the difference between a vendor obliged to answer within an hour and a mailing list is not a technical difference. It is the whole product. Escalation to engineers who can read the source, on a clock, is genuinely difficult to replicate — and it is available for open-source engines too, from independent support companies, which matters for the comparison later.
Certification and indemnity. Large procurement processes and regulated industries frequently require a named vendor who accepts liability. Separately, a great deal of third-party enterprise software — ERP, clinical systems, industrial and laboratory packages — is certified against specific database versions and only those. Running it on anything else does not merely lose you the database vendor's support; it voids the application vendor's. This is the single most common legitimate reason organisations run a commercial database, and it has nothing to do with the database's merits.
Tooling and the people who know it. Mature management consoles, query analysers, migration assistants, integrated backup products, and a very large pool of administrators who have been trained on them. The training material, certifications and career path around the big commercial engines are an asset, and the value of "we can hire someone who already knows this" is real even though it never appears in a comparison table.
Specific engineered capabilities. There are genuine differentiators. Shared-storage active-active clustering, where several nodes run against one copy of the data, is a distinctive architecture with no straightforward open-source equivalent. Deep integration with a vendor's own stack — reporting, ETL, analysis services, identity, the surrounding cloud — is real value if you already live in that stack. Mainframe integration is a category of its own. Long-established parallel query, partitioning and workload management have had a very long time to mature.
What Postgres does for nothing
The other side of the ledger has moved a long way, and the comparison many organisations carry in their heads is a decade out of date. Without paying anyone, Postgres gives you MVCC, write-ahead logging with point-in-time recovery, streaming and logical replication, declarative partitioning, parallel query execution, a sophisticated cost-based planner, window functions and recursive CTEs, JSON with indexable containment queries, foreign data wrappers to other systems, and multiple procedural languages.
Then there is the extension ecosystem, which is the part with no commercial equivalent at all. Spatial support is best-in-class and open. Time-series, columnar storage, vector similarity search, sharding and connection pooling all arrive as extensions rather than as separately-licensed product editions.
And the support asymmetry is smaller than it looks. Several independent companies sell production Postgres support with contractual response times, and because none of them owns the engine, you can change supplier without changing database. With a proprietary engine, support and engine are the same purchase — which is precisely the leverage the vendor is selling.
When the commercial option genuinely wins
Not often, but not never, and the honest cases are specific:
- Your third-party application is certified only against it. Not negotiable, and not an engineering decision.
- Procurement or regulation requires vendor indemnity. Also not an engineering decision.
- You need a capability with no open equivalent for your workload — shared-storage clustering, mainframe integration, or a specific analytical feature that would otherwise mean introducing a second system.
- You already have deep in-house expertise. A team of experienced administrators for one engine is worth more than the licence differential for a long time. Retraining is a real cost that comparisons habitually price at zero.
- The estate is large, old and works. Migrating a thousand stored procedures with vendor-specific syntax, three ETL pipelines and a reporting layer is a multi-year programme with no user-visible benefit. Choosing not to do it is a legitimate answer, not an admission of anything.
Note what is missing from that list: performance, reliability and scale for ordinary transactional workloads. For a typical application under a few terabytes, engine choice is not the thing standing between you and adequate performance.
The costs that do not appear on the quote
Both sides have them.
Commercial licensing is generally per-core or per-socket, which means a hardware upgrade is a licensing event, and virtualised or cloud deployment brings its own counting rules that can differ sharply from on-premises ones. Capabilities are frequently gated by edition, so the feature that justified the purchase may be an additional line item rather than part of the base. And licence audits are a recurring administrative and financial exposure that organisations consistently fail to budget for.
Open source has the mirror image. You are operating it, which means backups you have actually tested restoring, upgrade planning, replication monitoring, capacity work and someone on call who understands vacuum behaviour. Buying managed hosting removes most of that and replaces it with a monthly bill that is a real number, not a rounding error — and at large scale, managed database hosting can exceed what a licence would have cost.
The comparison people should make is total cost including staffing, not licence against zero.
The uncomfortable part: it is usually the schema
Most teams asking "should we buy a better database" have a query problem, and a query problem does not improve when you buy a licence. In rough order of how often it turns out to be the answer:
| Symptom | Actual cause |
|---|---|
| Queries slow as data grows | Missing or wrongly-ordered indexes |
| Hundreds of tiny queries per request | N+1 access pattern from an ORM |
| Connection errors under load | No pooling, or a pool sized without reference to the server's limit |
| Memory blowouts and timeouts | Unbounded result sets, no pagination |
| Random lock waits and deadlocks | Long transactions, or the wrong isolation level |
| Everything slow at once | Reads and writes on one node with no read replicas |
| Nothing can be queried efficiently | A data model that stores attributes as rows |
Every row in that table is engine-independent. A missing composite index is missing on every database in the world, and an index whose column order does not match the query will be ignored by every planner ever written. An N+1 pattern issuing four hundred round trips per page is slow because of the round trips, and a faster engine makes each of them slightly less slow.
There is a simple diagnostic. Before evaluating engines, take the ten slowest queries in production, run each with the planner's explain-and-analyse output on realistic data, and see how many are doing something structurally wrong. If the answer is most of them — and it usually is — the engine is not the constraint and switching to a different one will teach you that at considerable expense.
How to actually decide
Work through it in this order:
- Is the choice already made for you by a certification requirement, a procurement rule or a regulator? If yes, stop; this is not an engineering decision and treating it as one wastes everybody's time.
- Do you need a specific capability that only one engine provides for your workload? Name it precisely. "Better performance" is not a capability.
- What is your operational appetite? If nobody will own database operations, budget for managed hosting or a support contract regardless of which engine you choose. An unsupported database that nobody administers is the genuinely expensive option, and the bill arrives all at once.
- What can you hire for? In most markets that now favours the open-source engines, which is a reversal of the position twenty years ago and one of the more consequential changes in this comparison.
- Only then compare engines — on your workload, on production-shaped data, with the queries you actually run.
For a greenfield transactional application the default is Postgres, and the burden of proof sits with anyone proposing otherwise. For an existing estate the default is to leave it where it is and fix the queries. Neither of those is an exciting conclusion, which is probably why the question keeps getting asked in the hope of a different one.