// Analiza dla decydentów // Oracle · SQL Server · Licencje

Licencjonowanie Oracle EE
i SQL Server Enterprise

Migracja z VMware na Proxmox obniża koszt hypervisora — ale Oracle Database Enterprise Edition i Microsoft SQL Server Enterprise nadal liczą się od fizycznej infrastruktury, nie od vCPU maszyny. Na gęstym hoście z 64 czy 128 rdzeniami jedna baza danych może wymagać licencji na cały serwer tak jak w przypadku VMware. Wyjaśniamy modele licencyjne obu vendorów na Proxmox VE, pułapkę soft partitioningu i strategie, które realnie obniżają rachunek.

// 01 · Kontekst

Dlaczego bazy Enterprise to osobny budżet

Proxmox VE nie wymaga drogich licencji hypervisora — to oszczędność rzędu 90%+. Jednak jeśli w środowisku działają Oracle EE lub SQL Server Enterprise, koszt licencji baz danych często przewyższa koszt samej wirtualizacji. Oba produkty mają restrykcyjne zasady licencjonowania w środowiskach wirtualnych — a Proxmox (KVM/QEMU) jest traktowany przez Oracle jako soft partitioning, co ma kluczowe konsekwencje finansowe.

host
Licencja liczy się
od fizycznych rdzeni
soft
KVM/Proxmox =
soft partitioning (Oracle)
plan
Architektura licencji
planujesz przed migracją

Decydenci często zakładają: „skoro VM ma 4 vCPU, płacę za 4 rdzenie”. Przy Oracle EE i SQL Server EE na Proxmox to najczęściej błędne założenie. Poniżej — reguły licencyjne obu vendorów i praktyczne wnioski dla klastra Proxmox.

// 02 · Oracle

Oracle Database Enterprise Edition

Oracle EE licencjonuje się od fizycznych rdzeni hosta (model Processor License) lub Named User Plus (NUP — per użytkownik). W cenniku Oracle podaje stawkę za Processor License, ale wylicza ją z rdzeni — nie z socketów CPU. W wirtualizacji decydująca jest polityka hard vs soft partitioning opublikowana przez Oracle.

Typ partycjonowaniaTechnologie uznawane przez OracleProxmox / KVM
Hard partitioningOracle VM Server, wybrane LPAR/DRP, Solaris Zones (z ograniczeniami)Nie dotyczy
Soft partitioningVMware, Hyper-V, Xen, KVM, kontenery bez hard partitioninguTak — Proxmox = soft
⚠️

Reguła soft partitioningu: przy Proxmox/KVM Oracle wymaga licencjonowania wszystkich fizycznych rdzeni procesora na serwerze, na którym działa (lub może działać) baza — niezależnie od liczby vCPU przydzielonych maszynie. Przypięcie VM do podzbioru rdzeni (CPU affinity) nie zwalnia z licencjonowania pozostałych rdzeni hosta w ocenie Oracle.

ℹ️

Proxmox/KVM a hard partitioning Oracle: standardowy Proxmox VE (KVM) to soft partitioning. Wyjątek: Oracle Linux KVM z przypiętymi rdzeniami (CPU pinning przez olvm-vmcontrol) może kwalifikować się jako hard partitioning wg dokumentacji Oracle — ale wyklucza live migration i to inna ścieżka niż typowy klaster Proxmox.

Jak liczyć licencje od rdzeni (Processor License):

  • Policz wszystkie fizyczne rdzenie serwera (lub serwerów, jeśli VM może się uruchomić na wielu węzłach HA).
  • Pomnóż przez Core Processor Licensing Factor (dla typowych procesorów x86-64 — Intel Xeon, AMD EPYC: 0,5; ten sam współczynnik co dla Xeon).
  • Zaokrąglij w górę — wynik to liczba wymaganych licencji Processor License (przy współczynniku 0,5: 1 licencja = 2 rdzenie x86).
  • Minimum: 2 licencje Processor License na serwer (nie mylić z liczbą socketów CPU).
💡

Przykład — host 2×32 rdzenie (64 fizyczne rdzenie). 64 rdzeni × ~23 750 USD/rdzeń (Oracle EE, orientacyjnie) = ~1,52 mln USD samych licencji Oracle EE na jednym węźle — niezależnie od tego, czy VM ma 4 czy 16 vCPU.

Model Named User Plus bywa tańszy przy małej liczbie użytkowników, ale ma minimum NUP powiązane z liczbą Processor License (typowo min. 25 NUP na Processor License). Przy wielu użytkownikach i dużym hoście licencjonowanie od rdzeni zwykle wygrywa — szczegóły wymagają kalkulacji u partnera Oracle.

Opcje dodatkowe (Diagnostics Pack, Tuning Pack, RAC, Active Data Guard itd.) to osobne koszty licencjonowane tym samym modelem — w Enterprise często stanowią znaczący udział budżetu.

