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: Instance wird über mehrere Requests gehalten, neue Requests landen auf einer warmen Instance. Bei uns sind ~80% aller Requests jetzt warm-served, P99-Cold-Start liegt um 200ms — und das nur beim allerersten Hit nach Idle.

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, der AI SDK kümmert sich um den Rest. Code ist 30% kürzer, gleiches Verhalten.

3. Native Module sind wieder erlaubt

Ein Projekt brauchte sharp für Image-Resizing. Auf Edge war das ein Hard-No (eigener Service, eigener Deployment-Pipeline). Auf Fluid Compute: npm install sharp, in der Function importieren, fertig.

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

Unsere AI-Chat-Function ist die meiste Zeit am Warten — entweder auf den AI-Provider, oder auf die DB. Mit dem alten GB-Sekunden-Modell zahlten wir für die ganze Wall-Clock-Zeit. Mit Active CPU zahlen wir nur die ~5-15% tatsächliche CPU-Zeit.

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.

Wir nutzen das z.B. für unsere Vercel-Queues-Worker — bei einem Deploy mid-job verlieren wir den Job nicht mehr, sondern requeuen ihn graceful.

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 in unseren Projekten einstellige Prozentsätze der Endpoints. Default: 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.