Oracle Database Vault licensing in 2026. What it costs and where it is switched on.

Database Vault is a separately licensed Enterprise Edition option with a one line rule. What you pay depends on where it is enabled, who your DBAs work for, and what your feature usage history already records.

How is Oracle Database Vault licensed, and what does it cost?

Database Vault is a separately licensed option on Oracle Database Enterprise Edition. It lists at $11,500 per processor or $230 per Named User Plus, plus 22 percent annual support, and it sits on top of Enterprise Edition at $47,500 per processor. Enterprise Edition does not include it, and Standard Edition 2 cannot run it at all.

The licensing rule itself fits on one line. You license the option on the same processors or named users as the Enterprise Edition database underneath it. The database's own counting rules apply, core factor and minimums included, as our database licensing guide explains.

Which counting rules does the option follow?

Oracle's licensing manual says the Database Vault metric must match the Enterprise Edition metric. A processor licensed database needs Vault on the same cores, at the same 0.5 core factor for Intel and AMD servers. A Named User Plus database needs Vault for the same users, with the minimum of 25 per processor applying to both.

On small user populations that minimum usually sets the price. A database on an 8 processor server needs at least 200 Named User Plus, so Vault costs 200 x $230, or $46,000, plus $10,120 a year in support. The same server on the processor metric costs $92,000 for the option.

Where is Database Vault included at no extra cost?

Oracle's licensing manual lists Database Vault as included in Personal Edition and in Exadata Database Service. Oracle Base Database Service includes it at the Enterprise Edition High Performance and Extreme Performance tiers. If a regulated workload is moving to one of those services anyway, the on premises Vault licenses it replaces become candidates for reduction.

What does Database Vault do that encryption and auditing cannot?

Database Vault stops a fully privileged DBA, including one connected as SYSDBA, from reading application data. No other Oracle control does that. Transparent Data Encryption does not, because it decrypts for anyone with query privileges and the DBA usually manages the keystore. Auditing does not either, because the DBA can manage the trail that records the access.

Oracle's manual lists four features inside the option, and between them they provide the separation of duties that regulators eventually ask about.

• Realms. Protected zones around application schemas that system privileges cannot reach.
• Command rules. Conditions on SQL statements, for example blocking DROP TABLE outside a change window.
• Separation of duties. Distinct roles for account management, Vault administration and database administration.
• Trusted paths. Access allowed only from named hosts, programs or times.

The same manual grants Vault licensees special license rights for Oracle Label Security, itself a separate extra cost option. Read the scope of those rights in the manual's Special License Rights section before you assume a Vault license covers Label Security policies you create.

The control is worth paying for where it answers a real requirement. A common case is outsourced or offshore DBA support, where the regulated data must stay out of reach of the people running the database. Who your DBAs work for is often the question that decides whether you need Vault.

Does privilege analysis still require Database Vault?

No. Privilege analysis stopped requiring Database Vault around the Oracle Database 18c release and is now an Enterprise Edition feature. Oracle's current licensing manuals for 12.2, 18c and 19c all list it under Enterprise Edition, with no reference to the Vault option.

Yet buyers still get quoted the option for it, and any Vault line justified by privilege analysis alone is a quote to correct. A past purchase made only for privilege analysis is a candidate for reduction at the next renewal. Model Oracle's repricing rules for dropping support on part of a license set first.

Which databases should carry a Database Vault license?

License Vault on the databases that fall under a named regulatory requirement and hold the data that requirement names. Elsewhere the option buys control that no rule asked for. A scoped design is also your audit defense, because an entitlement that matches a documented scope is easy to explain.

The extra spend comes from enabling Vault on every database by default. Our engagement findings below put a range on that premium, and the multitenant rule makes it easy to incur by accident.

How does multitenant change the scope?

The licensing manual is specific here. A license is required when Database Vault is enabled in the CDB root, whether or not any PDBs are plugged in, and it applies to the entire CDB. You cannot license individual PDBs.

So the practical unit of scope is the container database and the hardware it runs on. Put regulated PDBs in their own CDB, on hosts sized for them, and keep unregulated PDBs elsewhere. Consolidating everything into one large CDB and then enabling Vault for a single regulated PDB licenses the whole server.

Should you switch Vault on everywhere for consistency?

Security teams often want one standard configuration on every database, Vault included, because exceptions are harder to manage. We disagree when the regulation covers only some systems.

Realms still need design per application, so the operational gain is small, while the license follows every processor where Vault is enabled. Standardize the build scripts instead, so any database can be enabled quickly once it enters scope.

What does inheritance add to the bill?