Subskrypcja wsparcia technicznego (Technical Support) — koszty i zakres uprawnień

Oracle nie ma programu Software Assurance — odpowiednikiem rocznego komponentu przy licencjach wieczystych jest Technical Support Subscription (subskrypcja wsparcia technicznego, Premier Support). Pierwszy rok supportu zwykle jest w pakiecie z zakupem licencji; kolejne lata kosztują ok. 22% ceny netto licencji rocznie (stawka katalogowa — przy ULA lub dużych wolumenach bywa niższa, np. 8–15%). Alternatywą jest licencja terminowa (subscription license) — wtedy opłata roczna obejmuje zarówno prawo użytkowania, jak i support.

Scenariusz (Oracle EE)Licencja (jednorazowo)Support / rok (~22%)Licencja + 3 lata supportu
Dedykowany węzeł 16 rdzeni16 × ~$23 750 ≈ $380 000 (~1,52 mln zł)~$83 600 (~334 000 zł)~$630 800 (~2,52 mln zł)
Dedykowany węzeł 32 rdzenie32 × ~$23 750 ≈ $760 000 (~3,04 mln zł)~$167 200 (~669 000 zł)~$1,26 mln (~5,04 mln zł)

Bez aktywnego supportu licencja wieczysta nadal pozwala używać wersji z momentu wygaśnięcia supportu, ale tracisz dostęp do patchy bezpieczeństwa, aktualizacji (RU/CPU), My Oracle Support i prawa do nowszych wersji. Aktywny support nie zmienia zasad soft partitioningu — nadal licencjonujesz fizyczne rdzenie każdego hosta Proxmox, na którym Oracle może działać (lub failoverować).

Z aktywnym supportem otrzymujesz:

  • Patchy i aktualizacje — RU/CPU bieżącej wersji, security alerts, poprawki krytyczne.
  • Prawo do nowszych wersji — upgrade w ramach tego samego numeru wersji (np. 19c → nowsza 19c) oraz ścieżki do nowej wersji głównej zgodnie z polityką Lifetime Support Oracle.
  • My Oracle Support — zgłoszenia SR, baza wiedzy, narzędzia diagnostyczne.

Support nie obejmuje (wymaga osobnych licencji rdzeniowych + własnego supportu):

  • Active Data Guard, RAC, Diagnostics Pack, Tuning Pack — osobne produkty licencjonowane od rdzeni (tak samo jak EE).
  • „Unlimited virtualization” — Oracle nie ma odpowiednika SA; na jednym hoście licencjonujesz wszystkie rdzenie, niezależnie od liczby VM Oracle.
  • Mobilności licencji między węzłami HA — brak odpowiednika License Mobility across Server Farm; wyjątek 10 dni DR tylko dla jednego nielicencjonowanego standby (ostre warunki — patrz info-box HA); poza nim pełne licencjonowanie węzła lub affinity.
⚠️

Klaster HA — jak licencjonować 2 węzły po 32 rdzenie? Scenariusz: jedna VM Oracle z HA Proxmox może w danym momencie działać na węźle A lub B (nie na obu jednocześnie).

Opcja (a): podwójne licencjonowanie. Licencjonujesz na stałe wszystkie rdzenie obu węzłów — 64 × ~$23 750 ≈ $1,52 mln. VM może failoverować, bo docelowy węzeł ma własny zestaw licencji. To standardowa ścieżka przy HA bez ograniczeń affinity.

Opcja (b): jeden węzeł + affinity. Licencjonujesz tylko 32 rdzenie jednego węzła (~$760 000) i trzymasz VM przez strict node-affinity — bez legalnego failoveru na drugi host. Oszczędność licencji kosztem odporności.

Brak odpowiednika SA. W przeciwieństwie do SQL Server Enterprise, aktywny support Oracle nie daje mobilności licencji między węzłami — nie przenosisz 32 licencji z A na B przy każdym failoverze. Każdy węzeł, na którym Oracle może legalnie działać, musi mieć własny, w pełni licencjonowany zakres rdzeni (soft partitioning).

Wyjątek: reguła 10 dni (failover / DR). Oracle dopuszcza uruchomienie na jednym nielicencjonowanym węźle zapasowym w klastrze failover do 10 oddzielnych okresów 24 h w roku kalendarzowym (każdy rozpoczęty dzień liczy się w całości — to nie jest 240 godzin łącznie). Warunki: klaster z współdzielonym storage (jedna logiczna macierz w jednym ośrodku), tylko jeden węzeł standby, instancja na standby naprawdę pasywna do momentu awarii primary (nie otwarta dla raportów, nie testy produkcyjne). Po przekroczeniu limitu lub przy failoverze poza tym wyjątkiem — pełne licencjonowanie węzła docelowego. Nie zastępuje to codziennego HA Proxmox między dwoma hostami — to wąski wyjątek DR, nie odpowiednik SA.

