Fluid Compute statt Edge Functions

Bis Anfang 2025 war unsere Default-Antwort auf „wo läuft das?" Edge Functions. Inzwischen ist sie Fluid Compute. Hier ist, warum.

Was sich geändert hat

Vercel hat 2025 Fluid Compute als neuen Default eingeführt. Auf dem Papier ein graduelles Update, in der Praxis eine ziemlich grundlegende Architektur-Änderung:

• Voller Node.js statt der eingeschränkten Edge-Runtime. Kein „Modul X läuft nicht weil V8-Isolate"-Geraffel mehr.
• Instance-Reuse über concurrent Requests. Eine Function-Instanz kann mehrere gleichzeitige Requests bedienen — keine Eins-zu-Eins Mapping mehr wie bei klassischen Serverless.
• Graceful Shutdown + Request-Cancellation als First-Class-Features.
• 300s Default-Timeout auf allen Plans, statt der alten 60-90s.
• Active CPU Pricing — abgerechnet wird tatsächliche CPU-Zeit, nicht Wall-Clock-GB-Sekunden.

Das bedeutet konkret: der Hauptgrund warum Edge Functions existierten — kalte Region-Latency in Sub-100ms — wird von Fluid Compute mit (fast) der gleichen Latency abgedeckt, aber ohne die ganzen Edge-Limitierungen.

Was wir bei der Migration gemerkt haben

1. Cold Starts sind kein Thema mehr

Klassische Serverless: jedes Mal ein neuer Container, jedes Mal Cold-Start (200-2000ms je nach Sprache).

Edge Functions: kein Cold-Start, aber V8-Isolate-Limits — keine Native-Module, keine fs-Operationen, kein längerer Code.

Fluid Compute: Die Instanz wird über mehrere Anfragen gehalten, neue Anfragen landen auf einer warmen Instanz. Wie hoch der Anteil warm bedienter Anfragen ausfällt, hängt am Verkehrsmuster — bei gleichmäßiger Last geht er gegen eins, bei seltenen Einzelaufrufen bleibt der Kaltstart. Eigene Messwerte nennen wir hier nicht: dafür bräuchten wir ein Projekt dieser Größenordnung im Dauerbetrieb.

2. Streaming wird trivial

Auf Edge mussten wir für unseren AI-Chat-Endpoint Streaming via Web-Streams API basteln. Funktionierte, aber bei Provider-Wechsel war's jedesmal wieder Anpassung.

Auf Fluid Compute: native Node.js-Streams, das AI SDK kümmert sich um den Rest. Der Handbetrieb um die Web-Streams-API entfällt ersatzlos.

3. Native Module sind wieder erlaubt

Ein typischer Fall ist sharp für die Bildskalierung. Auf Edge ist das ausgeschlossen und zwingt zu einem eigenen Dienst mit eigener Auslieferung. Auf Fluid Compute genügt npm install sharp.

Gleiches Pattern für: pdf-lib, jsonwebtoken, argon2, better-sqlite3 als embedded Cache. Alles was Edge unmöglich machte.

4. Active CPU Pricing zahlt sich aus

Ein Endpunkt, der ein Sprachmodell anspricht, wartet die meiste Zeit — auf den Modellanbieter, in anderen Aufbauten auch auf eine Datenbank. Das alte GB-Sekunden-Modell stellte die gesamte Wanduhrzeit in Rechnung, Active CPU nur die tatsächliche Rechenzeit. Bei einer wartelastigen Route ist das der ganze Unterschied.

Wie stark das durchschlägt, hängt am Verhältnis von Wartezeit zu Rechenzeit. Bei einem Endpunkt, der überwiegend auf einen Modellanbieter wartet, ist der Unterschied erheblich — eine belastbare Zahl dazu können wir erst nennen, wenn ein Projekt dieser Größenordnung bei uns im Betrieb ist.

5. Graceful Shutdown ist ein riesen Quality-of-Life

Sie können jetzt signal-aware Code schreiben, der bei Deployment-Rollover sauber aufräumt — DB-Connections schließen, In-Flight-Jobs an Queue zurückgeben, Final-Metrics flushen. Edge konnte das nicht. Fluid kann's.

Für einen Worker an einer Queue heißt das: Wird mitten im Auftrag ausgeliefert, geht er nicht verloren, sondern wandert zurück in die Warteschlange.

Wann wir trotzdem nicht auf Fluid migrieren

Zwei Edge-Cases (Wortspiel beabsichtigt) bleiben:

Sub-50ms latency-sensitiv und logikfrei

Wenn Ihr Endpoint nur einen Header lesen, einen Cookie setzen und einen Redirect schreiben muss — z.B. ein A/B-Routing oder eine Geo-Personalisierung — ist eine Edge Function (oder Routing Middleware) immer noch ~30-50ms schneller, weil sie näher am User läuft. Bei sehr hohem Traffic kann das eine reale UX-Verbesserung sein.

Globale Replikation mit minimalen Compute

Static-Site-Header-Manipulation, Cache-Decisions, kleine Auth-Token-Validation — Sachen die in jeder Region nahe am User stattfinden müssen, aber praktisch null Compute brauchen. Fluid läuft in einer Region, Edge global.

Beide Fälle sind Ausnahmen und betreffen einzelne Endpunkte, nicht die Regel. Die Vorgabe bleibt Fluid Compute.

Was Sie daraus mitnehmen

Wenn Sie in einem Vercel-Projekt heute noch Edge Functions als Default verwenden, fragen Sie sich pro Endpoint: brauche ich Sub-50ms regional? Brauche ich globale Replikation?

Wenn die Antwort zweimal Nein ist, gehört der Endpoint auf Fluid Compute. Sie gewinnen Modul-Freiheit, Streaming-Simplicity, Cost-Reduction und Graceful-Shutdown.

Edge Functions waren die richtige Antwort 2022. Fluid Compute ist die richtige Antwort 2026.