Migracja Oracle do PostgreSQL na AWS - przewodnik techniczny z dofinansowaniem MAP

Ten artykuł jest skierowany do organizacji średniej wielkości, dużych firm i sektora publicznego, czyli podmiotów z wieloma instancjami Oracle, złożoną logiką w PL/SQL i potrzebą migracji bez przestojów. Jeśli szukasz ogólnego przewodnika po migracji do AWS (nie tylko bazy danych), zobacz kompletny przewodnik migracji do chmury AWS.

Dlaczego firmy odchodzą od Oracle na PostgreSQL

Koszty licencji Oracle – rzeczywista skala problemu

Przy dwóch takich serwerach (typowa konfiguracja dla średniej firmy z HA) to ponad $400 000 rocznie – samych licencji, bez hardware, DBA i kolokacji. Aurora PostgreSQL db.r6g.2xlarge (8 vCPU, 64 GB RAM, Multi-AZ) oferuje porównywalną wydajność za ~$1 400/mies. = $16 800/rok. Brak limitu użytkowników. Brak ekspozycji na audyt.

Audyt Oracle LMS – główny wyzwalacz decyzji

Audyty Oracle License Management Services są bezwzględne i coraz częstsze. Szczególnie narażone są firmy, które:

• Zwirtualizowały środowisko na VMware bez wykupienia licencji na pełną szafę serwerową
• Uruchomiły Oracle Standard Edition na serwerach z >2 socketami
• Wdrożyły RAC lub Data Guard bez odpowiedniej opcji licencyjnej

Typowy efekt? Żądanie dopłaty $500K–$2M+ za „niezgodne użycie”. Widzieliśmy to u klientów z sektora bankowego – sześcio- i siedmiocyfrowe roszczenia po tym, jak VMware sprawl wymknął się spod kontroli. Instytucje publiczne są narażone w równym stopniu, szczególnie gdy Oracle forsuje audyt przed odnowieniem kontraktu.

Migracja na PostgreSQL eliminuje dźwignię audytową Oracle. Nie ma licencji – nie ma z czym być niezgodnym.

Uzależnienie od dostawcy i brak elastyczności

Oracle licencjonuje per-procesor, co oznacza, że każde skalowanie w górę podwaja koszty z dnia na dzień. Nie ma modelu rozliczeń za faktyczne użycie (Aurora rozlicza per-sekunda). Oracle na AWS nadal wymaga BYOL – przenosisz się do chmury, ale problem licencyjny jedzie z Tobą. Do tego brak natywnej integracji z IAM, CloudWatch czy Secrets Manager bez dodatkowych warstw konfiguracyjnych.

PostgreSQL – dlaczego akurat teraz

PostgreSQL dojrzał dramatycznie. Wersja 16 natywnie obsługuje partycjonowanie tabel, zapytania równoległe, replikację logiczną i JSON/JSONB – możliwości, które kiedyś stanowiły przewagę Oracle.

Na AWS konkretnie:

• Aurora PostgreSQL dostarcza 3-5× przepustowość standardowego PostgreSQL z automatycznym przełączaniem awaryjnym i do 15 replikami odczytu. To w pełni zarządzana usługa – łatki, kopie zapasowe i wysoka dostępność są obsługiwane za Ciebie.
• Natywna integracja z ekosystemem – uwierzytelnianie bazy przez IAM, automatyczna rotacja sekretów przez Secrets Manager, observability na poziomie zapytań przez Performance Insights
• Zero kosztów licencyjnych – płacisz za moc obliczeniową i storage, nic więcej

Dla branż regulowanych (KNF w Polsce, BaFin w Niemczech, FCA w UK) certyfikaty Aurora (ISO 27001, SOC 2, PCI DSS, C5 dla rynku DACH) oznaczają, że nie zamieniasz zgodności Oracle na lukę gdzie indziej.

Oracle vs PostgreSQL – kluczowe różnice techniczne

Typy danych – mapowanie

PL/SQL vs PL/pgSQL – kluczowe różnice składniowe

Funkcjonalności Oracle bez bezpośredniego odpowiednika

Migracja krok po kroku – proces 8-fazowy