ℹ️

A Data Guard / standby (active/passive)? Masz dwie instancje Oracle jednocześnie (primary + standby), ale standby jest pasywna — odbiera redo/logi, nie obsługuje zapytań użytkowników (fizyczny standby bez ADG lub z ADG w trybie apply-only). Standby wymaga osobnych licencji Oracle EE na wszystkich rdzeniach hosta standby (soft partitioning — cały węzeł). Active Data Guard to dodatkowa licencja rdzeniowa (~$11 500/rdzeń) oprócz EE na standby. Standby z odczytem dla użytkowników (Active Data Guard w trybie query, logical standby z raportami) wymaga pełnych licencji EE + ADG na standby. Reguła 10 dni dotyczy failoveru klastra (info-box HA powyżej), nie zwalnia z licencji przy ciągłym standby z replikacją logów.

💡

Kiedy support się opłaca: support jest praktycznie obowiązkowy w produkcji — bez patchy bezpieczeństwa ryzykujesz compliance i audyt. Przy planowaniu TCO licz licencję + 22%/rok przez 3–5 lat. Optymalizacja kosztów Oracle na Proxmox to nie „rezygnacja ze supportu”, lecz mniejsze węzły dedykowane (np. 16 rdzeni zamiast 128) i affinity zamiast podwójnego licencjonowania całego klastra.

ℹ️

Roczny odpowiednik SA u Microsoftu — Software Assurance SQL Server Enterprise — daje inne uprawnienia (unlimited virtualization, mobilność licencji, failover rights). Porównuj TCO obu vendorów osobno.

// 03 · Microsoft

SQL Server Enterprise

SQL Server Enterprise licencjonuje się modelu per-core (za rdzeń). Zasady na wirtualizacji są bardziej elastyczne niż u Oracle, ale nadal wymagają uwagi na gęstych hostach Proxmox.

ModelCo licencjonujeszKiedy ma sens na Proxmox
Per-core (pojedyncza VM)rdzenie przypisane do VM (min. 4 rdzenie na VM, min. 4 rdzenie na procesor fizyczny)1–2 instancje SQL na węźle, mało rdzeni w VM
Per-core (cały host)wszystkie fizyczne rdzenie serwerawiele VM SQL na węźle — z SA: nieograniczona liczba VM; bez SA: max tyle VM, ile licencji rdzeniowych
Enterprise + Software Assurancelicencja per-core z prawem unlimited virtualizationgęsty klaster SQL, mobilność licencji między hostami (warunki SA)
⚠️

Pułapka gęstości przy licencjonowaniu całego hosta: jeśli wybierzesz model per-core na wszystkie fizyczne rdzenie serwera, płacisz za każdy rdzeń hosta — niezależnie od tego, ile vCPU ma VM SQL. Na hoście 128-rdzeniowym z jedną małą instancją to ~128 × ~$7 562. Unikasz tego licencjonując per-VM (min. 4 rdzenie na maszynę — od SQL Server 2022 wymaga SA lub subskrypcji) albo wydzielając SQL na mniejszy, dedykowany węzeł.

Klaster HA Proxmox: jeśli VM SQL może failoverować na inne węzły, masz dwie drogi: (a) na stałe licencjonujesz wszystkie rdzenie każdego węzła, na który VM może trafić — drogo, ale działa bez SA; (b) kupujesz licencje na jeden węzeł i dodajesz SA (License Mobility across Server Farm) — te same licencje przenosisz między węzłami razem z VM przy failoverze (bez reguły 90 dni). Bez SA i bez podwójnego licencjonowania zostaje tylko strict node-affinity — bez legalnego HA między hostami.

SQL Server wymaga też licencji Windows Server jako systemu gościa — zobacz Licencjonowanie Windows Server na Proxmox VE.

Software Assurance (SA) — koszty i unlimited virtualization

Software Assurance to roczny dodatek do wieczystej licencji SQL Server Enterprise, kosztujący ok. 25% ceny bazowej licencji rocznie (kupowany zwykle w pakiecie L&SA na 1–3 lata). Im więcej rdzeni licencjonujesz, tym wyższy absolutny koszt SA, choć procent pozostaje podobny.

Scenariusz (SQL Server EE)Licencja (jednorazowo)SA / rok (~25%)Licencja + 3 lata SA
1 VM, 4 rdzenie (minimum)2× pakiet 2-rdzeniowy ≈ $15 123 (~60 500 zł)~$3 781 (~15 100 zł)~$26 465 (~106 000 zł)
Cały host 16 rdzeni16 × ~$7 562 ≈ $120 992 (~484 000 zł)~$30 248 (~121 000 zł)~$211 736 (~847 000 zł)
Cały host 32 rdzenie32 × ~$7 562 ≈ $241 984 (~968 000 zł)~$60 496 (~242 000 zł)~$423 472 (~1,69 mln zł)