Say you plan Vault for one regulated production database on a two socket Intel server with 8 cores per socket, which counts as 8 processors at the 0.5 core factor. It has a physical standby on identical hardware and a test copy refreshed monthly onto an 8 core host. At list price, the plan and the reality compare as follows.

The standby usually belongs in scope, since it holds the same regulated data and carries production's options. The test clone rarely needs the control, so add a step that disables Vault on it after each refresh.

Masking the copied data removes the regulatory reason to keep Vault there, but the license follows enablement, so the disable step still matters. Masking is the job of the data masking and subsetting pack, itself a separately licensed pack.

How do you check where Database Vault is enabled and used?

Query three views on every database, and read them in the right order. Each answers a different question, and the feature usage history is the one an Oracle measurement prices. The installed component also appears in DBA_REGISTRY, but installation alone creates no license obligation.

DBA_DV_STATUS returns two rows that matter: DV_CONFIGURE_STATUS and DV_ENABLE_STATUS. The licensing manual ties the license to enablement, so a database that is configured but not enabled needs no license. Enabled now is remediable, used ever is negotiable, and installed only is harmless.

Run the pass quarterly across every database, the same discipline our license position guide applies to every option. For how Oracle reads the collected output, see the script output interpretation guide. The quarterly pass turns evaluation residue into dated cleanup items before any script arrives.

Why is Vault enabled on databases you never licensed?

Because the Vault configuration lives in the data dictionary and travels with the database. Every clone, refresh and standby built from a configured source inherits the enablement, and the license obligation with it, without anyone deciding anything.

We have reviewed companies that believed they ran Vault on 6 databases and found it on 20. Their tooling had made the decision for them. That is why a DBA_DV_STATUS check belongs inside every clone and standby workflow, as a step in the runbook, and not only in the annual review.

What should you do about an old evaluation record?

Treat it as history to document. Where Vault is still enabled with no license, the Vault owner account runs DBMS_MACADM.DISABLE_DV and the database is restarted. Record the date, who approved it and why Vault was enabled in the first place, then keep the evidence with your license records.

The usage record stays in DBA_FEATURE_USAGE_STATISTICS after you disable the option, and that is expected. A dated cleanup with a stated evaluation purpose is far easier to explain than an unexplained history when the script output lands.

What have we seen in recent Database Vault negotiations?

Across roughly 25 to 35 Oracle engagements between 2024 and 2026 that touched Database Vault and the other security options, I found the same three patterns of exposure. None of them started with a decision to deploy.

The neighboring security options and the management packs follow the same rule. They reward deliberate scope with documented reasons, and they penalize whatever the build scripts switched on by default.

An entitlement that matches a documented scope is a position you can explain. Enablement that matches nothing is an audit finding.

What will Oracle's account team say, and how should you answer?

• "You need Vault for privilege analysis." Point to the licensing manual, which lists privilege analysis under Enterprise Edition, and ask for the line to be removed.
• "Configured means licensed." The manual requires a license when Vault is enabled, not when it is installed or configured. Show DV_ENABLE_STATUS for each database.
• "Feature usage shows Vault, so every one of those databases is out of compliance." Separate current enablement from historical use, and present the dated disable records for the evaluations.
• "Licensing all processors is simpler and earns a bigger discount." Ask for both prices in writing, scoped and full, and compare the net totals.

Which contract terms should you ask for?

1. A unit price hold for additional Vault processors or users. Regulated scope tends to grow, and a held price stops expansion being quoted at list.
2. Written evaluation terms before any trial. Name the databases and the dates, so a later usage record has a contract behind it.
3. A cap on annual support increases. Support is a fixed share of the net license fee, and yearly increases on it compound for as long as you keep the option.
4. Confirmation of the metric match. The order should show Vault on the same metric and count as the Enterprise Edition licenses it sits on, so a later audit cannot argue a mismatch.

What to do next

1. This quarter. Query V$OPTION, DBA_DV_STATUS and DBA_FEATURE_USAGE_STATISTICS on every database, and record installed, enabled and used status per database.
2. In every clone and standby runbook. Add a DBA_DV_STATUS check after each build or refresh, because the configuration inherits.
3. Before the next order. Scope the entitlement to the regulated databases, in their own CDB where you run multitenant, and document the regulation behind each one.
4. On every quote. Strike any Vault line priced for privilege analysis, which has been an Enterprise Edition feature since 18c.
5. For evaluation residue. Disable deliberately, document the date and purpose, and keep the record with your license files.
6. Before renewal or audit. Ask our Oracle practice or the audit defense team to review the options position with you.

Frequently asked questions