What Fluid Compute Solves
Vercel Fluid Compute, which went GA in 2025, is a next-generation execution platform that unifies what were previously separate "Serverless Functions" and "Edge Functions" runtimes. Traditional serverless suffered from the overhead of "1 request = 1 container" and idle billing; Edge Functions were constrained by a 50 MB code size limit and incomplete Node.js compatibility. Fluid Compute adopts a "multi-tenant concurrency" model where a single instance handles multiple requests in parallel and excludes I/O wait time from billing. The result: you can maintain a DB connection while achieving near-edge latency — a combination that was previously a forced tradeoff.
As of April 2026, the `runtime` option in `next.config.ts` is a three-way choice: `"nodejs"`, `"edge"`, or `"fluid"`. Next.js 16 defaults to `"fluid"`, so routes under `/app` run on Fluid unless you explicitly write `export const runtime = "edge"`. Edge Functions have narrowed to niche use cases like WebSocket termination or ultra-low-latency APIs. The old "edge or Lambda?" debate has shifted to "is Fluid enough, or do I need Edge?"
RSC Edge Rendering in Next.js 16
Next.js 16 can now generate streaming React Server Components (RSC) output at Points of Presence. Specifically, it asynchronously flushes HTML and RSC payload per Suspense boundary, reducing TTFB to around 40ms. The critical question is where to place data fetching. RSC allows you to write server-side fetch calls, but the rule of thumb is to avoid direct connections to origin databases — always go through Vercel Data Cache (formerly Request Memoization) or an edge cache layer like Hyperdrive or PlanetScale Boost.
RSC running in the Edge Runtime has constraints: Node.js `fs`, `net`, and `child_process` are unavailable, and cryptography goes through the Web Crypto API. With edge-compatible adapters added in late 2025, Prisma 6 and Drizzle ORM work as-is, but Sequelize and TypeORM are still recommended to stay on Fluid. The 2026 standard pattern is "RSC on Edge for reads, DB writes on Fluid."
```typescript // app/products/[id]/page.tsx export const runtime = "edge"; export const revalidate = 60; export default async function ProductPage({ params }: { params: Promise<{ id: string }> }) { const { id } = await params; const product = await fetch(`${process.env.EDGE_API}/products/${id}`, { next: { revalidate: 60, tags: [`product-${id}`] }, }).then((r) => r.json()); return ( <> <ProductHeader product={product} /> <Suspense fallback={<ReviewsSkeleton />}> <ProductReviews id={id} /> </Suspense> </> ); } ```
Streaming SSR and Partial Prerendering (PPR)
PPR was introduced experimentally in Next.js 14, stabilized in 15, and is enabled by default in 16. It delivers a "static shell + dynamic fill-in" hybrid of build-time and runtime rendering. The static HTML skeleton is served instantly from a PoP, while user-specific content (cart icon, recommendations) remains as Suspense boundaries and is flushed from the server afterward. This lets you maintain CDN cache hit rates while still personalizing the page.
The key implementation pitfall: the moment you reference `cookies()` or `headers()`, the entire tree becomes dynamic. Carelessly calling `headers()` in a layout means the static shell is never generated and every request falls back to full SSR. Regularly audit the `next build` output log for the ratio of "Static (prerendered)" to "Dynamic (on-demand)" and detect drops in your CI pipeline.
Edge Config and CDN-Backed Feature Flags
Edge Config is Vercel's read-optimized JSON store, readable in under 1ms from Edge Runtime. Rather than reaching for a SaaS product like LaunchDarkly or Statsig, building an in-house feature flag system on Edge Config + Vercel Flags SDK has become the pragmatic 2026 answer. Writes propagate to all regions within seconds via the management API; reads are embedded directly in the runtime Isolate with no network RTT.
The Flags SDK handles both A/B testing and flag evaluation through the same API and keeps identity consistent between RSC and client components. Concretely: middleware pins a user ID in a cookie, RSC evaluates `flag("new-checkout").bucket(userId)`, and the result is passed as a search param to child components. This delivers an SPA-like experience — the variant decided server-side on first load persists through navigation — entirely at the edge.
```typescript import { flag } from "@vercel/flags/next"; import { get } from "@vercel/edge-config"; export const newCheckout = flag<boolean>({ key: "new-checkout", async decide({ entities }) { const config = await get<{ rollout: number }>("new-checkout"); const userId = entities?.user?.id ?? "anon"; return hash(userId) % 100 < (config?.rollout ?? 0); }, }); ```
Edge Config size limits were expanded in late 2025 to 512 KB per store and 10 stores per project. In practice it stores values that update on second-to-minute timescales — feature flags, price tables, region-specific blocklists — and is not suited for high-frequency updates like user profiles. Those belong in KV or Redis.
Observability and Source Maps
Fluid Compute natively supports OpenTelemetry auto-instrumentation: import the `@vercel/otel` package and traces flow to Datadog, Honeycomb, or Grafana Cloud automatically. Fetches inside RSC automatically get their own spans; Web Vitals (LCP, INP, CLS) are collected as a separate RUM stream. Starting in 2026, Vercel Observability Plus lets you safely upload production source maps and resolve stack traces to TypeScript line numbers.
For error budget management, the standard pattern is defining SLOs in Vercel Monitoring's query language (VQL) and routing burn-rate alerts to Slack or PagerDuty. Putting Edge Function p99 latency, Fluid concurrent invocations, and Data Cache hit rate on the same dashboard lets you detect PPR static-rate drops or cache miss spikes early. The edge game isn't just about being fast — it's about staying fast.