Bez aktywnego SA licencja SQL Server EE nadal działa — możesz kupić licencje na wszystkie rdzenie hosta. Różnica dotyczy jednak tego, ile maszyn wirtualnych z SQL możesz na tym hoście uruchomić, oraz mobilności licencji między serwerami:

  • Brak unlimited virtualization — bez SA na w pełni licencjonowanym hoście (np. 32 rdzenie) uruchomisz SQL w VM maksymalnie w liczbie równiej liczbie przypisanych licencji rdzeniowych — czyli max 32 VM SQL na 32-rdzeniowym serwerze. W każdej z tych VM możesz mieć dowolną liczbę instancji SQL wewnątrz — ograniczenie dotyczy liczby maszyn wirtualnych, nie instancji w jednej VM. Od SQL Server 2022 licencjonowanie per-VM (bez licencjonowania całego hosta) wymaga SA lub subskrypcji.
  • Reguła 90 dni — przypisanie licencji rdzeniowej do konkretnego serwera możesz zmienić tylko raz na 90 dni. Failover HA, live migration między węzłami Proxmox lub szybka konsolidacja sprzętu stają się problemem compliance.

Z aktywnym SA odblokowujesz:

  • Unlimited virtualization rights — przy pełnym licencjonowaniu wszystkich rdzeni hosta możesz uruchamiać dowolną liczbę VM SQL na tym węźle (np. 50 VM na 32-rdzeniowym serwerze) oraz dowolną liczbę instancji w każdej z nich — bez dokupowania rdzeni per VM. Przy gęstej konsolidacji (wiele VM SQL na jednym hoście) model hosta + SA zwykle wygrywa z licencjonowaniem per-VM.
  • License Mobility across Server Farm — legalne przenoszenie licencji między serwerami w farmie częściej niż co 90 dni (wymaga SA). To warunek konieczny przy klasterze Proxmox HA, gdy VM SQL może failoverować między węzłami. Nie mylić z „License Mobility through SA” do hostera/chmury — tam obowiązują inne zasady i unlimited virtualization nie łączy się z tym modelem.
  • Prawo do nowszych wersji — upgrade SQL Server (np. 2019 → 2022) w trakcie trwania SA bez osobnego zakupu licencji.
  • Failover rights (DR) — dodatkowa pasywna instancja SQL na serwerze przeznaczonym wyłącznie do odzyskiwania awarii, przy spełnieniu warunków Microsoftu (instancja nie obsługuje produkcyjnego ruchu).
⚠️

Klaster HA — jak licencjonować 2 węzły po 32 rdzenie? Scenariusz: jedna VM SQL z HA Proxmox może w danym momencie działać na węźle A lub B (nie na obu jednocześnie).

Bez SA — opcja (a): podwójne licencjonowanie. Licencjonujesz na stałe wszystkie rdzenie obu węzłów — 64 × ~$7 562 ≈ $484 000. VM może failoverować, bo docelowy węzeł ma własny, stały zestaw licencji. Drogo, ale HA działa bez mobilności.

Bez SA — opcja (b): jeden węzeł + affinity. Licencjonujesz tylko 32 rdzenie jednego węzła (~$242 000) i trzymasz VM przez strict node-affinity — bez legalnego failoveru na drugi host.

Z SA — mobilność licencji (License Mobility across Server Farm). Kupujesz licencje na 32 rdzenie (~$242 000) + SA (~$60 500/rok). Te same 32 licencje przypisujesz do węzła, na którym aktualnie działa VM — przy failoverze przenosisz je z A na B (wielokrotnie, bez reguły 90 dni). Nie płacisz za 64 rdzenie — płacisz za jeden zestaw + roczne SA. Warunek: tylko jedna VM obsługuje produkcyjny ruch naraz (active/passive). Jeśli masz dwie aktywne instancje SQL z obciążeniem użytkowników równolegle na obu węzłach — każdy taki węzeł musi być w pełni licencjonowany; bez SA wraca opcja (a).

ℹ️

