Backend-Stack für Soloselbstständige: Cloudflare Workers, Supabase, Node.js und Datenbanken auswählen

Das Frontend des Tools steht. Nun müssen /api/submit, /api/checkout-webhook und /api/report-cron umgesetzt sowie users, usage_events und files gespeichert werden. Was gehört in Workers, was in Supabase und wofür brauchst du einen separaten Node-Dienst?

Ein Backend-Stack besteht nicht aus einer Plattform für alles. Request-Eingang, Geschäftsdaten, Dateispeicher, lange Jobs, Authentifizierung und Webhooks werden auf verschiedene Dienste verteilt. Workers passt zu Edge-Eingang und leichter Logik, Supabase trägt Auth und Postgres, Node.js übernimmt schwere Arbeit und Abhängigkeiten außerhalb einer Edge-Runtime. Gleiche die folgende Zuständigkeitstabelle mit deinem Backlog ab.

1. Zuständigkeitstabelle: Was gehört wohin?

Beginne mit deiner Liste aus APIs, Webhooks, Cron-Jobs, Daten und Dateien:

Die Tabelle sagt nicht, dass alles in Workers gehört. Workers hat CPU-, Speicher- und Subrequest-Limits, Supabase Pausen- und Nutzungsgrenzen, Node.js laufende Betriebskosten. Ein Node-Dienst lässt sich am Anfang verschieben, aber sein Einsatzsignal sollte bekannt sein.

Daten richtig zuordnen

• Geschäftsdaten → Supabase Postgres oder eine andere relationale Datenbank für Relationen, Transaktionen, Abfragen, Trigger und Fremdschlüssel.
• Dateien → Supabase Storage oder R2 nach Berechtigungen, Egress, CDN, Region und vorhandenem Tooling.
• Cache → KV; D1 kann leichte relationale Edge-Daten tragen, aber ein Cache darf nicht die Geschäftsquelle ersetzen.

Der vollständige Vergleich von D1, Postgres, R2, S3 und SQLite folgt im Datenbank- und Storage-Artikel. Hier geht es nur um die Datenklasse.

Webhook und Langzeitjob trennen

Stripe- oder GitHub-Webhooks können am Edge in Workers oder in einem Supabase-zentrierten Projekt in Edge Functions ankommen. Der Handler prüft die Signatur, schreibt einen Idempotenzdatensatz und antwortet schnell. Browserautomatisierung, große Parser oder mehrstufiges Warten laufen anschließend in Queue, Workflow, Container oder Node.js-Worker.

Bei Workers Paid haben normale HTTP-Requests standardmäßig 30 Sekunden CPU und können bis 5 Minuten konfiguriert werden. Cron Trigger mit mindestens stündlichem Intervall dürfen bis zu 15 Minuten CPU nutzen. Für HTTP gibt es bei bestehender Client-Verbindung kein festes Wall-Clock-Limit. Trotzdem sind lange Request-Jobs wegen Verbindungsabbrüchen, Retries, Ressourcenlimits und Runtime-Updates unzuverlässig.

Warnlinien der Gratisstufen

Stand Juli 2026 enthält Workers Free 100.000 Requests pro Tag, 10 ms CPU pro Invocation, 128 MB Speicher und 50 Subrequests. Supabase Free enthält 50.000 MAU, 500 MB Datenbank je Projekt, 5 GB Egress, 1 GB Dateispeicher und bis zu zwei aktive Projekte.

Diese Quoten sind ein Startbudget, kein Architekturversprechen. Supabase pausiert Free-Projekte nach einer Woche Inaktivität; Workers-Last oberhalb Free braucht Paid. Bei stabilen Nutzern oder Zahlungen gehören Nutzungsalarme, Kostenmodell und Degradationsplan dazu.

2. Cloudflare Workers: geeignete und ungeeignete Aufgaben

Workers ist kein Universal-Backend. Praktische Grenzen entstehen durch CPU, Speicher, Subrequests und Bundle-Größe, nicht durch die Frage, ob JavaScript läuft.

KiloClaw - Managed OpenClaw für Unternehmen: AI-Agent-Orchestrierung und smartes Modell-Routing

Jetzt starten →Anzeige

Workers-Free-Limits im Juli 2026

Workers Free erlaubt 100.000 Requests pro Tag und 10 ms CPU pro Invocation. Der Speicher ist auf 128 MB, Subrequests auf 50 und das komprimierte Bundle auf 3 MB begrenzt. CPU-Überschreitungen liefern Fehler 1102. Solange der Client verbunden bleibt, hat ein HTTP-Request kein festes Wall-Clock-Limit; nach Antwort oder Abbruch verlängert ctx.waitUntil() die Arbeit höchstens 30 Sekunden.

