Jak wykorzystać bazy danych w chmurze w projektach Java bez przepalania budżetu

Gdzie zjada cię budżet? Prawdziwy problem z bazami w chmurze przy Javie

Najczęstszy scenariusz: aplikacja Java w chmurze działa stabilnie, użytkownicy są zadowoleni, logi czyste – a po pierwszym pełnym miesiącu przychodzi faktura, na której baza danych kosztuje więcej niż cała reszta infrastruktury razem wzięta. EC2/GCE/VMs – tanio. Load balancer – akceptowalnie. Storage – umiarkowanie. A baza w chmurze? Kilka razy więcej niż planowany budżet.

Powód jest zwykle ten sam: aplikacje Java są wyjątkowo „rozmowne” z bazą, zwłaszcza gdy używają Spring Boota i ORM-a (Hibernate, JPA) bez większej dyscypliny. Każde niewinne wywołanie endpointu może generować dziesiątki zapytań, a każdy mikroserwis dorzuca kolejne stałe obciążenie połączeniami. Na tradycyjnym serwerze z bazą tego aż tak nie widać, bo rachunek jest „stały”. W chmurze każda zła decyzja ma cenę wprost na fakturze.

Do tego dochodzi drugi klasyk: ktoś wybiera w panelu chmurowym bazę „taką, jaką znamy z korporacji”: duża instancja, szybkie SSD, pełne HA multi-AZ, częste backupy, replikacja do drugiego regionu – wszystko od razu. A aplikacja to dopiero MVP z kilkoma użytkownikami testowymi. Efekt: architektura klasy enterprise dla budżetu klasy startup.

Mini-scenariusz: migracja monolitu Spring Boot i nagły skok rachunku

Typowy obrazek. Zespół ma monolit w Spring Boot, bazę PostgreSQL on-premise lub na tanim hostingu. System działa, ale skalowanie pionowe jest męczące, więc zapada decyzja: przenosimy do chmury, na przykład na AWS.

Plan jest prosty:

• aplikacja Java → ECS/EKS/EC2,
• baza → Amazon RDS for PostgreSQL w konfiguracji „bezpiecznej”: multi-AZ, sporo RAM, domyślny storage,
• reszta – według poradników z internetu.

Aplikacja po migracji:

• ma kilka instancji Spring Boot w autoscalingu,
• każda instancja ma swój connection pool z HikariCP, domyślnie dziesiątki połączeń,
• Hibernate generuje sporo zapytań (czasem N+1, bo nikt nie przyjrzał się logom SQL).

RDS jest za duży jak na realne obciążenie, storage SSD jest ustawiony hojnie, backupy codziennie, trzymane długo. CPU na bazie ledwo drgnie powyżej kilku procent, ale koszt compute + storage + I/O + backupów jest już bardzo wyraźny. Do tego każde środowisko (dev, test, staging) ma osobną, „taką samą, tylko trochę mniejszą” bazę – i rachunek rośnie.

Najbardziej zdradliwe objawy przepalania budżetu

Sygnały ostrzegawcze zwykle nie są związane z wydajnością, tylko z metrykami kosztów. Kilka typowych:

• Niskie CPU na instancji bazy, ale wysoki koszt miesięczny – instancja jest po prostu za duża, usługodawca liczy za rezerwację mocy, nie za realne użycie CPU.
• Duży koszt I/O/IOPS przy w miarę stabilnym ruchu – wzorce zapytań z Javy generują mnóstwo odczytów i zapisów (np. częste odświeżanie danych, brak cache, N+1 queries).
• Rosnące koszty backupów i snapshotów – automatyczne backupy trwają długo i trzymane są zbyt długo, a baza ma sporo historycznych danych, których nikt w praktyce nie używa.
• Środowiska nieprodukcyjne z pełnym HA – dev, test czy staging mają włączone multi-AZ, replikację i wysoką klasę storage, mimo że awaria tych środowisk jest w zasadzie bezbolesna.

Największą pułapką jest bezrefleksyjne kopiowanie konfiguracji enterprise do małego lub średniego projektu. Bez zdefiniowanych wymagań niefunkcjonalnych (SLA, RPO, RTO, docelowy ruch) naturalnym odruchem jest „ustawmy wszystko jak w dużych systemach, będzie bezpiecznie”. Niestety, w chmurze oznacza to po prostu „ustawmy wszystko jak w dużych systemach, będzie drogo”.

