RDS vs DynamoDB vs Aurora - którą bazę danych wybrać na AWS?

Trzy bazy, trzy filozofie

Na AWS masz ponad 15 serwisów bazodanowych, ale 90% aplikacji korzysta z trzech: RDS, DynamoDB i Aurora. Każda ma inną filozofię i inne zastosowania. Zły wybór na starcie oznacza kosztowną migrację za pół roku.

Amazon RDS - klasyka, która wciąż działa

Kiedy wybrać RDS?

RDS to najlepszy wybór gdy:

• Twoje dane są relacyjne - użytkownicy mają zamówienia, zamówienia mają produkty, produkty mają kategorie
• Potrzebujesz JOIN-ów - "pokaż zamówienia z produktami i danymi klienta"
• Twój zespół zna SQL - krzywa uczenia = 0
• Masz złożone zapytania analityczne - raportowanie, GROUP BY, window functions
• Potrzebujesz transakcji ACID na wielu tabelach jednocześnie

Uruchamianie RDS

# Utwórz subnet group (wymagane)
aws rds create-db-subnet-group \
  --db-subnet-group-name moja-apka-subnets \
  --db-subnet-group-description "Private subnets for DB" \
  --subnet-ids subnet-aaa111 subnet-bbb222

# Utwórz Security Group
aws ec2 create-security-group \
  --group-name rds-sg \
  --description "RDS access" \
  --vpc-id vpc-xxx

aws ec2 authorize-security-group-ingress \
  --group-id sg-rds123 \
  --protocol tcp --port 5432 \
  --source-group sg-app123  # dostęp tylko z app serwerów

# Utwórz instancję RDS PostgreSQL
aws rds create-db-instance \
  --db-instance-identifier moja-apka-db \
  --db-instance-class db.t3.micro \
  --engine postgres \
  --engine-version 16.4 \
  --master-username dbadmin \
  --master-user-password "SuperSilneHaslo123!" \
  --allocated-storage 20 \
  --storage-type gp3 \
  --max-allocated-storage 100 \
  --db-subnet-group-name moja-apka-subnets \
  --vpc-security-group-ids sg-rds123 \
  --backup-retention-period 7 \
  --no-publicly-accessible \
  --storage-encrypted

Koszty RDS

Do tego dochodzi storage ($0.115/GB/mc dla gp3) i opcjonalnie Multi-AZ (podwojenie kosztu instancji).

Amazon DynamoDB - NoSQL bez limitów skali

Kiedy wybrać DynamoDB?

DynamoDB jest idealny gdy:

• Masz proste wzorce dostępu - "pobierz użytkownika po ID", "lista zamówień klienta"
• Potrzebujesz milisekund latencji - single-digit ms niezależnie od rozmiaru tabeli
• Budujesz architekturę serverless (Lambda + DynamoDB to naturalne combo)
• Ruch jest nieregularny - mode on-demand = płacisz za faktyczne użycie
• Nie potrzebujesz JOIN-ów ani złożonych zapytań SQL
• Chcesz zero administracji - brak patching, brak instancji, brak backup management

Kluczowe koncepty DynamoDB

DynamoDB nie jest "bazą bez schematu". Ma schemat - ale inny niż SQL:

• Partition Key (PK) - klucz główny, determinuje w której partycji leżą dane
• Sort Key (SK) - opcjonalny, pozwala na query z warunkami (begins_with, between)
• GSI (Global Secondary Index) - dodatkowy "widok" na dane z innym PK/SK
• Single-table design - zamiast wielu tabel, jedna tabela z różnymi typami rekordów

# Utwórz tabelę DynamoDB
aws dynamodb create-table \
  --table-name MojaApka \
  --attribute-definitions \
    AttributeName=PK,AttributeType=S \
    AttributeName=SK,AttributeType=S \
    AttributeName=GSI1PK,AttributeType=S \
    AttributeName=GSI1SK,AttributeType=S \
  --key-schema \
    AttributeName=PK,KeyType=HASH \
    AttributeName=SK,KeyType=RANGE \
  --global-secondary-indexes '[{
    "IndexName": "GSI1",
    "KeySchema": [
      {"AttributeName":"GSI1PK","KeyType":"HASH"},
      {"AttributeName":"GSI1SK","KeyType":"RANGE"}
    ],
    "Projection": {"ProjectionType":"ALL"}
  }]' \
  --billing-mode PAY_PER_REQUEST

Przykładowe operacje

import boto3

dynamodb = boto3.resource('dynamodb')
table = dynamodb.Table('MojaApka')