A log shipping (active/passive)? To inny wzorzec niż failover całej VM w Proxmox HA — masz dwie VM SQL jednocześnie (primary + standby), ale standby jest pasywna: odbiera logi transakcyjne, działa w trybie NORECOVERY lub STANDBY bez obsługi zapytań użytkowników. Przy aktywnym SA obowiązują Failover Rights Microsoftu: jedna pasywna replika HA (synchroniczna, auto-failover) + jedna replika DR (asynchroniczna, ręczny failover) — bez dodatkowych licencji SQL na secondary, jeśli pozostaje pasywna (dozwolone m.in.: backup logów, full backup, checkdb, monitoring). Log shipping wpisuje się w model DR (asynchroniczna replikacja, ręczne przełączenie). Bez SA instancja standby wymaga osobnego licencjonowania (opcja (a) lub licencja na secondary). Uwaga: standby z odczytem dla użytkowników (raporty w trybie STANDBY READ ONLY) już nie jest „pasywna” — wymaga pełnych licencji. Liczba rdzeni na secondary nie może przekraczać liczby rdzeni objętych licencją na primary — przy przejęciu roli active passive musi być wystarczająco licencjonowana.

💡

Kiedy SA się opłaca, a kiedy nie: przy 1–2 małych instancjach SQL na dedykowanym, małym węźle bez HA — licencja per-VM (min. 4 rdzenie) bywa tańsza niż host + 25%/rok SA, ale od SQL Server 2022 nowe licencje per-VM wymagają SA lub subskrypcji (porównanie „per-VM bez SA” dotyczy starszych licencji). Przy HA z failoverem między węzłami SA oszczędza podwójne licencjonowanie (32 rdzenie + mobilność zamiast 64 rdzeni na stałe). Przy wielu VM SQL równolegle na wielu węzłach — i tak licencjonujesz każdy aktywny host. Policz TCO na 3–5 lat.

ℹ️

Roczny odpowiednik u Oracle — Technical Support Subscription — ma inne uprawnienia (brak unlimited virtualization i mobilności licencji). Porównuj TCO obu vendorów osobno.

💡

Przykład — SQL Server EE, host 32 rdzenie, 3 VM SQL. Licencja per-core na cały host: 32 × ~7 562 = ~242 000 USD (~970 000 zł). Z SA: dowolna liczba VM SQL na węźle. Bez SA: max 32 VM SQL (po jednej na każdą licencję rdzeniową). Trzy osobne VM po 8 rdzeniach (model per-VM — od SQL Server 2022 wymaga SA): 3 × 8 × ~7 562 = ~181 000 USD. Przy większej liczbie VM na jednym hoście licencjonowanie całego hosta + SA wygrywa z per-VM.

💡

Przykład — oversubscribe: 8 VM × 8 vCPU na hoście 16 rdzeni. Na Proxmox przydzielasz 8 maszynom SQL po 8 vCPU — łącznie 64 vCPU wirtualnych na 16 rdzeniach fizycznych (stosunek 4:1). Licencjonowanie SQL nie liczy vCPU — liczy fizyczne rdzenie hosta. Model cały host (16 rdzeni): 16 × ~$7 562 ≈ ~121 000 USD (~484 000 zł) — pokrywa wszystkie 8 VM, niezależnie od oversubscribe. Bez SA: legalne (8 VM < limit 16 VM). Z SA: też legalne + mobilność między węzłami i możliwość dodania kolejnych VM ponad 16. Model per-VM (8 vCPU na maszynę, od SQL Server 2022 wymaga SA): 8 × 8 × ~$7 562 ≈ ~484 000 USDczterokrotnie drożej przy tym samym obciążeniu. Oversubscribe obniża koszt sprzętu i zwiększa wykorzystanie CPU, ale nie zmniejsza wymaganych licencji SQL przy modelu per-core hosta — płacisz za 16 rdzeni fizycznych, nie za 64 vCPU. Pamiętaj też o osobnym licencjonowaniu Windows Server w każdej maszynie gościa.

// 04 · Proxmox

Proxmox VE: HA, migracja na żywo i soft partitioning

Proxmox oferuje live migration, HA i Dynamic Load Balancing — ale z perspektywy licencji baz danych każda z tych funkcji może poszerzyć wymagany zakres licencjonowania, jeśli nie zaplanujesz architektury świadomie.

  • Dedykowane węzły DB — wydziel 1–2 hosty z mniejszą liczbą rdzeni (np. EPYC 9175F — 16 rdzeni wysokotaktowanych) wyłącznie pod Oracle/SQL; reszta klastra na tanich, gęstych EPYC 9755.
  • Twarda reguła HA affinity — przypnij VM bazy danych strict node-affinity do licencjonowanych węzłów (reguły HA affinity), tak by nigdy nie uruchomiły się na nieobjętych licencją hostach.
  • Wyłącz auto-migrację dla VM DB lub ogranicz pulę węzłów HA wyłącznie do w pełni licencjonowanych serwerów.
  • Audyt przed migracją z VMware — sprawdź, czy obecne licencje Oracle/SQL pozwalają na zmianę platformy wirtualizacji (umowy, SA, BYOL).
ℹ️