Skąd się to bierze? Przyczyny drogich baz w chmurze dla projektów Java

Techniczne źródła kosztów po stronie chmury

Koszt bazy danych w chmurze nie jest jednym numerkiem. Składa się z kilku głównych komponentów, które w różnych kombinacjach potrafią nieprzyjemnie zaskoczyć:

• Compute – rozmiar instancji bazy (vCPU, RAM),
• Storage – typ (SSD, HDD, provisioned IOPS) i rozmiar,
• I/O / IOPS – liczba operacji odczytu/zapisu, czasem też przepustowość,
• Backupy i snapshoty – ilość danych x czas przechowywania,
• Replikacja i HA – dodatkowe instancje w innych strefach/regionach,
• Ruch sieciowy – zwłaszcza między regionami i poza chmurę,
• Licencje – gdy wybierasz komercyjne silniki lub specjalne edycje.

Java generuje wiele krótkich połączeń i zapytań, więc każdy z tych elementów dostaje swoją porcję obciążenia. Jeśli instancja jest przewymiarowana, płacisz głównie za compute. Jeśli aplikacja robi dużo małych odczytów i zapisów (np. zapisywanie logów lub zdarzeń do tej samej bazy), rachunek skacze na I/O.

Często największym cichym zabójcą budżetu jest storage SSD z wysokim poziomem provisioned IOPS. Konfiguracje „domyślne” lub „rekomendowane” w panelu są projektowane z myślą o bezpieczeństwie i wydajności, a nie o minimalizacji kosztów. Kilkaset gigabajtów SSD z wysokim IOPS może dla małego projektu być przerostem formy nad treścią – ale i tak będzie sumiennie rozliczane co miesiąc.

Do tego dochodzą koszty HA. Multi-AZ oznacza, że w praktyce utrzymujesz dwie instancje bazy (aktywną i pasywną), a w niektórych modelach – więcej replik. Każda replika ma własne storage, własne backupy. Przy dużych bazach różnica w rachunku między single-AZ a multi-AZ potrafi być brutalna, szczególnie na etapie MVP, gdy ryzyko biznesowe dłuższej awarii jest niskie.

Wpływ architektury aplikacji Java

Architektura aplikacji ma bezpośrednie przełożenie na to, jak drogo kosztuje baza w chmurze. Java, Spring Boot i mikroserwisy mają swoje specyficzne wzorce, które potrafią zabić kosztowo nawet dobrze dobraną konfigurację bazy.

Najważniejsze mechanizmy:

• Monolit vs mikroserwisy – monolit zwykle ma kilka instancji aplikacji → kilka pooli połączeń. Mikroserwisów jest więcej, więc i pul połączeń jest więcej. Każdy serwis „pilnuje” swoich połączeń, a baza patrzy na to jak na stałe obciążenie.
• N+1 queries i „czatowanie” z bazą – ORM w Javie lubi generować wiele drobnych zapytań zamiast jednego sensownego joinu lub batcha. Każde z tych zapytań to operacja I/O, która w chmurze jest konkretną pozycją w rachunku.
• Długotrwałe transakcje – gdy logika biznesowa trzyma transakcję otwartą przez długi czas (np. łączy kilka kosztownych zapytań, czeka na zewnętrzne API), utrzymuje zasoby bazy w użyciu, co może prowadzić do retry po stronie aplikacji i dodatkowych zapytań.

Do tego dochodzą detale związane z connection poolingiem. Jeśli każda instancja Spring Boot ma HikariCP ustawione na 30–50 połączeń, a instancji jest dynamicznie 10–15, to baza może mieć w piku nawet kilkaset aktywnych połączeń. Nie dlatego, że tyle potrzeba, ale dlatego, że nikt nie policzył, ile naprawdę jest potrzebne przy danym QPS aplikacji.

Efekt? Trzeba wybrać większą instancję bazy (więcej RAM, więcej połączeń), niż wynikałoby to z realnego ruchu użytkowników. Po prostu konfiguracja Javy wymusza przewymiarowanie bazy, bo w przeciwnym razie pojawiają się błędy „too many connections” lub rosną czasy odpowiedzi.

Decyzje organizacyjne „na wszelki wypadek”

Technika to jedno, ale równie dużo kosztów generują decyzje organizacyjne, podjęte często z najlepszych chęci:

