What your databases really cost

We do not sell licences. We work out which option is cheaper in the end — including the costs that appear in no quotation.

For many organisations Oracle licences are the single largest item in the IT budget, and the support fee of 22 percent of the licence value falls due every year again. At the same time it is rarely clear what exactly is being paid for: which options are genuinely needed, which were enabled by accident, and whether the edition in use actually matches the requirement.

We work through these questions one at a time — technically, not commercially. What you get at the end is a figure you can put in front of your management, and a route to it that we can also implement.

Are all the features reported as used actually needed?

Oracle records in DBA_FEATURE_USAGE_STATISTICS which options have been used in a database. The same view is read by the script used during a licence audit. In our experience it contains entries nobody in the organisation expected.

Cases we find again and again:

• A single click on the performance page in Enterprise Manager, a single query against an AWR view — and the Diagnostic Pack counts as used. The parameter control_management_pack_access can prevent this deliberately.
• One partitioned table, created by a developer years ago, activates the Partitioning option for the entire database.
• inmemory_size is set to a value greater than zero although nobody uses the In-Memory option.
• A single encrypted column pulls in Advanced Security; a single compressed table pulls in Advanced Compression.
• An SDO_GEOMETRY column inside a third-party product activates Spatial.

For every finding we answer the same three questions. Is the option needed for business reasons? If not — can it be removed cleanly, and what does that path look like? If yes — is it licensed correctly? The result is either a saving or documented certainty that the licensing is sound. Both are good outcomes.

Does a move from Enterprise to Standard Edition 2 make sense?

The price difference is considerable. Enterprise Edition is licensed per processor with the core factor applied, while Standard Edition 2 is licensed per populated socket — regardless of how many cores sit inside it. With the core counts common today, that shifts the calculation substantially.

There are limits you need to know beforehand. Standard Edition 2 runs only on servers with at most two populated sockets and restricts every instance to 16 CPU threads. Since Oracle 19c, RAC is no longer included in Standard Edition; from Release Update 19.7 its place has been taken by Standard Edition High Availability, which fails a single instance over between two nodes on shared storage — with restart times measured in minutes rather than seconds.

Also gone: Partitioning, Parallel Query, Data Guard, Advanced Compression, In-Memory, and the Diagnostic and Tuning Packs together with AWR. Statspack takes over for performance analysis, which works well in practice but takes some getting used to.

The decisive question: does one of these features carry your application, or was it simply taken along because it came with Enterprise Edition anyway? For partitioning the answer is often that it does carry the application — in which case the move is off the table. For Parallel Query and compression it is worth looking closely.

Is a migration to PostgreSQL worthwhile once migration costs are included?

This question is often calculated from one side only. The licence and support fees saved are quickly established; the effort of moving rarely is. We put both sides next to each other and name the point at which the change pays for itself.

On the effort side we look at:

• porting PL/SQL — PostgreSQL has no packages, and Oracle-specific functions have to be replaced; tools such as ora2pg take on part of the work, but manual rework remains
• the application layer, which in our experience is the larger construction site than the database itself: SQL using Oracle-specific syntax, and differing behaviour around DATE, empty strings and collation order
• test effort and parallel running during the transition
• building high availability and backup on the new platform
• training for the operations staff and a support contract where required

There are cases in which we advise against it: extensive PL/SQL logic that forms the core of the application; packaged software certified for Oracle only; workload profiles that genuinely require RAC. An honest "not worth it" is a legitimate outcome of this analysis.

Where it is worth it, we have done it: in one corporate project, replacing Oracle with PostgreSQL freed up 16 processor licences of Enterprise Edition — at a core factor of 0.5 that corresponds to 32 Intel cores no longer requiring licences or support. Further examples can be found under References.

How do I plan a resilient architecture without driving up costs?

High availability is often bought before the requirement has been established. We therefore start with two numbers: how long may an outage last, and how many minutes of data may be lost in the process? Only then can we say which architecture is necessary — and which would simply be too expensive.

The levels differ considerably in cost and in recovery time:

RMAN, backup and restore

Free of licence cost, included in every edition. Recovery in hours. Sufficient for many systems, provided the backup is also regularly restored and verified.

Standby database

Through Data Guard in Enterprise Edition, or through your own scripts or a third-party product in Standard Edition 2. Recovery in minutes, data loss close to zero.

Standard Edition High Availability

Included in Standard Edition 2 from 19.7 onwards. Fails a single instance over between two nodes on shared storage, at no additional licence cost.

Active Data Guard

Permits read access on the standby database — a chargeable additional option. Anyone who only wants resilience and does not read from the standby does not need it.

Real Application Clusters

Active-active, recovery in seconds — and the most expensive level, since the option is licensed per processor on top of Enterprise Edition.

What we see frequently: a cluster was procured years ago for resilience, not for scale. A standby solution would have met that requirement — at a fraction of the cost. Also worth noting is the failover rule in Oracle's licensing manual, under which a passive node may, within certain conditions, step in unlicensed for a limited number of days per year.

Initial analysis at a fixed price

We offer the entry point as a clearly bounded package at a fixed price. You know in advance what it costs and what you get.

What we look at

Feature and option usage per database, reconciled against your licence inventory; assessment of an edition change; a business case for replacing Oracle with PostgreSQL; and an assessment of the existing availability architecture against your actual requirements.

What you receive

A written report with findings per database, a recommendation prioritised by savings potential, and an effort estimate for each measure. Plus a meeting in which we go through the report with you.

What we need from you

Read access to the databases concerned, or the output of our scripts; your current licence and support inventory; and a short conversation about the availability requirements of the applications involved.

What happens afterwards

Nothing, if that is what you want — the report is yours and can be acted on without us. If you would like us to, we implement the measures.

For the avoidance of doubt: we are neither a licence reseller nor a legal advisor. We assess the technical usage of your databases and work through the alternatives. Negotiations with Oracle and the legal interpretation of contracts are not part of this — but we supply the factual basis on which both rest.

Get in touch: Contact