Migracja hypervisora (VMware → Proxmox) nie zmienia automatycznie zasad licencjonowania Oracle ani Microsoft. Zmienia się profil ryzyka compliance — Oracle szczególnie często audytuje środowiska po zmianie platformy lub konsolidacji.

// 05 · Istniejące licencje

Czy można użyć dotychczasowych licencji?

Najczęstsze pytanie przed migracją z VMware (lub z serwerów fizycznych) na Proxmox: czy już wykupione licencje Oracle EE i SQL Server Enterprise nadal obowiązują, czy trzeba kupować je od nowa? W większości przypadków — tak, licencje można kontynuować, ale zmiana platformy wirtualizacji wymaga weryfikacji umowy i często zmienia zakres wymaganych licencji, nie sam fakt posiadania licencji.

SQL Server Enterprise — VMware, fizyczny serwer → Proxmox

Sytuacja źródłowaCzy licencja nadaje się na Proxmox?Na co uważać
SQL EE na VM w VMware (per-core na VM)Tak — te same licencje rdzenioweNa Proxmox licencjonujesz rdzenie VM tak samo (min. 4 rdzenie). Zmiana hypervisora nie unieważnia licencji.
SQL EE na VM w VMware (per-core na cały host + SA)Tak — z zachowaniem modelu hostaZ SA: unlimited virtualization na w pełni licencjonowanym węźle lub mobilność licencji (License Mobility across Server Farm) przy HA active/passive — nie musisz kupować drugiego kompletu rdzeni, jeśli SQL działa tylko na jednym węźle naraz.
SQL EE na serwerze fizycznym (bare metal)Tak — po migracji do VMLicencje rdzeniowe przenosisz na VM; liczysz rdzenie VM (min. 4) lub cały nowy host Proxmox — zależnie od wybranego modelu.
Licencje bez aktywnego Software AssuranceTak, ale ograniczona mobilnośćPrzeniesienie licencji między hostami (np. failover HA) — co 90 dni. Planuj dedykowane węzły DB lub wznów SA przed migracją.
Subskrypcja SPLA / hostingowa u partneraZależy od umowyLicencje należą do partnera — potwierdź, czy BYOL na własnym Proxmox jest dozwolone.
💡

Microsoft nie wiąże licencji SQL Server z VMware. Licencja dotyczy oprogramowania SQL Server, nie hypervisora. Po migracji P2V/V2V na Proxmox używasz tych samych kluczy i umów — pod warunkiem zgodności z modelem per-core i ewentualnym SA. Wymagana jest też ważna licencja Windows Server w maszynie gościa.

Oracle Database Enterprise Edition — VMware, fizyczny serwer → Proxmox

Sytuacja źródłowaCzy licencja nadaje się na Proxmox?Na co uważać
Oracle EE — Processor License (wieczysta / subskrypcja)Tak — licencje są przenośneOracle nie ogranicza platformy do VMware. Obowiązują te same reguły soft partitioningu — na Proxmox licencjonujesz fizyczne rdzenie hosta (lub pulę węzłów HA).
Oracle EE na serwerze fizycznymTak — po P2V na ProxmoxJeśli na fizycznym hoście licencjonowałeś np. 32 rdzenie, na Proxmox VM musi trafić na węzeł z co najwyżej taką samą (lub mniejszą) liczbą licencjonowanych rdzeni — inaczej dokupujesz.
Oracle EE na VMware (soft partitioning)Tak — ten sam modelVMware i Proxmox = soft partitioning w ocenie Oracle. Zakres licencji jest porównywalny: cały host (lub węzły HA), nie tylko vCPU VM.
Umowa ULA / CSI / all-you-can-eatSprawdź definicję „serwera”ULA może wymagać zgłoszenia nowych hostów lub migracji w ramach puli. Zmiana platformy nie zwalnia z audytu przy wyjściu z ULA.
Licencje NUP (Named User Plus)Tak — użytkownicy zostająMinimum NUP względem Processor License nadal obowiązuje na nowym hoście.
⚠️

Posiadanie licencji ≠ brak kosztów przy migracji. Jeśli na VMware Oracle działał na dedykowanym serwerze 32-rdzeniowym, a po migracji VM trafi na współdzielony węzeł 128-rdzeniowy — możesz potrzebować dokupienia licencji na brakujące rdzenie (albo przenieść VM na mniejszy, dedykowany węzeł Proxmox). To najczęstszy błąd przy założeniu „mamy już licencje, więc nic nie płacimy”.