Workers Paid im Standard-Tarif

Workers Paid kostet mindestens 5 US-Dollar pro Account und Monat und enthält 10 Millionen Requests sowie 30 Millionen CPU-Millisekunden. HTTP-CPU beträgt standardmäßig 30 Sekunden und kann bis 5 Minuten konfiguriert werden. Weitere Requests kosten 0,30 US-Dollar je Million, zusätzliche CPU 0,02 US-Dollar je Million Millisekunden. Es gelten 10.000 Subrequests, 10 MB komprimiertes Bundle und weiterhin 128 MB Speicher.

Geeignete Einsatzfälle

• Request-Eingang, Edge-Proxys und leichte APIs.
• Webhook-Empfang, Signaturprüfung und idempotentes Einreihen.
• Trigger und Orchestrierung für Cron, Queues und Workflows.
• KV/R2-Zugriffe, Cache-Header, Redirects und A/B-Routing.

Diese Arbeit besteht vor allem aus Netzwerk-I/O, Validierung und Orchestrierung. Sie braucht weder große Dateien im Speicher noch Browserprozesse oder native Systembibliotheken.

Ungeeignete Einsatzfälle

• Dauerhaft CPU-intensive Berechnung → Algorithmus teilen, asynchron ausführen oder zu Node.js/Container verschieben.
• Ganze große Dateien puffern → streamen, direkt in Object Storage laden oder Dateidienst nutzen.
• Lange Browser-Jobs → Node.js mit Playwright/Puppeteer oder gehosteter Browserdienst.
• Abhängigkeiten außerhalb von Bundle oder Runtime → Node.js-Dienst oder Container.

Die Node.js-Kompatibilität von Workers deckt viele APIs ab. „Es lässt sich bundeln“ bedeutet aber nicht „es gehört hierher“. Ressourcen, Retries, Laufzeit und Beobachtbarkeit entscheiden.

Kostengrenze

Bei durchschnittlich 5 ms CPU verbrauchen 10 Millionen dynamische Requests rund 50 Millionen CPU-ms. Nach den enthaltenen 30 Millionen entstehen etwa 0,40 US-Dollar zusätzliche CPU-Kosten. KV, Queues, R2 und andere Produkte können separat berechnet werden.

Wichtiger als der kleine Betrag ist, ob eine Kernfunktion nur innerhalb einer Gratisquote funktioniert. Wenn Mehrverbrauch Marge oder Verfügbarkeit bricht, werden Rate Limit, Cache und Fallback vor dem Wachstum entworfen.

3. Supabase: Grenzen von Auth, Postgres, Storage und Edge Functions

Supabase ist mehr als gehostetes Postgres. Auth, Storage, Realtime und Edge Functions gehören zusammen, haben aber jeweils Grenzen.

Supabase-Free-Limits im Juli 2026

Supabase Free bietet je Projekt 500 MB Datenbank, 50.000 MAU, 5 GB Egress, 5 GB Cached Egress und 1 GB Dateispeicher. Eine Organisation kann zwei aktive Free-Projekte halten. Nach einer Woche Inaktivität wird ein Free-Projekt pausiert; der Tarif ist für Validierung und niedrigen Traffic gedacht, nicht als Verfügbarkeitszusage.

Supabase-Pro-Kontingent

Supabase Pro beginnt bei 25 US-Dollar pro Monat. Enthalten sind 100.000 MAU, 8 GB Disk je Projekt, 250 GB Egress, 250 GB Cached Egress und 100 GB Dateispeicher. Bezahlte Pläne enthalten zudem 10 US-Dollar Compute Credits pro Monat. Weitere Projekte, Compute-Größen, Traffic, Storage und Add-ons erhöhen die Rechnung.

Geeignete Einsatzfälle

• Authentifizierung und Nutzer: E-Mail, OAuth, Sessions und RLS-Rechte.
• Geschäftsdaten: Postgres-Relationen, Constraints, Transaktionen und Abfragen.
• Dateispeicher: Uploads, Bilder und Exporte mit Zugriffsrichtlinien.
• Postgres-Trigger, Funktionen und Datenbankmigrationen.
• Edge Functions mit enger Verbindung zu Auth, Postgres und Storage.

Wenn Logik um Supabase Auth, Postgres und Storage gebaut ist, etwa nutzereigene Daten schreibt, verknüpfte Zeilen per Trigger aktualisiert oder Upload-Metadaten speichert, sinkt die Zahl selbst betriebener Komponenten.

Grenzen von Edge Functions

