Why Enterprise databases are a separate budget
Proxmox VE needs no expensive hypervisor licenses — often ~90%+ savings there. But if you run Oracle EE or SQL Server Enterprise, database licensing frequently exceeds the virtualization cost itself. Both products apply strict virtualization rules — and Proxmox (KVM/QEMU) is treated by Oracle as soft partitioning, with major financial consequences.
physical cores
soft partitioning (Oracle)
before migration
Decision-makers often assume: "the VM has 4 vCPU, I pay for 4 cores." With Oracle EE and SQL Server EE on Proxmox that's usually wrong. Below — both vendors' rules and practical conclusions for a Proxmox cluster.
Oracle Database Enterprise Edition
Oracle EE is licensed against physical host cores (the Processor License model) or Named User Plus (NUP). Oracle's price list quotes Processor License units, but they are calculated from cores — not CPU sockets. In virtualization, Oracle's hard vs soft partitioning policy is decisive.
| Partitioning type | Technologies Oracle recognizes | Proxmox / KVM |
|---|---|---|
| Hard partitioning | Oracle VM Server, IBM LPAR/DLPAR, capped Solaris Zones | Not applicable |
| Soft partitioning | VMware, Hyper-V, Xen, KVM, containers without hard partitioning | Yes — Proxmox = soft |
Soft partitioning rule: on Proxmox/KVM Oracle requires licensing all physical processor cores on the server where the database runs (or could run) — regardless of vCPU assigned to the VM. Pinning a VM to a subset of cores (CPU affinity) does not, in Oracle's view, exempt the remaining host cores from licensing.
Proxmox/KVM vs Oracle hard partitioning: standard Proxmox VE (KVM) is soft partitioning. Exception: Oracle Linux KVM with pinned cores (CPU pinning via olvm-vmcontrol) may qualify as hard partitioning per Oracle documentation — but excludes live migration and is a different path than a typical Proxmox cluster.
How to count core-based licenses (Processor License):
- Count all physical cores on the server (or servers, if the VM can start on multiple HA nodes).
- Multiply by the Core Processor Licensing Factor (typical x86-64 — Intel Xeon, AMD EPYC: 0.5; same factor as Xeon).
- Round up — that's the number of Processor License units required (with factor 0.5: 1 license = 2 x86 cores).
- There is no separate minimum number of Processor Licenses per server — cores × 0.5, rounded up to a whole license. Do not confuse that with CPU socket count.
Example — 2×32-core host (64 physical cores). 64 cores × ~$23,750/core (Oracle EE, indicative) = ~$1.52M in Oracle EE licenses on one node — whether the VM has 4 or 16 vCPU.
Named User Plus can be cheaper with few users but has minimums tied to Processor License units (typically min. 25 NUP per Processor License). With many users and a large host, core-based licensing usually wins — confirm with an Oracle partner.
Add-ons (Diagnostics Pack, Tuning Pack, RAC, Active Data Guard, etc.) are separate costs under the same model — in Enterprise they often dominate the budget.
Technical Support subscription — costs and scope of rights
Oracle has no Software Assurance program — the annual component for perpetual licenses is the Technical Support Subscription (Premier Support). The first year of support is bought together with the license and, like every later year, costs about 22% of net license price per year (net meaning after discount). The same 22% rate applies to ULAs and large volumes — what can be lower is the discounted base, not the percentage itself. An alternative is a term license (subscription license) where the annual fee covers both usage rights and support.
| Scenario (Oracle EE) | License (one-time) | Support / year (~22%) | License + 3 years support |
|---|---|---|---|
| Dedicated 16-core node | 16 × ~$23,750 ≈ $380,000 | ~$83,600 | ~$630,800 |
| Dedicated 32-core node | 32 × ~$23,750 ≈ $760,000 | ~$167,200 | ~$1.26M |
Without active support your perpetual license still allows use of the version current when support expired, but you lose access to security patches, updates (RU/CPU), My Oracle Support and rights to newer versions. Active support does not change soft partitioning rules — you still license physical cores on every Proxmox host where Oracle can run (or fail over).
With active support you receive:
- Patches and updates — RU/CPU for the current version, security alerts, critical fixes.
- Upgrade rights — upgrades within the same release (e.g. 19c → newer 19c) and paths to new major versions per Oracle Lifetime Support policy.
- My Oracle Support — SR tickets, knowledge base, diagnostic tools.
Support does not cover (requires separate core licenses + their own support):
- Active Data Guard, RAC, Diagnostics Pack, Tuning Pack — separate products licensed per core (same as EE).
- "Unlimited virtualization" — Oracle has no SA equivalent; on one host you license all cores regardless of how many Oracle VMs you run.
- License mobility between HA nodes — no License Mobility across Server Farm equivalent; the 10-day DR exception applies only to one unlicensed standby (strict conditions — see HA info-box); otherwise full node licensing or affinity.
HA cluster — how to license 2 nodes with 32 cores each? Scenario: one Oracle VM with Proxmox HA can run on node A or B at any given time (not both simultaneously).
Option (a): double licensing. You permanently license all cores on both nodes — 64 × ~$23,750 ≈ $1.52M. The VM can fail over because the target node has its own license set. Standard path for HA without affinity limits.
Option (b): one node + affinity. You license only 32 cores on one node (~$760,000) and pin the VM with strict node-affinity — no legal failover to the second host. License savings at the cost of resilience.
No SA equivalent. Unlike SQL Server Enterprise, active Oracle support does not grant license mobility between nodes — you cannot move 16 Processor Licenses (32 cores × 0.5) from A to B on every failover. Every node where Oracle can legally run must have its own fully licensed core scope (soft partitioning).
Exception: 10-day rule (failover / DR). Oracle allows running on one unlicensed spare node in a failover cluster for up to 10 separate 24-hour periods per calendar year (any started day counts in full — not 240 hours total). Conditions: cluster with shared storage (one logical disk array in one data center), only one standby node, instance on standby truly passive until primary fails (not open for reports, not production testing). After the limit is exceeded or for failover outside this exception — full licensing of the target node. Does not replace daily Proxmox HA between two hosts — a narrow DR exception, not an SA equivalent.
What about Data Guard / standby (active/passive)? You have two Oracle instances running simultaneously (primary + standby), but standby is passive — receives redo/logs, does not serve user queries (physical standby without ADG or ADG in apply-only mode). Standby requires separate Oracle EE licenses on all cores of the standby host (soft partitioning — whole node). Active Data Guard is an additional license (~$5,750/core, i.e. ~$11,500 per Processor License) on top of EE on the standby. A physical standby open read-only for users while Redo Apply runs (real-time query) requires full EE + ADG on standby. A logical standby (SQL Apply) used for reports is part of Data Guard included in EE — it needs full EE licenses on the standby host, but no ADG. The 10-day rule applies to cluster failover (HA info-box above), not to exempt a continuously running standby with log replication.
When support pays off: support is practically mandatory in production — without security patches you risk compliance and audit exposure. For TCO planning, count license + 22%/year over 3–5 years. Oracle cost optimization on Proxmox is not "skip support" but smaller dedicated nodes (e.g. 16 cores instead of 128) and affinity instead of double-licensing the whole cluster.
Microsoft's annual equivalent — SQL Server Enterprise Software Assurance — grants different rights (unlimited virtualization, license mobility, failover rights). Compare each vendor's TCO separately.
SQL Server Enterprise
SQL Server Enterprise is licensed per-core. Virtualization rules are more flexible than Oracle's but still demand care on dense Proxmox hosts.
| Model | What you license | When it makes sense on Proxmox |
|---|---|---|
| Per-core (single VM) | cores assigned to the VM (min. 4 cores per VM; the 4-core minimum per physical processor applies when licensing the whole host, not this VM) | 1–2 SQL instances on a node, few VM cores |
| Per-core (whole host) | all physical cores on the server | many SQL VMs on one node — with SA: unlimited VMs; without SA: max as many VMs as core licenses |
| Enterprise + Software Assurance | per-core license with unlimited virtualization rights | dense SQL cluster, license mobility across hosts (SA terms) |
Whole-host density trap: if you choose per-core licensing for all physical cores on the server, you pay for every host core — regardless of how many vCPUs the SQL VM has. On a 128-core host with one small instance that's ~128 × ~$7,562. Avoid this with per-VM licensing (min. 4 cores per machine — from SQL Server 2022 requires SA or subscription) or by dedicating SQL to a smaller node.
Proxmox HA cluster: if the SQL VM can fail over to other nodes, you have two paths: (a) permanently license all cores on every node the VM might land on — expensive, but works without SA; (b) buy licenses for one node and add SA (License Mobility across Server Farm) — move the same licenses between nodes with the VM on failover (no 90-day rule). Without SA and without double licensing, only strict node-affinity remains — no legal cross-host HA.
When SQL Server runs on Windows, a Windows Server guest OS license is also required — see Windows Server licensing on Proxmox VE. On Linux that license is not required: the SQL license works on either platform.
Software Assurance (SA) — costs and unlimited virtualization
Software Assurance is an annual add-on to a perpetual SQL Server Enterprise license costing about 25% of the base license price per year (usually bought as an L&SA bundle for 1–3 years). The more cores you license, the higher the absolute SA cost, though the percentage stays similar.
| Scenario (SQL Server EE) | License (one-time) | SA / year (~25%) | License + 3 years SA |
|---|---|---|---|
| 1 VM, 4 cores (minimum) | 2× 2-core pack ≈ $30,246 | ~$7,562 | ~$52,932 |
| Whole 16-core host | 16 × ~$7,562 ≈ $120,992 | ~$30,248 | ~$211,736 |
| Whole 32-core host | 32 × ~$7,562 ≈ $241,984 | ~$60,496 | ~$423,472 |
Without active SA your SQL Server EE license still works — you can buy licenses for all host cores. The difference is how many SQL VMs you can run on that host, and license mobility between servers:
- No unlimited virtualization — without SA on a fully licensed host (e.g. 32 cores) you can run SQL in VMs up to the number of assigned core licenses — i.e. max 32 SQL VMs on a 32-core server. Within each VM you can run any number of SQL instances — the limit is on virtual machines, not instances inside one VM. From SQL Server 2022, per-VM licensing (without licensing the whole host) requires SA or a subscription.
- 90-day rule — you can reassign a core license to a specific server only once every 90 days. HA failover, live migration between Proxmox nodes or rapid hardware consolidation become a compliance problem.
With active SA you unlock:
- Unlimited virtualization rights — with all host cores fully licensed you can run any number of SQL VMs on that node (e.g. 50 VMs on a 32-core server) plus any number of instances in each — without buying cores per VM. For dense consolidation (many SQL VMs on one host), whole-host + SA usually beats per-VM licensing.
- License Mobility across Server Farm — legally move licenses between servers in a farm more often than every 90 days (requires SA). Essential for a Proxmox HA cluster when the SQL VM can fail over between nodes. Do not confuse with "License Mobility through SA" to a hoster/cloud — different rules apply and unlimited virtualization cannot be combined with that model.
- Upgrade rights — upgrade SQL Server (e.g. 2019 → 2022) during SA without a separate license purchase.
- Failover rights (DR) — an additional passive SQL Server instance in a separate operating system environment on any server. It must be asynchronous and failed over manually, and it must not serve SQL Server data to users or run an active SQL Server workload.
HA cluster — how to license 2 nodes with 32 cores each? Scenario: one SQL VM with Proxmox HA can run on node A or B at any given time (not both simultaneously).
Without SA — option (a): double licensing. You permanently license all cores on both nodes — 64 × ~$7,562 ≈ $484,000. The VM can fail over because the target node has its own permanent license set. Expensive, but HA works without mobility.
Without SA — option (b): one node + affinity. You license only 32 cores on one node (~$242,000) and pin the VM with strict node-affinity — no legal failover to the second host.
With SA — License Mobility across Server Farm. You buy licenses for 32 cores (~$242,000) + SA (~$60,500/year). You assign those same 32 licenses to whichever node currently runs the VM — on failover you move them from A to B (as often as needed, no 90-day rule). You do not pay for 64 cores — you pay for one set + annual SA. Condition: only one VM serves production user traffic at a time (active/passive). If you have two active SQL instances serving users in parallel on both nodes — each such node must be fully licensed; without SA you're back to option (a).
What about log shipping (active/passive)? This is a different pattern from whole-VM failover in Proxmox HA — you have two SQL VMs running simultaneously (primary + standby), but standby is passive: receives transaction logs, runs in NORECOVERY or STANDBY without serving user queries. With active SA, Microsoft's Failover Rights apply: one passive fail-over replica for any purpose (e.g. HA) — with no synchronous-replication or automatic-failover requirement — + one DR replica (asynchronous, manual failover) — no additional SQL licenses on the secondary if it stays passive (allowed: log backups, full backups, checkdb, monitoring). Log shipping fits the DR model (asynchronous replication, manual switchover). Without SA, the standby instance requires separate licensing (option (a) or a license on the secondary). Note: standby with read access for users (reports in STANDBY READ ONLY) is no longer "passive" — full licensing required. Core count on the secondary must not exceed the licensed cores on the primary — when the passive instance becomes active it must be adequately licensed.
When SA pays off and when it doesn't: with 1–2 small SQL instances on a dedicated small node without cross-host HA — per-VM licensing (min. 4 cores) can be cheaper than whole-host + 25%/year SA, but from SQL Server 2022 new per-VM licenses require SA or a subscription (the "per-VM without SA" comparison applies to older licenses). With HA failover between nodes, SA saves double licensing (32 cores + mobility instead of 64 cores permanently). With many SQL VMs running in parallel on multiple nodes — you license each active host anyway. Calculate 3–5 year TCO.
Oracle's annual equivalent — Technical Support Subscription — has different rights (no unlimited virtualization or license mobility). Compare each vendor's TCO separately.
Example — SQL Server EE, 32-core host, 3 SQL VMs. Per-core whole-host license: 32 × ~$7,562 = ~$242,000. With SA: any number of SQL VMs on the node. Without SA: max 32 SQL VMs (one per core license). Three separate 8-core VMs (per-VM model — from SQL Server 2022 requires SA): 3 × 8 × ~$7,562 = ~$181,000. With more VMs on one host, whole-host + SA beats per-VM.
Example — oversubscribe: 8 VMs × 8 vCPU on a 16-core host. On Proxmox you assign 8 SQL machines 8 vCPU each — 64 virtual vCPUs on 16 physical cores (4:1 ratio). SQL licensing does not count vCPUs — it counts physical host cores. Whole-host model (16 cores): 16 × ~$7,562 ≈ ~$121,000 — covers all 8 VMs regardless of oversubscription. Without SA: legal (8 VMs < 16 VM limit). With SA: also legal + mobility between nodes and ability to add more VMs beyond 16. Per-VM model (8 vCPU per machine, from SQL Server 2022 requires SA): 8 × 8 × ~$7,562 ≈ ~$484,000 — four times more expensive for the same workload. Oversubscription lowers hardware cost and raises CPU utilization, but does not reduce required SQL licenses under the per-core whole-host model — you pay for 16 physical cores, not 64 vCPUs. When the guest is Windows, remember separate Windows Server licensing for each VM. On Linux that license is not required.
SQL Server Standard
SQL Server Standard is the second commercial edition (alongside Enterprise). Microsoft describes it as the edition for small and medium organizations: many Enterprise engine features, with limits on scalability and high availability. On Proxmox, Standard is often cheaper than Enterprise — if you fit the edition capacity limits and pick the right model: per-core or Server + CAL.
Capacity limits (2025 edition)
These are product limits per Database Engine instance — independent of whether you buy cores or Server + CAL:
| Metric | SQL Server 2025 Standard | SQL Server 2022 Standard |
|---|---|---|
| Compute (single instance) | lesser of 4 sockets or 32 cores | lesser of 4 sockets or 24 cores |
| Buffer pool memory (single instance) | 256 GB | 128 GB |
SQL Server 2025 Standard also allows 32 GB for the columnstore segment cache (per instance) and 32 GB of In-Memory OLTP data per database. Enterprise under the per-core model has no such core cap (operating-system maximum). On a 128-core host, Standard does not get 128 cores — an instance uses at most 32. In a virtualized environment this limit is counted in logical processors (hardware threads): 32 Standard cores means 32 hardware threads.
128 cores ≠ 128 cores of SQL Standard. The 32-core figure is edition capacity, not a license to buy 32 core licenses on a 128-core bare-metal server. When licensing a physical server per-core, the license count equals all physical cores on the host, with a minimum of 4 per physical processor (socket). The engine still uses at most 32 — you pay for the rest and SQL will not use them.
Two licensing models
| Model | What you buy | CALs | On Proxmox |
|---|---|---|---|
| Per-core | 2-core packs; min. 4 cores per processor (physical host) or min. 4 per virtual OSE | not required | VMs: from SQL Server 2022 only with SA or a subscription |
| Server + CAL | a server license per OSE + a CAL per user or device | required (including indirect access) | one server license per VM/container running SQL; vCPU count does not increase the number of server licenses |
Server + CAL is Standard-only and is not available with pay-as-you-go billing (SQL Server enabled by Azure Arc). New Enterprise purchases are per-core only. A SQL Server CAL is not a SQL login and is not a Windows Server or RDS CAL.
Per-core — physical OSE versus VM
Standard and Enterprise entitlements differ as follows:
- Physical host (all cores): any number of SQL Standard instances in the physical OSE only — even with SA. This is not unlimited virtualization. Microsoft reserves unlimited virtualization for Enterprise when the host is fully licensed with SA or a subscription.
- Single VM (virtual OSE): core licenses equal to virtual cores, min. 4 per VM. If a virtual core maps to more than one hardware thread, you license each mapped thread. Requires SA or a subscription. In that VM: any number of instances; with SA/subscription also unlimited containers in that OSE.
- Without SA / without a subscription: per-VM licensing is unavailable. On Proxmox you cannot legalize a guest SQL instance with a “vCPU only” core count unless SA or a subscription is in place.
List-price example (SQL Server 2025): Standard 2 cores ~$3,945, i.e. ~$1,973 per core. Minimum 4 cores per VM: two packs ≈ $7,890. 32 cores (edition ceiling): 16 packs ≈ $63,120. 128 cores on bare metal: 64 packs ≈ $252,480 for capacity Standard will not use.
Server + CAL — user, device, service account
You buy a server license for each OSE that runs an instance (physical or virtual; a container is a virtual OSE). You may stack server licenses on one device to increase the allowed instances and OSEs. Then a CAL for each user or device that accesses SQL directly or indirectly.
- User CAL — one named person, any number of devices.
- Device CAL — one named device, any number of people. You may mix both types.
- One CAL, many servers: a user or device with a CAL may access more than one licensed SQL Standard server.
- CAL version: a CAL covers that version and earlier versions, not a later version than the CAL.
- Administration: the license terms do not require CALs for up to two devices or uses solely to administer the instances.
- Server-to-server: you do not need CALs for servers already licensed to run SQL Server instances.
- Multiplexing / pooling: an ERP layer, API, RDS or a single service account does not reduce the CAL count. You count people and devices at the end of the chain, not the application login.
- Unattended devices (sensor, kiosk, camera reporting to SQL) also require a Device CAL if they access SQL.
A service account does not replace CALs. One application login for 30 ERP staff = 30 User CALs (or Device CALs for their workstations), plus the server license. A public site or uncountable external users — use the per-core model. Windows Server CALs remain separate when the guest is Windows — they are not SQL CALs.
Assignment and HA. You assign the license to a server; without SA you may reassign no more than once every 90 days (exception: permanent hardware failure). With SA or a subscription, when SQL Standard runs in a virtual OSE, you may move that OSE between servers in the same server farm as often as needed — this applies to both per-core per-VM and Server + CAL in a VM. Licenses without SA / without a subscription do not include disaster-recovery or high-availability rights, including use of fail-over clusters. With SA/subscription: for each licensed OSE you may add a passive HA replica, a passive DR replica, and a passive DR replica on Azure — a passive replica must not serve SQL data to clients or run active SQL workloads, and the licenses that would cover the passive replica must not exceed the primary.
When Server + CAL, when cores: at catalog list prices the 4-core Standard floor (~$7,890) is roughly 30 CALs at ~$230 plus a ~$989 server license. With a known, small internal user population, Server + CAL on a Proxmox VM usually beats 32 or 128 cores. If you cannot enumerate people and devices — per-core, and keep the VM at ≤32 vCPU (and ≤32 threads), because Standard will not use more.
Distributed Availability Groups on SQL Server Standard may be used only to replicate with Azure resources. Developer Edition (Enterprise Developer / Standard Developer) includes the matching edition’s features, but only for development, testing and demonstration — not production.
Proxmox VE: HA, live migration and soft partitioning
Proxmox offers live migration, HA and Dynamic Load Balancing — but from a database licensing perspective each feature can expand the licensing scope unless you design the architecture deliberately.
- Dedicated DB nodes — carve out 1–2 hosts with fewer cores (e.g. EPYC 9175F — 16 high-frequency cores) exclusively for Oracle/SQL; keep the rest of the cluster on dense, cheaper EPYC 9755 nodes.
- Strict HA affinity — pin DB VMs with strict node-affinity to licensed nodes (HA affinity rules) so they never start on unlicensed hosts.
- Disable auto-migration for DB VMs or limit the HA node pool to fully licensed servers only.
- Pre-migration audit — verify existing Oracle/SQL licenses allow changing virtualization platform (contracts, SA, BYOL).
Hypervisor migration (VMware → Proxmox) does not automatically change Oracle or Microsoft licensing rules. It does change compliance risk — Oracle in particular often audits environments after platform changes or consolidation.
Can you reuse existing licenses?
The most common question before migrating from VMware (or bare-metal servers) to Proxmox: do Oracle EE and SQL Server Enterprise licenses you already own still apply, or must you buy again? In most cases — yes, you can continue using them — but changing the virtualization platform requires contract review and often changes the scope of licensing required, not whether the licenses themselves remain valid.
SQL Server Enterprise — VMware, bare metal → Proxmox
| Source scenario | Reusable on Proxmox? | Watch out for |
|---|---|---|
| SQL EE on VMware VM (per-core per VM) | Yes — same core licenses | On Proxmox you license VM cores the same way (min. 4 cores). Changing hypervisor does not invalidate licenses. |
| SQL EE on VMware VM (whole-host per-core + SA) | Yes — keep the host model | With SA: unlimited virtualization on a fully licensed node or license mobility (License Mobility across Server Farm) for active/passive HA — you don't need a second full core set if SQL runs on only one node at a time. |
| SQL EE on bare-metal server | Yes — after migration to VM | Move core licenses to the VM; count VM cores (min. 4) or the whole new Proxmox host — depending on the model you choose. |
| Licenses without active Software Assurance | Yes, but limited mobility | Reassigning a license between hosts (for example HA failover) — once every 90 days. Plan dedicated database nodes. Software Assurance can be added only when the perpetual license is purchased — without it, buy new licenses with SA or a subscription license. |
| SPLA / hoster subscription via partner | Depends on contract | Licenses belong to the partner — confirm whether BYOL on your own Proxmox is allowed. |
Microsoft does not tie SQL Server licenses to VMware. The license covers SQL Server software, not the hypervisor. After P2V/V2V migration to Proxmox you use the same keys and agreements — provided you comply with the per-core or Server + CAL model and any SA requirements. When the guest is Windows, a valid Windows Server guest license is also required. On Linux it is not.
SQL Server Standard — VMware, bare metal → Proxmox
| Source situation | Does the license work on Proxmox? | Watch-outs |
|---|---|---|
| Standard Server + CAL on a VM | Yes — one server license per OSE | On Proxmox each SQL VM needs its own server license. User/Device CALs carry over. vCPU does not increase server-license count. Edition cap: 32 cores / 256 GB buffer pool (2025). |
| Standard per-core on a VM (with SA / subscription) | Yes — the same core licenses | Min. 4 cores per VM; from SQL Server 2022 per-VM requires SA or a subscription. Do not assign more than 32 threads — Standard will not use them. |
| Standard per-core on physical hardware | Yes, but the entitlement scope changes | Physical-OSE licensing covers instances in the physical OSE only, not KVM guests. After P2V to Proxmox you move to per-VM (SA/subscription) or Server + CAL on the VM. |
Oracle Database Enterprise Edition — VMware, bare metal → Proxmox
| Source scenario | Reusable on Proxmox? | Watch out for |
|---|---|---|
| Oracle EE — Processor License (perpetual / subscription) | Yes — licenses are portable | Oracle does not restrict the platform to VMware. The same soft partitioning rules apply — on Proxmox you license physical host cores (or the HA node pool). |
| Oracle EE on bare-metal server | Yes — after P2V to Proxmox | If you licensed e.g. 32 cores on physical hardware, the Proxmox VM must land on a node with at most the same (or fewer) licensed cores — otherwise you must buy more. |
| Oracle EE on VMware (soft partitioning) | Yes — same model | VMware and Proxmox = soft partitioning in Oracle's view. Licensing scope is comparable: whole host (or HA nodes), not just VM vCPU. |
| ULA / CSI / all-you-can-eat agreement | Check the definition of "server" | ULA may require reporting new hosts or migrations within the pool. Platform change does not remove audit risk when exiting ULA. |
| Named User Plus (NUP) licenses | Yes — users remain | NUP minimums relative to Processor License still apply on the new host. |
Owning licenses ≠ zero migration cost. If Oracle on VMware ran on a dedicated 32-core server and after migration the VM lands on a shared 128-core node — you may need to buy more licenses for the extra cores (or move the VM to a smaller, dedicated Proxmox node). This is the most common mistake when assuming "we already have licenses, so we pay nothing".
Pre-migration checklist
- License inventory — type (per-core / Server + CAL / Processor / NUP), purchase date, SA status (SQL), Oracle support, contract number.
- Scope comparison — how many cores were licensed on VMware/bare metal vs what the target Proxmox host requires (including HA nodes).
- License agreement — clauses on platform change, sublicensing, audit, ULA deployment reporting.
- HA affinity — pin DB VMs to nodes covered by existing licenses; never start on unlicensed hosts, even "temporarily".
- Audit documentation — VM → node → license map; Oracle and Microsoft may ask after a VMware migration.
Summary: existing MSSQL Enterprise and Oracle EE licenses from VMware or physical servers can usually be used legally on Proxmox — it is not a "buy everything again" scenario. Risk lies in expanded scope (larger host, HA, soft partitioning) and contract terms, not in the hypervisor change itself. Run a licensing audit with a Microsoft/Oracle partner or independent advisor before cutover.
Catalog prices (indicative)
Below are indicative list prices (USD, before partner discounts). Real rates depend on enterprise agreements, channel and volume — use as a budgeting reference, not a quote.
Oracle Database Enterprise Edition
| Item | Catalog price (USD) |
|---|---|
| Oracle EE — core license (Processor License) | ~$23,750 / core |
| Named User Plus (Oracle EE) | ~$950 / user |
| Real Application Clusters (RAC) — add-on | ~$11,500 / core |
| Active Data Guard — add-on | ~$5,750 / core |
| Technical Support (annual, ~22% of license) | depends on licensed cores; required for patches and updates |
Oracle's price list quotes Processor License units (~$47,500) — a licensing unit derived from cores, not a per-CPU-socket price. With a 0.5 factor for x86-64 processors (Intel Xeon, AMD EPYC), one Processor License covers 2 physical cores (~$23,750/core). There is no separate minimum number of Processor Licenses per server. Full Technical Support details — in Oracle Database Enterprise Edition.
SQL Server Enterprise
| Item | Catalog price (USD) |
|---|---|
| SQL Server Enterprise — 2-core pack | ~$15,123 |
| SQL Server Enterprise — per-core equivalent (sold only in 2-core packs) | ~$7,562 |
| Software Assurance (annual, ~25% of license) | depends on licensed cores; required e.g. for unlimited virtualization |
Full Software Assurance details (unlimited virtualization, license mobility, HA scenarios) — in SQL Server Enterprise. Oracle's annual equivalent — Technical Support Subscription.
SQL Server Standard
| Item | Catalog price (USD) |
|---|---|
| SQL Server Standard — 2-core pack | ~$3,945 |
| SQL Server Standard — per-core equivalent (sold only in 2-core packs) | ~$1,973 |
| SQL Server Standard — server license (Server + CAL) | ~$989 |
| SQL Server 2025 CAL (User or Device) | ~$230 |
Catalog prices, indicative. Server + CAL and per-core models — SQL Server Standard.
All prices in USD (indicative list, before partner discounts). Oracle publishes in USD; Microsoft in USD/EUR depending on channel. Cloud subscriptions (Oracle Cloud BYOL, Azure SQL, SQL on Azure VMs) use a different cost model — compare 3–5 year TCO.
Optimization strategies and recommendations
Proxmox Migracje recommendation: for nodes dedicated to enterprise databases (Oracle EE, SQL Server Enterprise) we recommend the AMD EPYC 9175F — 16 high-frequency cores with strong per-core performance and the smallest practical core count to license.
- Oracle EE on Proxmox → dedicated node with the smallest practical core count; avoid Oracle on a dense 128-core host shared with hundreds of VMs.
- SQL Server EE — many instances → license the whole host per-core (+ SA if HA mobility is needed).
- SQL Server EE — 1–2 small instances → per-VM licensing (min. 4 cores; from SQL Server 2022 requires SA or subscription).
- SQL Server Standard → VM ≤32 vCPU (and ≤32 threads). Countable internal users: Server + CAL (one server license per VM). Uncountable access or higher compute needs: per-core on the VM with SA/subscription — do not per-core-license a 128-core host for Standard, because the edition uses at most 32 cores and a physical-OSE entitlement does not cover Proxmox guests.
- HA cluster (SQL) → single VM with failover: 32 cores + SA (mobility between nodes) instead of double-licensing both hosts; many parallel VMs → each active node fully licensed. Oracle → dedicated affinity-pinned nodes.
- Consider PostgreSQL / Oracle Standard Edition 2 where business requirements allow — TCO difference can be multiples.
Oracle and Microsoft models and prices change over time — confirm your scenario, contracts and current rates with an authorized partner. The above are general rules and indicative prices, not commercial, legal or tax advice.
Related articles: Windows Server licensing, RHEL licensing, AMD EPYC 9175F for databases.
We'll size DB licenses for your Proxmox cluster
We'll calculate required Oracle EE and SQL Server Enterprise licensing — including HA, affinity and optimal node architecture — before you approve VMware migration.
⚡ Free consultation → Windows Server licensing