Lista kontrolna przed migracją

  • Inwentaryzacja licencji — typ (per-core / Processor / NUP), data zakupu, status SA (SQL), support Oracle, numer umowy.
  • Porównanie zakresu — ile rdzeni było licencjonowanych na VMware/fizycznym vs ile wymaga docelowy host Proxmox (w tym węzły HA).
  • Umowa licencyjna — klauzule o zmianie platformy, sublicencjonowaniu, audycie, ULA deployment reporting.
  • Affinity HA — przypnij VM DB do węzłów objętych istniejącymi licencjami; nie uruchamiaj na nieobjętych hostach nawet „tymczasowo”.
  • Dokumentacja dla audytu — mapa VM → węzeł → licencje; Oracle i Microsoft mogą pytać po migracji z VMware.
ℹ️

Podsumowanie: dotychczasowe licencje MSSQL Enterprise i Oracle EE z VMware lub serwerów fizycznych zwykle można legalnie używać na Proxmox — to nie jest „nowy zakup od zera”. Ryzyko leży w rozszerzeniu zakresu (większy host, HA, soft partitioning) i w warunkach umowy, nie w samej zmianie hypervisora. Przed cutoverem zrób audyt licencyjny z partnerem Microsoft/Oracle lub niezależnym doradcą.

// 06 · Cennik

Ceny katalogowe (orientacyjne)

Poniżej orientacyjne ceny katalogowe (USD, bez rabatów partnerskich). Realne stawki zależą od umowy enterprise, kanału i wolumenu — traktuj to jako punkt odniesienia do budżetu, nie ofertę handlową.

Oracle Database Enterprise Edition

PozycjaCena katalogowa (USD)Orientacyjnie (PLN)
Oracle EE — licencja rdzeniowa (Processor License)~23 750 / rdzeń~95 000 zł
Named User Plus (Oracle EE)~950 / użytkownik~3 800 zł
Real Application Clusters (RAC) — dodatek~11 500 / rdzeń~46 000 zł
Active Data Guard — dodatek~11 500 / rdzeń~46 000 zł
Technical Support (rocznie, ~22% ceny licencji)zależy od licencjonowanych rdzeniwymagany do patchy i aktualizacji
ℹ️

Oracle w cenniku podaje stawkę jako Processor License (~47 500 USD) — to jednostka licencyjna wyliczana z rdzeni, a nie cena za socket CPU. Przy współczynniku 0,5 dla procesorów x86-64 (Intel Xeon, AMD EPYC) jedna Processor License obejmuje 2 fizyczne rdzenie (~23 750 USD/rdzeń). Minimum to 2 Processor License na serwer. Szczegółowy opis Technical Support — w sekcji Oracle Database Enterprise Edition.

SQL Server Enterprise

PozycjaCena katalogowa (USD)Orientacyjnie (PLN)
SQL Server Enterprise — 2 rdzenie (pakiet)~15 123~60 500 zł
SQL Server Enterprise — 1 rdzeń (dodatkowy)~7 562~30 250 zł
Software Assurance (rocznie, ~25% ceny licencji)zależy od licencjonowanych rdzeniwymagane m.in. do unlimited virtualization

Szczegółowy opis Software Assurance (unlimited virtualization, mobilność licencji, scenariusze HA) — w sekcji SQL Server Enterprise. Roczny odpowiednik u Oracle — Technical Support Subscription.

ℹ️

Ceny orientacyjne (~4 zł/USD). Oracle publikuje cennik w USD; Microsoft — w USD/EUR w zależności od kanału. Subskrypcje chmurowe (Oracle Cloud BYOL, Azure SQL, SQL na VM w Azure) to alternatywa o innym modelu kosztowym — warto porównać TCO na 3–5 lat.

// 07 · Rekomendacja

Strategie optymalizacji i rekomendacje

💡

Rekomendacja Proxmox Migracje: do węzłów dedykowanych pod bazy danych enterprise (Oracle EE, SQL Server Enterprise) rekomendujemy procesor AMD EPYC 9175F — 16 rdzeni wysokotaktowanych z wysoką wydajnością na rdzeń i minimalną liczbą rdzeni do licencjonowania.

  • Oracle EE na Proxmox → dedykowany węzeł z możliwie małą liczbą rdzeni; unikaj stawiania Oracle na gęstym 128-rdzeniowym hoście współdzielonym z setkami VM.
  • SQL Server EE — wiele instancji → licencjonowanie całego hosta per-core (+ SA jeśli potrzebna mobilność HA).
  • SQL Server EE — 1–2 małe instancje → licencja per-VM (min. 4 rdzenie; od SQL Server 2022 wymaga SA lub subskrypcji).
  • Klaster HA (SQL) → jedna VM z failoverem: 32 rdzenie + SA (mobilność między węzłami) zamiast podwójnego licencjonowania obu hostów; wiele VM równolegle → każdy aktywny węzeł w pełni licencjonowany. Oracle → dedykowane węzły z affinity.
  • Rozważ PostgreSQL / Oracle Standard Edition 2 tam, gdzie wymagania biznesowe na to pozwalają — różnica TCO bywa wielokrotna.
ℹ️