• Overprovisioning – lepiej dajmy większą instancję, bo „może będziemy mieli skok ruchu”. Problem w tym, że skok może nigdy nie nadejść, a budżet jest przepalany co miesiąc.
• Wiele środowisk z pełną kopią konfiguracji – dev, test, staging, preprod, demo – wszystkie z własną bazą, często z włączonym multi-AZ i automatycznymi backupami.
• Brak wymagań niefunkcjonalnych – jeśli nikt nie ustali, jakie RPO/RTO i SLA są akceptowalne, to najprościej jest „dać wszystko na maksimum” i uznać, że „będzie dobrze”. Dla budżetu będzie źle.

Firmy, które dopiero poznają chmurę, często zakładają, że skoro na starcie „to tylko kilkadziesiąt dolarów różnicy”, to nie ma o co walczyć. Problem zaczyna się, gdy projekt rośnie, danych przybywa, środowisk się mnoży, a różnice jednostkowe zamieniają się w stały i wysoki miesięczny koszt.

Jakie opcje w ogóle masz? Mapowanie typów baz w chmurze na projekty Java

Bazy zarządzane (RDS, Cloud SQL, Azure Database) – kiedy mają sens

Zarządzane relacyjne bazy danych (DBaaS) – typu Amazon RDS, Google Cloud SQL czy Azure Database – są kuszące, bo zdejmują z zespołu dużo obowiązków: patchowanie, backupy, podstawowe HA, monitoring zdrowia instancji. Płacisz więcej za wygodę operacyjną, ale mniej za czas adminów i DevOpsów.

Dla typowych projektów Java to często najlepszy punkt startowy:

• monolit Spring Boot z relacyjnym modelem danych,
• kilka mikroserwisów biznesowych z umiarkowanym ruchem,
• systemy wewnętrzne, które wymagają sensownego SLA, ale nie są ekstremalnie krytyczne.

Przy dobrze dobranej klasie instancji i rozsądnych parametrach HA/backupów, zarządzane bazy pozwalają szybciej ruszyć z projektem, bo zespół nie traci miesięcy na dopieszczanie klastrów na Kubernetesie. Kosztowo zyskujesz przewidywalność – cennik jest jasny, a większość obowiązków utrzymaniowych jest po stronie dostawcy chmury.

Kłopot zaczyna się, gdy korzysta się z tych usług „na auto-pilocie”:

• włącza się multi-AZ „bo checkbox kusi”,
• zostawia się domyślne retention backupów na poziomie kilkudziesięciu dni,
• ustawia się większą klasę instancji „na zapas”,
• daje się więcej storage, niż wynika z realnej ilości danych.

Dlatego zarządzane bazy mają sens, gdy świadomie kontrolujesz ich konfigurację. Sam fakt, że to „managed service”, nie sprawi, że rachunek będzie rozsądny.

Bazy NoSQL zarządzane (dokumentowe, klucz-wartość)

Usługi typu dokumentowe (np. Firestore, DocumentDB, Cosmos DB) czy klucz-wartość (np. DynamoDB, Cloud Bigtable w określonych scenariuszach) mogą obniżyć koszt warstwy danych, ale tylko wtedy, gdy model danych i wzorce dostępu do nich są proste i przewidywalne.

W uproszczeniu:

• Jeśli Java potrzebuje szybkich odczytów po kluczu (np. sesje, tokeny, proste konfiguracje), to baza klucz-wartość bywa tańsza niż relacyjna, bo nie trzeba utrzymywać skomplikowanej instancji z całą otoczką.
• Jeśli dane mają naturalny kształt dokumentów (np. profil użytkownika z osadzonymi kolekcjami), dokumentowa baza NoSQL pozwala uniknąć kosztownych joinów i wielu tabel.

Ryzyka pojawiają się wtedy, gdy:

• model danych jest sztucznie „na siłę” wciskany w NoSQL, co powoduje konieczność wykonywania wielu operacji odczytu/zapisu per jeden request w Javie,
• aplikacja nie kontroluje wielkości dokumentów i liczby odczytów, więc rośnie koszt operacji i transferu,
• ktoś zakłada, że „NoSQL jest zawsze tańsze”, a potem okazuje się, że przy złożonych zapytaniach i nieoptymalnych partycjach jest odwrotnie.