# Zapis
table.put_item(Item={
    'PK': 'USER#abc123',
    'SK': 'PROFILE',
    'name': 'Jan Kowalski',
    'email': '[email protected]',
    'plan': 'pro'
})

# Odczyt po kluczu - stałe <5ms niezależnie od rozmiaru tabeli
result = table.get_item(Key={'PK': 'USER#abc123', 'SK': 'PROFILE'})

# Query - wszystkie zamówienia użytkownika
result = table.query(
    KeyConditionExpression='PK = :pk AND begins_with(SK, :sk)',
    ExpressionAttributeValues={
        ':pk': 'USER#abc123',
        ':sk': 'ORDER#'
    }
)

# Scan - UNIKAJ na produkcji (czyta całą tabelę!)
# Zamiast scan, użyj GSI z odpowiednim kluczem

Koszty DynamoDB

Amazon Aurora - RDS na sterydach

Kiedy wybrać Aurora?

Aurora to relacyjna baza danych zbudowana przez AWS od podstaw, kompatybilna z MySQL i PostgreSQL. Wybierz ją gdy:

• Potrzebujesz SQL + wysokiej wydajności - Aurora oferuje do 5× przepustowości standardowego MySQL i do 3× standardowego PostgreSQL
• Chcesz auto-skalowanie storage - dysk rośnie automatycznie od 10 GB do 128 TB
• Potrzebujesz wielu read replik - do 15, z lagiem rzędu milisekund dzięki wspólnemu storage (RDS też pozwala na 15, ale każda replika to osobna kopia danych)
• Chcesz serverless SQL - Aurora Serverless v2 skaluje się do 0 ACU (auto-pause), gdy baza śpi płacisz tylko za storage
• Wymagasz global database - replikacja cross-region z <1s lag

Aurora Serverless v2 - game changer

Aurora Serverless v2 automatycznie skaluje compute od 0 ACU (auto-pause przy braku połączeń, wznowienie ~15 s) do 256 ACU (1 ACU = ~2 GB RAM). Płacisz za faktyczne użycie, nie za zarezerwowaną instancję:

# 1. Utwórz klaster Aurora Serverless v2
aws rds create-db-cluster \
  --db-cluster-identifier moja-apka-aurora \
  --engine aurora-postgresql \
  --engine-version 16.4 \
  --master-username dbadmin \
  --master-user-password "SuperSilneHaslo123!" \
  --serverless-v2-scaling-configuration MinCapacity=0.5,MaxCapacity=8 \
  --db-subnet-group-name moja-apka-subnets \
  --vpc-security-group-ids sg-rds123 \
  --storage-encrypted

# 2. Dodaj instancję writer (Serverless v2)
aws rds create-db-instance \
  --db-instance-identifier moja-apka-aurora-writer \
  --db-cluster-identifier moja-apka-aurora \
  --db-instance-class db.serverless \
  --engine aurora-postgresql

# 3. Opcjonalnie: dodaj read replica (też serverless)
aws rds create-db-instance \
  --db-instance-identifier moja-apka-aurora-reader \
  --db-cluster-identifier moja-apka-aurora \
  --db-instance-class db.serverless \
  --engine aurora-postgresql

Koszty Aurora

Porównanie głowa do głowy

Drzewo decyzyjne - szybki wybór

Odpowiedz na te pytania w kolejności:

1. Potrzebujesz JOIN-ów i złożonych zapytań SQL?
   • TAK → RDS lub Aurora (przejdź do pytania 4)
   • NIE → przejdź do pytania 2
2. Czy Twoje wzorce dostępu to głównie get/put po kluczu?
   • TAK → DynamoDB
   • NIE → RDS lub Aurora
3. Budujesz architekturę serverless (Lambda)?
   • TAK → DynamoDB (naturalny partner Lambda, zero connection pooling issues)
   • NIE → RDS lub Aurora
4. Potrzebujesz auto-skalowania compute + storage?
   • TAK → Aurora Serverless v2
   • NIE → przejdź do pytania 5
5. Budżet jest ograniczony (startup, side project)?
   • TAK → RDS (db.t3.micro na start)
   • NIE → Aurora (lepsza wydajność, mniej zarządzania)

Scenariusze z praktyki

Scenariusz 1: Sklep e-commerce

Rekomendacja: Aurora PostgreSQL

Produkty, zamówienia, koszyk, użytkownicy - relacyjne dane z JOIN-ami. Potrzebujesz raportów sprzedaży (GROUP BY, SUM). Aurora daje wydajność potrzebną w Black Friday bez ręcznego skalowania. Read replica dla raportów, żeby nie obciążać writera.