Narzędzia AWS do migracji Oracle → PostgreSQL

AWS Schema Conversion Tool (SCT)

SCT analizuje schemat Oracle i generuje odpowiedniki w PostgreSQL – DDL tabel plus procedury PL/pgSQL. Traktuj go jako pierwszy przebieg: radzi sobie z prostymi konwersjami, żeby Twoi inżynierowie mogli skupić się na trudnych przypadkach.

Generuje raport oceny z kolorowym oznaczeniem: zielony to konwersja automatyczna, żółty wymaga drobnych poprawek, czerwony oznacza, że ktoś musi usiąść i przemyśleć logikę. Z naszego doświadczenia 60-85% obiektów ląduje w zielonej lub żółtej kategorii.

Gdzie SCT zawodzi: pakiety PL/SQL konwertuje „płasko” (tracisz enkapsulację), hierarchie CONNECT BY wymagają ręcznego przepisania na CTE, a niektóre funkcje analityczne specyficzne dla Oracle potrzebują ludzkiego oka. Ale za tę cenę (bezpłatny – część zestawu narzędzi AWS) to obowiązkowy punkt wyjścia.

AWS Database Migration Service (DMS)

DMS przenosi właściwe dane. Obsługuje jednorazowe pełne ładowanie i – co ważniejsze – ciągłą replikację przez CDC (Change Data Capture). To dzięki CDC osiągasz minimalny przestój przy finalnym przełączeniu.

Kilka rzeczy do skonfigurowania po stronie Oracle: supplemental logging musi być włączony, potrzebujesz dostępu przez Binary Reader lub LogMiner, a instancja replikacyjna powinna mieć mniej więcej 1 vCPU na 50 GB ładowanych danych (lub na 100 tabel pod CDC).

Po stronie PostgreSQL: slot replikacji logicznej dla konfiguracji Multi-AZ i session_replication_role = replica podczas początkowego ładowania, żeby wyzwalacze nie wchodziły w drogę.

Koszt operacyjny jest umiarkowany – mniej więcej $0.018/h za vCPU instancji replikacyjnej plus transfer danych.

ora2pg – opcja open-source

Narzędzie napisane w Perl, które obsługuje konwersję schematu i danych bez jakiejkolwiek zależności od AWS. Przydaje się dla mniejszych baz, środowisk docelowych on-premise, albo sytuacji gdzie chcesz pełną kontrolę nad każdą decyzją konwersyjną.

Mniej odpowiedni dla dużych organizacji z setkami procedur składowanych (heurystyki SCT sprawdzają się lepiej na dużą skalę) i nie obsługuje CDC – więc do replikacji na żywo i tak potrzebujesz DMS.

Kiedy NIE używać:

• Duże organizacje z setkami procedur składowanych (SCT ma lepsze heurystyki)
• Gdy potrzebujesz CDC (ora2pg tego nie obsługuje – użyj DMS)

Jak AWS MAP finansuje migrację Oracle → PostgreSQL

Co to jest AWS Migration Acceleration Program (MAP)

MAP to program dofinansowania AWS skierowany do organizacji migrujących z on-premise lub konkurencyjnych platform. Obejmuje trzy fazy:

MAP dla migracji Oracle – dedykowana ścieżka

AWS prowadzi dedykowaną ścieżkę MAP dla migracji baz danych Oracle z budżetem wyższym niż standardowy program. To nie jest szeroko reklamowane, ale istnieje, bo AWS ma strategiczny interes w przeciąganiu workload z Oracle na swoją platformę.

Co ścieżka Oracle dodaje ponad standardowy MAP:

• Dodatkowe kredyty na narzędzia, wydłużone testy i podnoszenie kompetencji zespołu
• Wyższe pułapy dofinansowania dla złożonych środowisk z wieloma bazami
• Bonusy „okna szans” (Windows of Opportunity) gdy migrujesz przed datą odnowienia licencji Oracle – bo odnowienie to punkt dźwigni i AWS o tym wie

Kto się kwalifikuje

Poprzeczka nie jest tak wysoko, jak mogłoby się wydawać:

• Aktywne środowisko Oracle (on-premise, kolokacja lub EC2 z BYOL)
• Minimalna wielkość projektu: typowo od $50K wartości zaangażowania partnera (to wyklucza trywialne jednoinstancyjne migracje, ale większość scenariuszy korporacyjnych przechodzi swobodnie)
• Cel musi być natywną usługą AWS (Aurora PostgreSQL lub RDS PostgreSQL)
• Potrzebujesz certyfikowanego partnera MAP do złożenia wniosku. My zajmujemy się tym od A do Z.

Ile realnie można uzyskać

Poza pokryciem honorarium partnera typowo otrzymujesz 1-3 miesiące kredytów AWS na infrastrukturę docelową, dostęp do AWS Solution Architects na czas projektu i (przy największych migracjach) bezpośrednie wsparcie AWS Professional Services.

Proces kwalifikacji – co potrzebujemy od Ciebie

1. Inwentaryzacja baz Oracle – ile instancji, jakie rozmiary, orientacyjna liczba procedur
2. Zarys uzasadnienia biznesowego – choćby na serwetce: oszczędności licencyjne vs koszt migracji
3. Data odnowienia licencji Oracle – to decyduje o pilności i może odblokować dodatkowe dofinansowanie
4. Rozmowa – składamy wniosek MAP w Twoim imieniu i prowadzimy cały cykl życia dofinansowania do zakończenia projektu

Najczęstsze wyzwania migracji Oracle → PostgreSQL

1. Procedury składowane z logiką biznesową

Problem: Bazy Oracle w dużych organizacjach mają setki procedur PL/SQL implementujących logikę biznesową – kalkulacje, walidacje, workflow. SCT konwertuje 60-70% automatycznie. Reszta wymaga ludzkiej głowy.

Jak to rozwiązujemy:

Zaczynamy od priorytetyzacji. Raport Oracle AWR pokazuje, które procedury są faktycznie wywoływane w produkcji – często połowa istniejących procedur to martwy kod.

Kluczowa zasada: przepisujemy, nie tłumaczymy. PostgreSQL ma lepsze funkcje okna, CTE i operacje na tablicach – wykorzystujemy je zamiast naśladować wzorce Oracle, które powstały z ograniczeń tamtego silnika.

Dla okresu przejściowego działa rozszerzenie orafce – tymczasowy pomost emulujący NVL2, DECODE i inne funkcje specyficzne dla Oracle. Docelowo chcesz się tego pozbyć, ale na start zmniejsza liczbę zmian wymaganych jednocześnie.

Każda skonwertowana procedura przechodzi test z wynikami Oracle jako wartość referencyjna. Bez wyjątków.

Wsparcie AI (Amazon Q, Copilot): Modele językowe konwertują PL/SQL → PL/pgSQL z kontekstem schematu docelowego. Inżynier weryfikuje i poprawia wynik zamiast pisać od zera. W naszych projektach redukuje to nakład na konwersję ręczną o 40-60% i eliminuje typowe błędy składniowe, które ludzie popełniają przy ręcznym przepisywaniu.

2. Wydajność po migracji

Problem: Zapytania, które działały w 50ms na Oracle, potrafią trwać 5s na PostgreSQL. Inny optymalizator, inne statystyki, inne indeksy.

Rozwiązanie:

• pg_stat_statements – identyfikacja najwolniejszych zapytań
• EXPLAIN (ANALYZE, BUFFERS) – porównanie planów wykonania
• Dodatkowe indeksy: PostgreSQL korzysta z indeksów częściowych, indeksów na wyrażeniach, indeksów pokrywających
• Dostrojenie random_page_cost (dla SSD: 1.1 zamiast domyślnego 4.0)
• Pula połączeń: PgBouncer w trybie transakcyjnym (Oracle obsługuje tysiące połączeń natywnie, PostgreSQL potrzebuje poolera)

3. Funkcje Oracle bez bezpośredniego odpowiednika

Problem: CONNECT BY, MODEL clause, MERGE z zaawansowaną logiką, transakcje autonomiczne.

Rozwiązanie per funkcja:

4. Zmiana mentalności zespołu DBA

Problem: Zespoły przyzwyczajone do Oracle (AWR, ASH, Enterprise Manager) muszą nauczyć się nowego zestawu narzędzi.

