Die eine Sache, die Sie nicht überspringen können
Jedes B2B-SaaS rennt im zweiten Monat gegen dieselbe Wand. Die Nutzerin klickt auf einen Button, und nun muss die App eine E-Mail senden, ein PDF erzeugen, eine Drittanbieter-API aufrufen, ein Webhook posten und drei Datensätze aktualisieren.
All das synchron zu tun, ist eine 12-Sekunden-Seitenladezeit. Tun Sie das nicht.
Hintergrundjobs sind die richtige Antwort. Die Frage ist, welches Hintergrundjob-System. Die drei meistgenutzten 2026 sind Sidekiq (Ruby), BullMQ (Node) und Celery (Python), und jedes hat eine starke Meinung dazu, wie asynchrone Arbeit ablaufen sollte.
Wir haben alle drei ausgeliefert. Sie sind nicht austauschbar. Das falsche für Ihren Stack zu wählen, kann Sie Wochen kosten.
Hier ist der ehrliche Vergleich aus der Praxis, nicht aus dem Marketingdeck.
Sidekiq: Der leise Standard
Sidekiq ist seit 2012 die Standardantwort in Ruby. Mike Perham pflegt es bis heute. Es führt Hintergrundjobs als Ruby-Threads in einem einzigen Prozess aus, gestützt auf Redis.
Der Pitch ist Einfachheit. Ein Ruby-Prozess, eine Redis-Instanz, zehn Zeilen Code, und Sie liefern asynchrone Arbeit aus. Sidekiq Pro ergänzt Batches, Callbacks und Reliability-Features, Sidekiq Enterprise ergänzt Rate-Limiting und Unique Jobs.
Produktion im großen Maßstab ist gut verstanden. Shopify, Stripe, Gusto, GitLab, Mastodon und die meisten Rails-Unternehmen mit über zehn Engineers verarbeiten jährlich Milliarden Jobs auf Sidekiq. Sidekiq 8 (veröffentlicht im März 2025) ist die aktuelle Linie und setzt Ruby 3.2+ voraus.
Die operative Geschichte ist reif: Dashboards, Metriken, Alerting, Replay-Tooling.
Das Threading-Modell ist der Gewinn. Ein Sidekiq-Prozess mit 25 Threads bewältigt die Arbeit von 25 single-threaded Worker-Prozessen mit einem Bruchteil des Speichers. Für Ruby, wo Speicher tatsächlich ein Budgetposten ist, zählt das.
Die zweite Ruby-Option 2026 ist Solid Queue, die datenbankgestützte Queue, die 37signals mit Rails 8 ausgeliefert hat. Sie verarbeitet bei HEY 20 Millionen Jobs pro Tag, ohne Redis. Für neue Rails-Projekte starten wir zunehmend dort: ein System weniger zu betreiben, eine Infrastruktur-Abhängigkeit weniger, und der Durchsatz reicht für so gut wie jeden B2B-SaaS-Workload.
Wir haben die operativen Implikationen in Datenisolierung und Sicherheit in Multi-Mandanten-Systemen beschrieben, und sie gelten für Solid Queue ebenso wie für Sidekiq.
BullMQ: Der Node-Standard, der ihn sich verdient hat
BullMQ ist der moderne Nachfolger von Bull. TypeScript-first, aktiv gepflegt und in Produktion bei Netflix, Stripe und Twilio für Milliarden Jobs pro Monat im Einsatz. Die 5.x-Linie kam 2024 mit substanziellen Reliability-Verbesserungen, 2026 ist es die langweilige Wahl für Node-basierte asynchrone Arbeit.
Die Architektur ähnelt Sidekiqs. Redis-gestützte Queues, mehrere Worker, eine saubere Job-Handler-API. Wo es sich unterscheidet:
- Job-Abhängigkeiten sind First-Class. Eltern-Jobs warten auf Kind-Jobs. Nützlich für Fan-In-Muster.
- Rate-Limiting, Priorisierung und Job-Gruppierung sind eingebaut.
- Die Bull-Board-UI ist ab Werk anständig (Sidekiqs Web-UI ist immer noch besser, aber der Abstand ist geschlossen).
- Wiederkehrende Jobs und Cron-artige Planung funktionieren ohne separate Bibliothek.
Für einen reinen Node-Stack (Next.js, NestJS, Hono) ist BullMQ die richtige Antwort. Es gibt keinen echten Zweiten, der in Produktion in derselben Größenordnung liefert. Inngest und Trigger.dev existieren als gehostete Alternativen, falls Sie eine verwaltete Job-Plattform mit UI wollen; selbstgehostete Agenda-Forks wie Pulse gibt es weiterhin für MongoDB-Setups, wobei Sie jeweils Lock-in oder Plattformreichweite gegen Komfort tauschen.
Der Haken: BullMQ setzt Redis voraus. Wenn Ihr Plattform-Team Redis nicht betreiben will, sitzen Sie fest. Es gibt eine Postgres-gestützte Queue namens pg-boss, die diese Nische füllt, aber mit schmalerer Produktionserprobung.
Celery: Der Python-Workhorse mit Footguns
Celery ist seit über einem Jahrzehnt die Standardantwort in Python. Es ist mächtig, ausgereift und unterstützt mehr Konfigurationsstellschrauben, als irgendjemand vernünftigerweise braucht. Instagram lief in der Spitze auf Celery, ebenso wie das meiste Django-Ökosystem.
Stärken: riesige Feature-Oberfläche, Broker-Flexibilität (Redis, RabbitMQ, Kafka, SQS), starke Result-Backends, ausgereifte Django-Integration, gute Flower-UI. Wer einmal Celery so konfiguriert hat, wie es laufen soll, hat ein Werkzeug, das fast jede asynchrone Anforderung erschlagen kann.
Die Schwächen sind gut dokumentiert und real:
- Konfiguration ist eine kleine Karriere. Standardeinstellungen werden Sie beißen. Acks-late, Prefetch-Counts, Visibility-Timeouts, Broker-Kompatibilitätsmacken. Rechnen Sie mit einer Woche Einarbeitung.
- Die Kombination “Celery + Redis als Broker” hat im großen Maßstab subtile Reliability-Probleme. Die meisten produktiven Celery-Deployments landen bei RabbitMQ oder SQS als Broker.
- Die Community wandert zu Alternativen ab. Dramatiq ist einfacher und gut genug für die meisten Teams. arq ist async-first und schlanker. Procrastinate nutzt Postgres direkt, also kein separater Broker nötig.
Für neue Python-Projekte 2026 wählen wir Celery nur, wenn wir wissen, dass wir seine spezifischen Features brauchen. Für die meisten Teams ist Dramatiq oder Procrastinate schneller ausgeliefert und einfacher zu betreiben.
Wie sie sich wirklich vergleichen
Für einen typischen B2B-SaaS-Workload (10-1000 Jobs pro Sekunde, Mischung aus schnellen und langen Tasks, Retry-on-Failure-Semantik, geplante Jobs):
- Operative Reife: Sidekiq > BullMQ > Celery (Celery verliert Punkte für Footgun-Dichte, nicht für Fähigkeiten).
- Speichereffizienz: Sidekiq > BullMQ > Celery. Threading vs. Prozess-pro-Worker zählt.
- No-Redis-Option: Solid Queue (Ruby) > Procrastinate (Python) > pg-boss (Node). Für Teams, die wirklich keine zusätzliche Infrastruktur-Abhängigkeit wollen.
- Job-Abhängigkeiten und komplexe Flows: BullMQ hat die sauberste API. Celery kann es. Sidekiq Pro kann es mit Batches.
- Durchsatz im Extremmaßstab: Alle drei erreichen auf einer einzelnen Shard zehntausende Jobs pro Sekunde, mit gesharded Redis oder partitionierten Datenbanken deutlich über 100k. Keines davon ist Ihr Engpass für B2B-SaaS-Volumen.
Was wir für Kunden ausliefern
Für ein Rails-Projekt: Solid Queue, wenn es Rails 8 ist, Sidekiq, wenn es älter ist oder das Team das Sidekiq-Dashboard und Ökosystem ausdrücklich will. Bei deutschen Mittelstandskunden mit strikten Datenschutzanforderungen wiegt das Argument “kein Redis betreiben, weil ein System weniger zu auditieren ist” oft besonders schwer.
Für ein Node- oder TypeScript-Projekt: BullMQ. Immer. Es gibt für Node keine echte Alternative auf demselben Reife-Niveau, und der Operations-Aufwand ist mit einer kleinen Redis-Instanz überschaubar.
Für ein Python-Projekt: Procrastinate oder Dramatiq für Neubauten. Celery nur bei Migration aus einem bestehenden Celery-Setup oder wenn wir das spezifische Feature-Set wirklich brauchen. Die Django-Integrationsgeschichte ist 2026 für beide Optionen gut, das alte Argument “Celery ist, was Django nutzt” trägt nicht mehr wie vor fünf Jahren.
Für einen polyglotten Stack mit gemischten Sprachen: Eine Postgres-gestützte Queue (Solid Queue, Procrastinate oder River für Go) gewinnt oft, weil sie den sprachübergreifenden Koordinationsaufwand von Redis oder RabbitMQ entfernt. Sie haben dann ein Backup, einen Audit-Pfad und ein Monitoring-Dashboard für alle Jobs, statt zwei Stacks parallel zu pflegen. Wir haben das umfassendere Argument für Postgres als Queue in unserem Blick auf die wahren Kosten technischer Schulden berührt.
Der Entscheidungsfilter
Drei Fragen, in dieser Reihenfolge:
- In welcher Sprache läuft Ihre Anwendung? Das eliminiert zwei der drei.
- Betreiben Sie bereits Redis? Falls ja, ist die Wahl innerhalb Ihrer Sprache leichter. Falls nein, bevorzugen Sie die Postgres-gestützte Option.
- Brauchen Sie ein Feature, das nur eines von ihnen einzigartig bietet? Job-Abhängigkeiten, Rate-Limiting, komplexe Retries, Batches. Falls ja, lautet die Antwort, was zum Feature passt.
Die meisten Teams überdenken das. Die richtige Antwort für 95 % der B2B-SaaS lautet “das Standard-Hintergrundjob-System für Ihren Stack, mit vernünftigen Defaults konfiguriert, mit funktionierendem Dashboard und Alerting verkabelt”.
Lassen Sie Kafka und die eigene Queue-Schicht weg. Liefern Sie Produkt aus. Die Reliability-Probleme, die Sie sich ausmalen, tauchen unabhängig von der gewählten Queue auf, und sie mit der richtigen Queue plus guter Observability zu lösen schlägt es, eine exotische Queue zu wählen und zu hoffen, dass nichts kaputtgeht. Wir haben in den letzten Jahren mehr Schaden durch zu früh eingeführte Eventbus-Architekturen repariert als durch zu lange beibehaltene Sidekiq-Setups.
Sie wählen ein Hintergrundjob-System für ein neues Projekt oder versuchen, eine Produktions-Queue zu reparieren, die Jobs verliert? Lassen Sie uns reden. Wir schauen uns Ihren Stack, Ihren Traffic und Ihre Reliability-Anforderungen an und sagen ehrlich, welches der drei (oder welche schlankere Alternative) passt.