Integracja z Javą (Spring Data, oficjalne SDK) jest zazwyczaj dojrzała, ale trzeba dbać o to, żeby najczęstsze ścieżki (hot paths) były zaprojektowane pod minimalną liczbę operacji na bazie. Typowa strategia to: dane transakcyjne i złożone relacje trzymać w relacyjnej bazie zarządzanej, a wysoce cache’owalne dane i sesje – w NoSQL lub cache typu Redis.

Samodzielna baza na VM/Kubernetes – kiedy ma to sens

Postawienie bazy samodzielnie na maszynie wirtualnej (EC2, Compute Engine, VM) albo w klastrze Kubernetes kusi niższym kosztem jednostkowym: płacisz za surowe zasoby (CPU, RAM, dysk), bez narzutu „usługi zarządzanej”. W zamian przejmujesz na siebie odpowiedzialność za:

…patchowanie, backupy, konfigurację replik, monitoring, skalowanie w pionie/poziomie, procedury odtwarzania po awarii i testy tych procedur.

Ekonomicznie ma to sens głównie w dwóch sytuacjach. Po pierwsze, gdy masz już zespół z kompetencjami DBA/DevOps i realnie są w stanie utrzymać tę bazę bez odkładania tematów „na później”. Po drugie, gdy skala jest na tyle duża, że narzut usług zarządzanych zabija budżet, a jednocześnie aplikacja Java ma przewidywalne wzorce ruchu. Klasyczny przykład: duża platforma B2B, gdzie liczba klientów i zapytań jest stabilna, a każdy procent oszczędności robi różnicę w rachunku.

Ryzyko pojawia się, gdy „samodzielna baza” jest wyborem domyślnym tylko dlatego, że ktoś czuje się pewnie z instalacją Postgresa na VM-ce. Koszty wychodzą wtedy bokiem: nie ma automatycznych kopii, test restore’u nigdy nie został zrobiony, a pierwszy poważniejszy incydent kończy się wielogodzinną przerwą. Z perspektywy projektu Java oznacza to time-outy, kolejki retry, rosnącą latencję i w końcu paniczne skalowanie wszystkiego, byle tylko „przepchnąć” ruch.

Trzeba też liczyć się z tym, że każda decyzja architektoniczna po stronie Javy (liczba instancji, strategia pooli połączeń, batch processing nocą) bezpośrednio obciąża bazę. Przy DBaaS część problemów „wygładzają” mechanizmy dostawcy. Przy własnej instancji to ty konfigurujesz RAID, IOPS, parametry kernela, autovacuum, limity połączeń, alerty – i to ty dostajesz po kieszeni, gdy coś się rozjedzie i trzeba awaryjnie dorzucać zasoby.

Jeśli projekt dopiero startuje, a wymogi SLA nie są jeszcze betonem, częściej opłaca się zacząć od zarządzonej bazy, a dopiero przy kolejnej większej iteracji (gdy profil ruchu się ustabilizuje) rozważyć migrację na własną infrastrukturę. Dla wielu systemów produkcyjnych ten „drugi krok” nigdy nie nadchodzi – bo prostsza operacyjnie usługa zarządzana okazuje się po prostu wystarczająco tania w stosunku do ryzyka i czasu ludzi.

Patrząc z góry: jeśli potrzebujesz szybkiego startu i prostoty, wybierz zarządzaną bazę relacyjną. Gdy masz proste, przewidywalne wzorce dostępu i dużo odczytów, dołóż NoSQL albo cache, żeby odciążyć główną bazę i rachunek. A jeśli działasz w skali, masz doświadczony zespół i konkretny powód finansowy lub regulacyjny, wtedy dopiero schodzenie na własne instancje czy klastry zaczyna mieć sens – razem z pełnym pakietem obowiązków, który za tym idzie.

Decyzje krok po kroku: jak przejść od wymagań aplikacji do konkretnej bazy i konfiguracji

Zamiast zaczynać od wyboru usługi z katalogu chmurowego, lepiej odwrócić proces: najpierw wymagania aplikacji Java, potem dopasowanie bazy i konfiguracji. Inaczej kończy się na „RDS db.m7g-super-XXL, bo tak ktoś zrobił w innym projekcie”.

Krok 1: Uporządkuj wymagania niefunkcjonalne zamiast „dajmy HA na maksa”

Najczęstszy scenariusz: biznes mówi „ma działać szybko i się nie psuć”. Technicznie da się to przetłumaczyć na dowolnie drogi klaster. Zanim wybierzesz usługę, spisz cztery podstawowe parametry:

• Ruch dzienny i szczytowy – orientacyjny QPS, liczba jednoczesnych użytkowników, oczekiwane piki (kampanie, integracje batchowe, zamknięcia miesiąca).
• Akceptowalna niedostępność – ile minut/godzin przerwy jest realnie nie do przyjęcia? Czy 99,5% uptime to katastrofa, czy w porządku?
• RPO (ile danych można utracić) – czy utrata 5–10 minut danych jest akceptowalna, czy absolutnie nie?
• RTO (jak szybko trzeba wstać po awarii) – minuta, pięć, godzina? Tu jest ogromna dźwignia kosztowa.

Krótka checklista, która mocno wpływa na rachunek:

• Jeśli RPO >= 5–10 minut i RTO >= 30 minut, często wystarczy single-AZ + snapshots, zamiast pełnego multi-AZ.
• Jeśli aplikacja ma okna serwisowe w nocy, nie ma sensu płacić za konfigurację jak dla systemu bankowego 24/7.
• Jeśli 90% ruchu to raporty wewnętrzne, a nie front dla klientów, SLA można ustawić trochę niżej – i budżet odetchnie.

Bez tego kroku każda kolejna decyzja (typ bazy, HA, backupy) będzie zbyt konserwatywna, a więc zbyt droga.

Krok 2: Dopasuj typ bazy do rodzaju obciążenia z Javy

Zasada jest prosta: nie płacisz za technologię, tylko za to, jak twoja aplikacja ją wykorzystuje. Warto więc nazwać po imieniu dominujący typ obciążenia:

• Transakcyjny CRUD z umiarkowanym ruchem – typowy monolit Spring Boot lub kilka mikroserwisów z prostymi operacjami biznesowymi. Tutaj zwykle wygrywa zarządzana relacyjna baza (RDS/Cloud SQL/Azure Database) z rozsądnym rozmiarem instancji.
• Dużo odczytów, mało skomplikowanych zapisów – katalogi produktów, profile użytkowników, konfiguracje. Najczęściej dobre połączenie: relacyjna baza + silny cache (Redis/MemoryStore) albo relacyjna baza + NoSQL dokumentowe na wybrane, proste dane.
• Analiza danych / raportowanie – długie zapytania, skany tabel, agregacje. To, co zabija OLTP. Tu lepiej wynieść raportowanie do osobnej bazy analitycznej lub data warehouse’a zamiast dusić główną bazę.

Prosty wzorzec, który często ratuje budżet: jedna solidna baza relacyjna pod transakcje + wyspecjalizowane magazyny pod dodatkowe potrzeby (cache, search, analityka), zamiast jednej „magicznej” bazy od wszystkiego na sterydach.

Krok 3: Zacznij od minimalnie sensownej konfiguracji, a nie od „docelowej”

Wiele zespołów projektuje pierwszą konfigurację bazy tak, jakby już miały tysiące użytkowników. Można podejść odwrotnie: startujesz z ustawieniem, które jest minimalnie bezpieczne, ale łatwe do skalowania w górę w ciągu kilku minut.

Dla typowej aplikacji Java (monolit lub kilka usług) rozsądny start wygląda tak:

• Klasa instancji: mała lub średnia (np. 2–4 vCPU, 8–16 GB RAM) zamiast od razu „production-optimized”.
• Storage: tyle, ile realnie potrzebujesz + 20–30% buforu, zamiast x3 „bo dane będą rosły”.
• HA: single-AZ na start, jeśli RPO/RTO to dopuszczają; multi-AZ dopiero po weryfikacji ruchu i wymagań biznesu.
• Backupy: retencja 7–14 dni dla środowisk niekrytycznych, dłuższa tylko tam, gdzie audyt lub regulacje tego wymagają.

Kluczowy warunek: musisz mieć przygotowaną ścieżkę szybkiego skalowania. Czyli opisane (i przetestowane) procedury:

• jak powiększyć instancję bazy (zmiana klasy, ewentualny krótki downtime),
• jak zwiększyć storage bez ryzyka „no space left on device”,
• jak włączyć multi-AZ, gdy biznes zacznie naprawdę tego potrzebować.

Bez tego grozi „paraliż decyzyjny” – zespół boi się dotykać konfiguracji, więc od razu wybiera duże i drogie ustawienia.

Krok 4: Ustaw connection pooling po stronie Javy tak, żeby nie zabijał bazy