Rozwiązanie:

• AWS Performance Insights = odpowiednik Oracle ASH (Active Session History)
• pg_stat_statements = odpowiednik Oracle V$SQL
• pgBadger = odpowiednik raportu Oracle AWR
• Szkolenie 2-3 dniowe dla zespołu DBA (pokrywane z budżetu MAP)

5. Integracje zewnętrzne

Problem: Systemy raportowe (BI), ETL (Informatica, SSIS, Talend) i inne aplikacje łączą się bezpośrednio do Oracle.

Rozwiązanie:

• Faza assessment identyfikuje WSZYSTKIE połączenia do Oracle (netstat, AWR, audyt Oracle)
• Plan przełączenia obejmuje przełączenie każdej integracji
• Praca równoległa: DMS utrzymuje Oracle w trybie read-only jako zabezpieczenie dla systemów, które nie mogą się przełączyć natychmiast

Timeline i koszty migracji Oracle → PostgreSQL

Według rozmiaru bazy i złożoności

Powyższe koszty uwzględniają wsparcie AI w konwersji kodu (Amazon Q Developer, Copilot). Bez wsparcia AI konwersja ręczna zajmowałaby o 40-60% dłużej – szczególnie widoczne w scenariuszach „Złożony” i „Enterprise”, gdzie większość budżetu to praca nad procedurami składowanymi.

Co wpływa na timeline

Oszczędności po migracji – zwrot z inwestycji

Typowa firma z 2 instancjami Oracle EE (2-socket każda):

Przy koszcie migracji $150 000 (po MAP) – zwrot z inwestycji w 4 miesiące.

Sektor publiczny – specyficzne aspekty

Dlaczego instytucje publiczne migrują z Oracle

• Zamówienia publiczne: Kierunek open-source redukuje uzależnienie od dostawcy (wymóg wielu przetargów)
• Audyty NIK: Kwestionowanie wydatków na licencje komercyjne, gdy istnieją alternatywy open-source
• NIS2 / KSC: Wymogi cyberbezpieczeństwa łatwiej spełnić na w pełni zarządzanej usłudze (Aurora) niż samodzielnie utrzymywanym Oracle
• Budżetowanie roczne: Model rozliczania za użycie w AWS lepiej pasuje do rocznego cyklu budżetowego niż wieloletnie licencje Oracle

AWS w sektorze publicznym PL

• Najbliższe regiony AWS: eu-central-1 (Frankfurt) i eu-west-1 (Irlandia) – opóźnienie do Polski <30ms
• Zgodność z RODO – dane w UE
• AWS Artifact – certyfikaty zgodności (ISO 27001, SOC 2, C5)
• Umowy ramowe – możliwość zakupu AWS przez dystrybutorów z umów ramowych

Najczęściej zadawane pytania

Następne kroki – bezpłatna ocena migracji

Każda migracja Oracle → PostgreSQL zaczyna się od oceny środowiska. Analizujemy Twoje bazy (schematy, złożoność PL/SQL, wolumeny danych, punkty integracji) i wracamy z konkretem:

1. Raport konwersji SCT – co konwertuje się automatycznie, co wymaga pracy inżynieryjnej
2. Realistyczny kosztorys i harmonogram – konkretne widełki, w tym projekcja dofinansowania MAP
3. Rekomendacja architektury – Aurora vs RDS, Multi-AZ, repliki odczytu, strategia poolingu
4. Plan przełączenia – jak przejść z minimalnym wpływem na biznes

Realizowaliśmy wyjścia z Oracle dla firm z sektora finansowego, ubezpieczeniowego i administracji publicznej w Polsce. Niezależnie czy zbliża się odnowienie licencji za sześć miesięcy, czy na biurku leży już pismo z audytu LMS – pierwszy krok to zrozumienie, z czym mamy do czynienia.

Rozważasz odejście od Oracle?

Umów bezpłatną 30-minutową rozmowę. Wstępnie ocenimy złożoność migracji i sprawdzimy, czy Twój projekt kwalifikuje się do dofinansowania AWS MAP (typowo 70-80% kosztów).

Umów ocenę migracji