SQS czy Redis dla kolejek w Laravel — porównanie [2026]

Redis i Amazon SQS to dwa najczęściej wybierane sterowniki kolejek w Laravelu — i odpowiadają na różne potrzeby. Redis to szybkość, priorytety i Laravel Horizon. SQS to zarządzanie, trwałość i dopasowanie do infrastruktury AWS. Ten poradnik porównuje oba sterowniki w wymiarach, które faktycznie decydują: wydajność, koszty, możliwości i ograniczenia — z konfiguracją SQS krok po kroku i scenariuszem hybrydowym.

Najważniejsze: Najważniejsze — jeśli aplikacja działa na własnym serwerze i używasz Horizon: Redis. Jeśli infrastruktura siedzi w AWS (EC2, Lambda, kontenery): SQS — znika problem utrzymania Redisa, a kolejka jest usługą zarządzaną z trwałością wbudowaną w cenę. SQS nie wspiera priorytetów kolejek ani Laravel Horizon; Redis nie daje trwałości na poziomie usługi i wymaga własnego serwera.

Redis vs SQS — porównanie w praktyce

Trzy różnice, które przesądzają najczęściej

1. Horizon działa tylko na Redisie. Jeśli panel kolejek, autoskalowanie i metryki są dla ciebie kluczowe — wybór jest z góry przesądzony.
2. Priorytety kolejek. Redis: --queue=high,default,low i zadania z high zawsze przed resztą. SQS: brak natywnych priorytetów — symuluje się je osobnymi kolejkami i osobno skonfigurowanymi workerami.
3. Trwałość. SQS replikuje wiadomości między strefami dostępności — awaria jednej strefy nie gubi zadań. Redis bez konfiguracji persistence gubi zadania przy restarcie (dla kolejek włączamy AOF/RDB, ale to wciąż jeden serwer, nie usługa HA).

Konfiguracja SQS w Laravel krok po kroku

• Wymagania: konto AWS, kolejka SQS, użytkownik IAM z uprawnieniami do kolejki.

1. Utworzenie kolejki (konsola AWS lub CLI)

aws sqs create-queue --queue-name production-jobs
# FIFO (zachowana kolejność):
aws sqs create-queue --queue-name production-jobs.fifo --attributes FifoQueue=true

2. Uprawnienia IAM — użytkownik techniczny z polityką ograniczoną do konkretnej kolejki

{
    "Version": "2012-10-17",
    "Statement": [{
        "Effect": "Allow",
        "Action": ["sqs:SendMessage", "sqs:ReceiveMessage", "sqs:DeleteMessage", "sqs:GetQueueAttributes"],
        "Resource": "arn:aws:sqs:eu-central-1:123456789:production-jobs"
    }]
}

3. Konfiguracja w Laravelu — .env i config/queue.php

QUEUE_CONNECTION=sqs
AWS_ACCESS_KEY_ID=...
AWS_SECRET_ACCESS_KEY=...
AWS_DEFAULT_REGION=eu-central-1
SQS_PREFIX=https://sqs.eu-central-1.amazonaws.com/123456789
SQS_QUEUE=production-jobs

// config/queue.php — sterownik sqs z prefixem i kolejką
'sqs' => [
    'driver' => 'sqs',
    'key' => env('AWS_ACCESS_KEY_ID'),
    'secret' => env('AWS_SECRET_ACCESS_KEY'),
    'prefix' => env('SQS_PREFIX'),
    'queue' => env('SQS_QUEUE'),
    'suffix' => env('SQS_SUFFIX'),
    'region' => env('AWS_DEFAULT_REGION', 'us-east-1'),
    'after_commit' => false,
],

4. Uruchomienie workera — identycznie jak przy Redisie, zmienia się tylko nazwa sterownika

php artisan queue:work sqs --tries=3 --timeout=90 --max-time=3600

• ## SQS: na co uważać

• Limit 256 KB na wiadomość. Payload zadania większy niż 256 KB zostanie odrzucony. Wzorzec: duże dane (pliki, duże tablice) zapisz do S3/bazy i w zadaniu przekazuj referencję — nie zawartość.