Scenariusz 2: Aplikacja SaaS (API-driven)

Rekomendacja: DynamoDB

Proste CRUD na zasobach tenantów. Serverless backend (Lambda). Nieregularny ruch. DynamoDB on-demand skaluje się od zera do tysięcy requestów/s bez konfiguracji. Zero kosztów stałych. Architekturę SaaS na DynamoDB opisałem w Use Case: SaaS za 200 zł.

Scenariusz 3: Blog / CMS

Rekomendacja: RDS PostgreSQL (db.t3.small)

Relacyjne dane (posty, kategorie, komentarze, tagi). Złożone zapytania (najnowsze posty w kategorii z liczbą komentarzy). Mały budżet. RDS t3.small za $30/mc w zupełności wystarczy. Jeśli ruch rośnie, dodaj read replica i cache (ElastiCache).

Scenariusz 4: IoT / real-time analytics

Rekomendacja: DynamoDB + S3 (data lake)

Tysiące urządzeń wysyłających dane co sekundę. DynamoDB obsługuje miliony writes/s. Hot data (ostatnie 24h) w DynamoDB, cold data eksportuj do S3 i analizuj Athena/QuickSight.

Scenariusz 5: System bankowy / finanse

Rekomendacja: Aurora PostgreSQL z Multi-AZ

Transakcje ACID na wielu tabelach (przelew = debit + credit atomowo). Aurora Global Database dla disaster recovery. Szyfrowanie at-rest i in-transit. Audit logging. Zero kompromisów na niezawodności.

Połączenie baz - polyglot persistence

W praktyce wiele aplikacji używa WIĘCEJ niż jednej bazy. To normalne i ma nawet nazwę - polyglot persistence:

• Aurora - główna baza (użytkownicy, zamówienia, finanse)
• DynamoDB - sesje użytkowników, cache, feature flags
• ElastiCache (Redis) - cache API responses, rate limiting
• S3 - pliki, obrazy, backupy

Nie bój się mieszać technologii - każda baza robi co innego najlepiej.

Problemy z Lambda + RDS (i jak je rozwiązać)

Jeśli łączysz Lambda z RDS/Aurora, napotkasz problem connection pooling. Lambda tworzy nowe połączenie przy każdym cold starcie, a baza ma limit połączeń (np. 100 dla db.t3.micro).

Rozwiązanie: RDS Proxy - managed connection pooler:

# Utwórz RDS Proxy
aws rds create-db-proxy \
  --db-proxy-name moja-apka-proxy \
  --engine-family POSTGRESQL \
  --auth '[{
    "AuthScheme": "SECRETS",
    "SecretArn": "arn:aws:secretsmanager:eu-central-1:123456789:secret:db-creds",
    "IAMAuth": "REQUIRED"
  }]' \
  --role-arn arn:aws:iam::123456789:role/rds-proxy-role \
  --vpc-subnet-ids subnet-aaa111 subnet-bbb222 \
  --vpc-security-group-ids sg-proxy123

# Zarejestruj target
aws rds register-db-proxy-targets \
  --db-proxy-name moja-apka-proxy \
  --db-cluster-identifiers moja-apka-aurora

RDS Proxy kosztuje ~$0.015/vCPU/h, rozliczane min. za 2 vCPU (~$22/mc dla db.t3.small). DynamoDB nie ma tego problemu - kolejny powód, dla którego jest naturalnym partnerem Lambda.

FAQ - najczęstsze pytania o bazy danych AWS

Co dalej?

1. Przejdź przez drzewo decyzyjne wyżej i wybierz bazę dla swojego projektu.
2. Dla RDS/Aurora: zacznij od najtańszej instancji i skaluj w górę gdy metryki w CloudWatch pokażą bottleneck.
3. Dla DynamoDB: zacznij od on-demand mode i zaprojektuj single-table design.
4. Umieść bazę w prywatnym subnecie VPC z odpowiednimi Security Groups.
5. Włącz szyfrowanie (at-rest i in-transit) i automatyczne backupy.
6. Jeśli używasz Lambda z RDS - rozważ RDS Proxy.

Wybór bazy danych to jedna z najważniejszych decyzji architektonicznych. Zły wybór = kosztowna migracja za pół roku. Dobry wybór = infrastruktura, która rośnie razem z aplikacją. Jeśli budujesz pełną architekturę, przeczytaj architekturę aplikacji webowej na AWS.