Pool połączeń potrafi podbić rachunek bardziej niż różnica między klasami instancji. Zwłaszcza gdy każdy mikroserwis ustawia sobie własne „maximumPoolSize = 50”, a baza ma limit 100 połączeń.

Praktyczna mini-checklista dla Spring Boot + HikariCP:

• maxLifetime – ustaw niższy niż timeout połączeń na bazie (np. 30–45 minut), żeby unikać masowych odrzutów po stronie DB.
• maximumPoolSize – licz realnie: liczba instancji aplikacji × max pool per instancja <= limit połączeń na bazie z bezpiecznym marginesem. Zazwyczaj 10–20 na instancję w zupełności wystarcza.
• minimumIdle – nie ustawiaj równego maximumPoolSize, jeśli ruch jest zmienny. Mniejsza liczba bezczynnych połączeń = mniej pamięci i mniej presji na bazę.
• timeouty – connectionTimeout i idleTimeout dobrane tak, żeby w razie problemów w bazie aplikacja szybko reagowała, zamiast wisieć długo na martwych połączeniach.

Dobrym ruchem jest też włączenie obserwowalności puli – metryki: liczba aktywnych połączeń, odrzuconych żądań, czas oczekiwania. To one powiedzą, czy trzeba naprawdę zwiększać pulę, czy tylko optymalizować zapytania.

Krok 5: Ogranicz „czatowanie” z bazą – projektuj API pod mniej zapytań

Java, która dla jednego requestu HTTP robi dziesięć osobnych zapytań do bazy, to szybka droga do kosztów. Płacisz nie tylko za CPU i IOPS, ale też za konieczność większej instancji bazy i bardziej rozbudowanej HA.

Kilka prostych wzorców, które mocno zmniejszają liczbę round-tripów:

• Ładowanie grupowe (batch) – zamiast pętli, która po kolei ładuje każdy rekord (N+1), używaj zapytań z IN lub dedykowanych repozytoriów do ładowania całych kolekcji.
• Projekcje – nie pobieraj całego encji, jeśli potrzebujesz trzech pól do listy. Projekcje w JPA (interfejsy, DTO) zmniejszają transfer i obciążenie.
• Read models – jeśli frontend potrzebuje „zdenormalizowanego” widoku, czasem taniej jest utrzymywać dodatkową tabelę lub kolekcję read-only (odświeżaną asynchronicznie) niż za każdym razem składać widok z wielu joinów.
• Cache – wyniki często powtarzanych zapytań (konfiguracje, słowniki, rzadko zmieniające się dane) trzymaj w pamięci lub Redisie. Baza relacyjna powinna obsługiwać przede wszystkim operacje biznesowe, a nie być rozbudowanym key-value storem.

Przykład z praktyki: endpoint „/me” zwracający profil użytkownika. Jeśli każdy call robi osobne zapytania po adresy, preferencje, ostatnie zamówienia i powiadomienia – baza dostaje kilka razy więcej pracy niż to konieczne. Zdenormalizowany widok „profil użytkownika” w jednej tabeli lub dokumencie + lekkie cache po stronie aplikacji potrafią uciąć większość tych zapytań.

Krok 6: Rozdziel środowiska i poziom ochrony danych

Drogi błąd: traktowanie wszystkich środowisk jak produkcję. Dev, test, staging i demo często mają identyczne klasy instancji, backupy, a nawet multi-AZ. Rachunek za „środowiska pomocnicze” bywa wtedy większy niż za samą produkcję.

Prosty zestaw zasad, który zwykle działa bezboleśnie:

• Dev/feature – najmniejsze możliwe instancje, jedynie basic backup (albo nawet tylko rekreacja z migracji). Dane mogą być syntetyczne.
• Test/staging – konfiguracja zbliżona do produkcji tylko wtedy, gdy testujesz wydajność. Na co dzień można mieć mniejszą klasę instancji i krótszą retencję backupów.
• Demo/preview – często wystarczy współdzielona baza lub nawet snapshot produkcji z okrojonymi danymi, przywracany cyklicznie.

Dobrym nawykiem jest też nocne wyłączanie niektórych środowisk (VM-ki, klastery), jeśli chmura i architektura na to pozwalają. Przy serverless lub w pełni zarządzanych bazach jest to trudniejsze, ale w wielu projektach staging czy demo nie muszą działać 24/7.