Supabase Edge Functions nutzt eine TypeScript-/Deno-kompatible Runtime für Webhooks, Drittanbieterintegrationen und projektnahe APIs. Aktuell gelten 256 MB Speicher, 2 Sekunden CPU pro Request und 150 Sekunden Idle Timeout. Die maximale Wall-Clock-Dauer beträgt 150 Sekunden auf Free und 400 Sekunden auf Paid.

Wall-Clock umfasst I/O-Wartezeit und ist kein CPU-Budget. Browserautomatisierung, native Multithreading-Bibliotheken, Videoverarbeitung und große Dateiumwandlungen gehören in Background-Worker oder Spezialdienste. Auch Background Tasks bleiben an CPU-, Speicher- und Wall-Clock-Limits gebunden.

Edge Functions oder Workers

• Projektlogik mit enger Bindung an Supabase Auth/Postgres/Storage → Edge Functions.
• Edge-Eingang oder Proxy ohne starke Supabase-Bindung → Workers.

Ein Stripe-Webhook, der eine Subscription-Tabelle und Supabase Auth aktualisiert, ist in Edge Functions direkt. Für Prüfung, Rate Limit und Weiterleitung ist Workers ein unabhängiger Eingang. Zeitintensive Arbeit wird immer eingereiht.

Alibaba Cloud - Top-Wahl für Entwickler, exklusiv 15 % Rabatt auf Lighthouse-Server

15 % Rabatt sichern →Anzeige

Verhalten bei Projektpausen

Supabase pausiert Free-Projekte nach einer Woche Inaktivität. Ein selten genutztes internes Tool muss beim nächsten Request eventuell auf das Fortsetzen warten. Für ein dauerhaft bezahltes Produkt werden Pro, Backups und Migration bewertet. Free ist keine langfristige Architekturgarantie.

4. Node.js: Wann ein klassischer Dienst sinnvoll bleibt

Serverless und Edge reduzieren Serverwartung, beseitigen aber nicht den Bedarf an vollständiger Runtime, Systemabhängigkeiten und dauerhaften Prozessen.

Wann Node.js gebraucht wird

• Browserautomatisierung mit Playwright oder Puppeteer.
• Große Dateien, komplexes Parsing und Tasks mit temporärem Datenträger.
• Native Module oder npm-Abhängigkeiten außerhalb der Edge-Runtime.
• Dauerhafte Queue-Consumer, WebSockets und Admin-APIs.
• Gemeinsames Backend mit einheitlichem Prozessmodell, Monitoring und Ressourcenprofil.

Screenshots, PDF-Erzeugung, Datensammlung, Videotranscoding und große Parser brauchen meist mehr CPU, Speicher, Prozesse oder Dateisystem. Node.js-Dienst, Container oder Task-Plattform passen besser.

Signale für Node.js

Node.js wird relevant, wenn Jobs wiederholt CPU-, Speicher-, Laufzeit-, Bundle- oder Kompatibilitätslimits von Workers oder Edge Functions treffen oder Browserprozesse, native Module, dauerhafte Verbindungen und zuverlässige Queue-Consumer brauchen.

„Länger als 30 Sekunden“ ist kein ausreichender Test. Workers Paid, Cron, Queues, Workflows, Containers und Supabase Functions haben unterschiedliche Limits. Entscheidend ist zuverlässige Ausführung im Ressourcen-, Retry-, Idempotenz- und Beobachtbarkeitsmodell der Plattform.

Wann Node.js nicht nötig ist

• Reine API-Weiterleitung oder Edge-Routing.
• Leichte I/O-lastige Validierung und Datenbank-Writes.
• Keine schwere Dateiverarbeitung, nativen Abhängigkeiten oder langen Verbindungen.
• Noch kein Bedarf, der laufenden Serverbetrieb rechtfertigt.

Workers oder Supabase Edge Functions decken diese Fälle ohne separaten Node-Dienst ab.

Node.js ist nicht veraltet

Eine Edge-Runtime tauscht Einschränkungen gegen wenig Betrieb und globale Verteilung. Node.js tauscht Infrastrukturarbeit gegen Abhängigkeitskompatibilität, Ressourcenkontrolle und dauerhafte Prozesse. Das sind verschiedene Aufgaben. Workers und Supabase schließen zuerst leichte APIs, Webhooks, Auth und Geschäftsdaten; Node.js folgt bei realer Browser-, Datei- oder Abhängigkeitslast.

5. Workers und Supabase: API-Client oder Hyperdrive

Workers und Supabase bilden meist einen Stack aus Edge-Eingang sowie Identität und Geschäftsdaten, statt direkte Konkurrenten zu sein.

Workers mit Supabase kombinieren

Workers übernimmt Weiterleitung, Validierung, Rate Limit und Cache. Supabase Auth und Postgres tragen Identität, Geschäftsdaten und Richtlinien. Das passt zu leichten Abfragen und validierten Writes im ersten Produkt ohne eigenen Server.