Modele i ceny Oracle oraz Microsoft zmieniają się w czasie — konkretny scenariusz, umowy i aktualne stawki potwierdź u autoryzowanego partnera. Powyższe to reguły ogólne i ceny orientacyjne, nie porada handlowa, prawna ani podatkowa.

Powiązane artykuły: Licencjonowanie Windows Server, Licencjonowanie RHEL, AMD EPYC 9175F dla baz danych.

Zaplanujemy licencje DB w Twoim klastrze Proxmox

Policzymy wymagany zakres licencji Oracle EE i SQL Server Enterprise — z uwzględnieniem HA, affinity i optymalnej architektury węzłów — zanim zatwierdzisz migrację z VMware.

⚡ Bezpłatna konsultacja → Licencjonowanie Windows Server
// Analysis for decision-makers // Oracle · SQL Server · Licensing

Oracle EE and SQL Server Enterprise
licensing on Proxmox VE

Moving from VMware to Proxmox cuts hypervisor cost — but Oracle Database Enterprise Edition and Microsoft SQL Server Enterprise are still licensed against physical infrastructure, not a VM's vCPU count. On a dense 64- or 128-core host, a single database can require licenses for the entire server, just as with VMware. We explain both vendors' models on Proxmox VE, the soft-partitioning trap, and strategies that genuinely lower the bill.

// 01 · Context

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.

host
Licensing counts
physical cores
soft
KVM/Proxmox =
soft partitioning (Oracle)
plan
License architecture
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.

// 02 · Oracle

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 typeTechnologies Oracle recognizesProxmox / KVM
Hard partitioningOracle VM Server, selected LPAR/DRP, Solaris Zones (with limits)Not applicable
Soft partitioningVMware, Hyper-V, Xen, KVM, containers without hard partitioningYes — 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).
  • Minimum: 2 Processor License units per server (do not confuse 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 usually bundled with the license purchase; subsequent years cost about 22% of net license price per year (list rate — with ULA or large volumes it can be lower, e.g. 8–15%). 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 node16 × ~$23,750 ≈ $380,000~$83,600~$630,800
Dedicated 32-core node32 × ~$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 32 licenses 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 core license (~$11,500/core) on top of EE on the standby. Standby with read access for users (ADG query mode, logical standby for reports) requires full EE + ADG on standby. 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.

// 03 · Microsoft

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.

ModelWhat you licenseWhen it makes sense on Proxmox
Per-core (single VM)cores assigned to the VM (min. 4 cores per VM, min. 4 cores per physical processor)1–2 SQL instances on a node, few VM cores
Per-core (whole host)all physical cores on the servermany SQL VMs on one node — with SA: unlimited VMs; without SA: max as many VMs as core licenses
Enterprise + Software Assuranceper-core license with unlimited virtualization rightsdense 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.

SQL Server also requires a Windows Server guest OS license — see Windows Server licensing on Proxmox VE.

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 ≈ $15,123~$3,781~$26,465
Whole 16-core host16 × ~$7,562 ≈ $120,992~$30,248~$211,736
Whole 32-core host32 × ~$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 instance on a server dedicated solely to disaster recovery, when Microsoft terms are met (instance does not serve production traffic).
⚠️

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 HA replica (synchronous, auto-failover) + 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,000four 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. Remember separate Windows Server licensing for each guest VM.

// 04 · Proxmox

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.

// 05 · Existing licenses

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 scenarioReusable on Proxmox?Watch out for
SQL EE on VMware VM (per-core per VM)Yes — same core licensesOn 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 modelWith 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 serverYes — after migration to VMMove 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 AssuranceYes, but limited mobilityMoving licenses between hosts (e.g. HA failover) — only every 90 days. Plan dedicated DB nodes or renew SA before migration.
SPLA / hoster subscription via partnerDepends on contractLicenses 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 model and any SA requirements. A valid Windows Server guest license is also required.

Oracle Database Enterprise Edition — VMware, bare metal → Proxmox

Source scenarioReusable on Proxmox?Watch out for
Oracle EE — Processor License (perpetual / subscription)Yes — licenses are portableOracle 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 serverYes — after P2V to ProxmoxIf 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 modelVMware 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 agreementCheck 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) licensesYes — users remainNUP 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 / 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.

// 06 · Pricing

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

ItemCatalog 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~$11,500 / 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). The minimum is 2 Processor License units per server. Full Technical Support details — in Oracle Database Enterprise Edition.

SQL Server Enterprise

ItemCatalog price (USD)
SQL Server Enterprise — 2-core pack~$15,123
SQL Server Enterprise — 1 additional core~$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.

ℹ️

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.

// 07 · Recommendation

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 instancesper-VM licensing (min. 4 cores; from SQL Server 2022 requires SA or subscription).
  • 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