Database Vault licensing, one rule and three views
Database Vault is a separately licensed security option, not a feature of Enterprise Edition, and the licensing rule is one line. The money is decided by where you switch it on, who your DBAs work for, and what the feature usage history already says, which is why the three views get read before Oracle reads them for you.
Prepared by Redress Compliance · August 6, 2026 · Oracle advisory. Based on 25 to 35 security option engagements 2024 to 2026.
Executive summary
The rate stacks on Enterprise Edition.
Database Vault lists at $11,500 per processor or $230 per Named User Plus, plus 22 percent support, on top of EE at $47,500, and it is the only Oracle control that stops a fully privileged DBA from reading application data: encryption does not do this, and neither does auditing.
The capability is real, which is exactly why its licensing deserves the same precision.
The option is installed everywhere and enabled by hand. Every 12c and later database ships with Vault installed; configuring and enabling it is a DBA action that needs no purchase order, which is exactly why it turns up in audits.
In 4 of 5 estates, Vault was enabled on more databases than the buyer believed, usually because clones and standby copies inherited the configuration nobody remembered making.
The three views answer three different questions.
V$OPTION says available, DBA_DV_STATUS says configured and enabled, and DBA_FEATURE_USAGE_STATISTICS says used, and the usage history is what a measurement prices: evaluation enablement left a usage record in 30 to 45 percent of the estates we reviewed.
Each one a claim waiting for a script to find it.
Read all three before Oracle does.
Scope is the price, and one feature migrated out. Estate wide enablement cost the buyers we reviewed 20 to 40 percent more than a scoped design delivering the same control to the databases under a named regulation.
And privilege analysis stopped requiring Database Vault at Oracle Database 18c, it is an Enterprise Edition feature now, yet buyers still get quoted the option for it.
The rule, the rate, and what the option uniquely does
The licensing rule is genuinely one line: Database Vault is a separately licensed Enterprise Edition option, priced per processor or Named User Plus on the database's own counting rules, core factor and floors included, per the database licensing guide.
What earns the rate is the control: realms and command rules that stop even SYSDBA from reading application data, the separation of duties every regulator eventually asks about, and the answer encryption and auditing cannot give, since the DBA holds the keys to one and writes the trail of the other.
Buy it for the regulation, not the estate. The databases under a named regulatory requirement, holding the data the requirement names, are the scope that earns the option; everywhere else is 20 to 40 percent of premium for control nobody mandated.
The scoped design is also the audit defense, because an entitlement matching a documented scope is a position, and estate wide enablement matching nothing is a finding.
The three views, and the history that prices
| The view | The question it answers | The trap it reveals |
|---|---|---|
| V$OPTION | Is Vault available in this binary | Availability is universal on 12c and later; it proves nothing about liability |
| DBA_DV_STATUS | Is Vault configured and enabled here, now | The inherited enablement on clones and standbys nobody remembers |
| DBA_FEATURE_USAGE_STATISTICS | Has Vault ever been used on this database | The evaluation record from years ago that a measurement prices as use |
The reading order matters because the questions differ: enabled now is remediable, used ever is negotiable, and only available is innocent.
The quarterly pass across all three, the same discipline the license position guide runs for every option, is what converts the 30 to 45 percent evaluation residue from audit findings into cleanup items, dated and documented before any script arrives.
The script output interpretation guide covers what the measurement actually reads.
The database options and packs analysis
The full option catalog with Vault in context: the usage view semantics, the enablement traps, the scoping designs, and the remediation paths that avoid list price findings.
Get the white paper →The inheritance problem, clones, standbys, and the free feature
The 4 in 5 finding has a mechanism: Vault configuration travels with the database, so every clone, refresh, and standby built from a configured source inherits the enablement, and the license obligation, silently.
The estates that believed they had Vault on six databases and had it on twenty had made no decision at all; their tooling had made it for them, which is why the DBA_DV_STATUS sweep belongs in every clone and standby workflow, not just the annual review.
The privilege analysis correction is free money in the literal sense: the feature stopped requiring Database Vault at 18c and became Enterprise Edition functionality, yet quotes still arrive pricing the option for it.
Any Vault line justified by privilege analysis alone is a quote to correct, and any historical purchase made for it is a scope reduction candidate at the next true up.
- Percentile standing for your exact deal size and industry, from real closed transactions
- Scenario simulation before the call: test alternative terms and see the financial impact of each
- A negotiation playbook, talking points, and a two page executive brief on day one
What we saw across security option engagements, 2024 to 2026
Across roughly 25 to 35 Oracle engagements touching Database Vault and the security options, Fredrik Filipsson found the same three shapes of exposure, and none of them started with a decision to deploy:
Vault active on databases the buyer never counted, inherited through clones and standby copies.
Usage records left by trials and explorations, priced as use by every measurement that finds them.
The scoping finding closed the loop: estate wide enablement, usually the path of configuration least resistance, cost 20 to 40 percent more than designs scoped to the regulated databases, for identical compliance outcomes.
The security options reward exactly one posture, deliberate scope with documented reasons, and the neighboring options, masking and subsetting and the packs, follow the same law.
Your first five moves
- Run the three views across the estate: available, enabled, and used, per database, quarterly, before any measurement does.
- Sweep DBA_DV_STATUS in every clone and standby workflow, because the configuration inherits and the 4 in 5 finding is the default.
- Scope the entitlement to the regulated databases, documented, and take the 20 to 40 percent difference out of the design.
- Strike any quote pricing the option for privilege analysis; it has been an Enterprise Edition feature since 18c.
- Clean the evaluation residue deliberately: disable, document the date, and hold the record, so history reads as cleanup rather than use. The Oracle practice and audit defense services run the options estate with you.
Frequently asked questions
How much does Oracle Database Vault cost?
List runs $11,500 per processor or $230 per Named User Plus, plus 22 percent annual support, licensed on top of Enterprise Edition at the database's own counting rules.
Scoped to the databases under a named regulation, the option earns its rate; estate wide, it cost buyers 20 to 40 percent more for the same control.
Is Database Vault included with Oracle Enterprise Edition?
No, it is a separately licensed option, but it ships installed with every 12c and later database, and enabling it is a DBA action requiring no purchase order.
That gap between installed everywhere and licensed somewhere is exactly why Vault appears in audits, and why the enablement status needs active monitoring.
How do we check where Database Vault is enabled?
Three views, three questions: V$OPTION shows availability, universal on modern versions, DBA_DV_STATUS shows current configuration and enablement, and DBA_FEATURE_USAGE_STATISTICS shows historical use, which is what a measurement prices.
In 4 of 5 estates, the sweep found more enablement than the buyer believed.
Why was Vault enabled on databases we never licensed?
Inheritance: the configuration travels with the database, so clones, refreshes, and standby copies built from a configured source carry the enablement silently.
The DBA_DV_STATUS check belongs inside the clone and standby workflows themselves, because the annual review finds the inheritance a year of liability late.
Does privilege analysis require Database Vault?
Not since Oracle Database 18c, where it became an Enterprise Edition feature, yet quotes still arrive pricing the option for it.
Any Vault line justified by privilege analysis alone should be corrected, and historical purchases made for that capability are scope reduction candidates at the next opportunity.
What if our feature usage history already shows Vault use?
The record from evaluations and trials, present in 30 to 45 percent of estates we reviewed, is negotiable context rather than a verdict: disable deliberately, document the date and the evaluation character of the use, and hold the evidence.
A dated cleanup reads very differently from an unexplained history when the script output lands.