Für Supabase Auth, Data API oder Storage reicht supabase-js. Bei häufigem SQL, Transaktionen oder ORM gegen Postgres sollten Datenbanktreiber und Connection Pool statt neuer Direktverbindungen pro Edge-Invocation verwendet werden.

Verbindungsmethoden

Hyperdrive unterstützt Supabase Postgres und reduziert Latenz sowie Verbindungsdruck verteilter Workers. Es ist kein Autorisierungssystem. Datenbankrolle, Tabellenrechte und RLS-Verhalten stammen weiterhin aus Postgres-Zugangsdaten und Policies.

Warnung zu Service-Role-Keys

Service-Role-Keys und serverseitige Secret-Keys von Supabase sind hoch privilegiert und können RLS umgehen. Sie gehören weder in Browser oder Mobile Client noch in öffentliche Repositories oder Logs, sondern nur als Secrets in vertrauenswürdige Backends.

Für Admin-Arbeit wird ein separater serverseitiger Supabase-Client angelegt, damit eine Nutzersession den Authorization-Header und damit das RLS-Verhalten nicht überschreibt. Webhook-Writes, Batches und Admin-Aktionen brauchen minimale Rechte und einen eigenen Audit Trail statt eines universellen Hochprivileg-Keys.

Railway - Moderne Deployment-Plattform, ohne DevOps-Aufwand, in Minuten live

Jetzt starten →Anzeige

Zuständigkeitsgrenze zwischen Edge Functions und Workers

• Starke Bindung an Supabase Auth, Postgres oder Storage → Edge Functions.
• Unabhängiger Edge-Eingang, Proxy, Rate Limit und Routing → Workers.

Die Grenze ist nicht absolut. Entscheidend sind Supabase-Zentrierung von Daten und Rechten, benötigte Cloudflare-Edge-Funktionen sowie der gewünschte Ort für Logs und Deployment. Hochprivilegierte Keys bleiben auf beiden Plattformen Backend-Secrets.

6. Datenzuordnung: Geschäftsdaten, Dateien und Cache

D1, Postgres, KV und R2 speichern Daten, lösen aber unterschiedliche Probleme.

Tabelle zur Datenzuordnung

Nutzer, Bestellungen, Abos, Projekte und Berechtigungen beeinflussen Abrechnung oder Zugriff. Sie gehören in eine Geschäftsdatenbank mit Constraints, Migrationen und Backups. Postgres bietet komplexe Abfragen, Fremdschlüssel, Trigger, Transaktionsintegrität und MVCC. D1 kann leichte relationale Daten tragen, braucht aber eine eigene Prüfung von Konsistenz, Skalierung und Plattformgrenzen.

Dateispeicher wird nicht an einer willkürlichen 1-GB-Schwelle geteilt. Supabase Storage passt zu Nutzerdateien mit Auth und RLS, R2 zu Objekten im Cloudflare-Traffic- und CDN-System. Zugriffsrichtlinie, Egress, Upload-Methode, Transformationen und SDKs entscheiden.

Cache gehört an die Edge, ist aber keine primäre Geschäftsdatenbank. KV eignet sich für Konfiguration und wiederherstellbare Read-heavy-Daten. Existieren Bestellungen oder Berechtigungen nur im Cache, verändert ein Ablauf, Sync-Verzug oder versehentliches Löschen den echten Geschäftsstatus.

Der vollständige D1-, Postgres-, R2-, S3- und SQLite-Vergleich folgt im Datenbankartikel. Hier werden nur Datenkategorien verteilt.

7. Nächste Schritte der Serie

Dieser Beitrag ordnet Backend-Aufgaben zu. Weitere Teile behandeln Deployment, Datenbanken und Storage, Zahlungsintegration sowie Authentifizierungs- und Berechtigungsmodelle.

Verwandte BetterLink-Artikel

Zur Prüfung der Plattformgrenzen helfen der Cloudflare-Pages-Deployment-Leitfaden, Cloudflare Free Plan Limits 2026, die Workers-API-Proxy-Praxis, der Supabase-Einstieg und die Supabase-Edge-Functions-Praxis.

Zuerst eine eigene Zuständigkeitstabelle bauen

Liste fünf Backend-Aktionen auf, die diese Woche live gehen müssen. Markiere „Sofortantwort / Identität und Zugriff / Geschäftsdatensatz / Datei / asynchroner Job / Secret“ und ordne Workers, Supabase, Node.js oder Aufschub zu. Plattformen sind Umsetzungsmittel; Zuständigkeiten und Fehlerpfade entscheiden über ein stabiles erstes Backend.