• Brak priorytetów. Potrzebujesz „high" i „default"?

  Utwórz dwie kolejki i dwa procesy workerów (queue:work sqs --queue=https://.../high i drugi na default). To działa, ale konfiguracja jest mniej wygodna niż --queue=high,default.

• Visibility timeout. SQS ukrywa wiadomość na czas przetwarzania (visibility timeout) — jeśli zadanie trwa dłużej, wiadomość „wróci" do kolejki i zostanie przetworzona ponownie. Ustaw visibility timeout dłuższy niż najdłuższe zadanie (parametr kolejki) i pilnuj, żeby --timeout workera był krótszy.

• Delay do 15 minut. ->delay() działa, ale maksymalny natywny delay w SQS to 15 minut. Dłuższe opóźnienia realizuj schedularem.

• Koszt przy dużym ruchu. Płatność za żądania: worker pollowanie (long polling) to jedno żądanie na 20 s bez zadań; przy setkach tysięcy zadań miesięcznie koszty są groszowe, ale przy dziesiątkach milionów — policz.

Kiedy Redis, kiedy SQS — scenariusze

Wskazówka: SQS ma wbudowany odpowiednik failed_jobs — dead-letter queue (DLQ). Konfigurujesz „redrive policy": po N nieudanych próbach wiadomość trafia do kolejki DLQ, którą przeglądasz i ponawiasz osobno. Warto ustawić od pierwszego dnia — bez DLQ nieudane wiadomości po prostu znikają po przekroczeniu limitu odbiorów.

Scenariusz hybrydowy — Redis do szybkości, SQS do trwałości

Można używać obu sterowników równocześnie — Laravel pozwala wskazać połączenie per zadanie

class SyncOrderToErp implements ShouldQueue
{
    public $connection = 'sqs';      // zadania krytyczne → SQS (trwałość)
}

class SendMarketingEmail implements ShouldQueue
{
    public $connection = 'redis';    // masowe, mniej krytyczne → Redis (szybkość)
}

W praktyce ten układ bywa nadmiarowy — utrzymujesz dwa systemy kolejek. Ma sens, gdy jednocześnie potrzebujesz Horizon (Redis) do zadań masowych i gwarancji trwałości (SQS) dla operacji finansowych. Dla większości projektów: jeden sterownik, wybrany świadomie.

Migracja między sterownikami — co się zmienia

Przejście Redis ↔ SQS jest w Laravelu tanie, bo sterownik to warstwa pod spodem — kod zadań, retry, backoff i middleware zostają bez zmian. Zmieniają się:

• Konfiguracja — .env (QUEUE_CONNECTION) i config/queue.php.
• Workery — queue:work redis → queue:work sqs (plus ewentualne osobne procesy dla wielu kolejek SQS).
• Monitoring — Horizon przestaje działać (Redis-only); na SQS zostają Pulse i queue:monitor.
• Failed jobs — na Redisie tabela failed_jobs; na SQS dodatkowo DLQ do skonfigurowania.

Zadania w locie przepadną przy przełączeniu (stara kolejka nie jest opróżniana) — migrację rób w oknie serwisowym albo poczekaj, aż kolejka będzie pusta.

Najczęściej zadawane pytania

Czy Laravel Horizon działa z Amazon SQS?

Nie — Horizon obsługuje wyłącznie sterownik Redis. Na SQS korzystasz z Laravel Pulse (rozmiar i przepustowość kolejek), komendy queue:monitor do alertów i natywnego monitoringu AWS (CloudWatch). To jeden z głównych powodów, dla których projekty spoza AWS zostają przy Redisie.

Czy SQS wspiera priorytety kolejek?

Nie ma natywnych priorytetów. Standardowy wzorzec: osobna kolejka SQS dla każdego priorytetu i osobny proces workera na każdą z nich (queue:work sqs --queue=...high, queue:work sqs --queue=...default). Działa poprawnie, ale wymaga więcej konfiguracji niż --queue=high,default na Redisie.

Ile kosztuje SQS?

Płatność za liczbę żądań — około 0,40 USD za milion żądań (standardowa kolejka). Long polling sprawia, że puste pollowanie to jedno żądanie na 20 sekund, więc koszt „bezczynnej" kolejki jest pomijalny. Przy dziesiątkach milionów zadań miesięcznie koszty warto policzyć — Redis z stałym kosztem serwera może wyjść taniej.

Co się dzieje z zadaniem, które przekroczy limit prób w SQS?

Bez konfiguracji DLQ wiadomość znika po przekroczeniu limitu odbiorów (max receive count). Z redrive policy trafia do dead-letter queue, gdzie możesz ją przejrzeć i ponowić. Konfiguruj DLQ od pierwszego dnia — to odpowiednik tabeli failed_jobs, ale trzeba go włączyć świadomie.

Czy mogę zmienić sterownik kolejek bez zmian w kodzie zadań?

Tak — sterownik jest warstwą pod spodem, a zadania, retry, backoff i middleware pozostają bez zmian. Zmienia się konfiguracja (.env, config/queue.php), komenda workera i monitoring (Horizon tylko dla Redisa). Zadania oczekujące w starej kolejce przepadną — przełączaj przy pustej kolejce albo w oknie serwisowym.

👉 Nie wiesz, który sterownik wybrać, albo migrujesz aplikację do AWS? Opisz projekt na kontakt@informatix.com.pl lub przez formularz — dobierzemy sterownik do infrastruktury i skonfigurujemy kolejki z monitoringiem.

📖 Zobacz również: Kolejki w Laravel i Laravel Horizon — poradnik, Redis w Laravel — cache, kolejki i sesje, Horizon, Pulse i Telescope — monitoring oraz usługa Laravel development.