Next.js and Edge Config

The plain-language idea

Edge Config (Vercel's implementation) is a small, read-optimized key-value store built for one specific job: answering a config or feature-flag read fast enough that doing it on every single request doesn't noticeably add latency. The trick isn't a faster network call — it's that there's barely a network call at all. The data is replicated out to every edge location ahead of time, so a get() is read from a local copy, not fetched from a database server somewhere and sent back over the wire. A normal database read has a real round trip baked in: open or reuse a connection, send a query, wait for a response, across however many hundred miles sit between the request and the database's region. Edge Config reads are commonly sub-millisecond; a database read over a network is usually tens of milliseconds at best, more under load or cross-region.

That gap only matters when the read sits on a hot path — code that runs on every request, not once per session. A feature flag checked inside proxy.ts to decide whether to show a new layout is a hot-path read: it runs on literally every page view. A user's notification preferences, fetched once when a settings page loads, is not — a normal database query is completely fine there, and reaching for Edge Config would be solving a latency problem that read never had.

See it in a real thing: a maintenance-mode flag checked on every request

// proxy.ts
import { NextResponse, type NextRequest } from "next/server";
import { get } from "@vercel/edge-config";

export async function proxy(request: NextRequest) {
  const maintenanceMode = await get<boolean>("maintenanceMode");

  if (maintenanceMode && !request.nextUrl.pathname.startsWith("/maintenance")) {
    return NextResponse.rewrite(new URL("/maintenance", request.url));
  }
}

This runs before every matched request in the app. Swap get("maintenanceMode") for an equivalent database query and you've added a real, measurable connection-plus-round-trip cost to every page load in the app, not just the one request where someone actually flips the flag — the cost is paid by every visitor, to answer a question that changes maybe a few times a year.

What people usually miss

Watch out

• Edge Config is read-optimized and eventually consistent, not a general-purpose database. Writes propagate to every edge location on a short delay rather than instantly, and there's no transaction support — it's built for "this value is read constantly and written rarely," not for anything resembling user data.
• It has a real size limit per store, by design. It's meant to hold a handful of flags and small config values, not a product catalog or a user table — reaching for it because "reads are fast" for something that grows unbounded is the wrong tool for the job.
• The latency win only exists for hot-path reads. Caching a single settings-page fetch behind Edge Config instead of a normal query adds complexity for a read that was never the bottleneck — the entire justification is "this runs on every request," and if that's not true, a database read was already fine.
• "Edge" in the name refers to data replication, not code execution location. A route reading Edge Config can run on the Node.js runtime, same as any other route; nothing about using this data store requires or implies the deprecated Edge Runtime.

Why this matters in interviews

"We want to roll out a new nav layout to 10% of users with a flag we can flip instantly, without slowing down every single page load" is the exact scenario Edge Config exists for, and a candidate who reaches for "just add a column to the users table and query it in proxy" is correctly describing a solution that works, while missing that it reintroduces a database round trip into the single hottest code path in the app — the strong answer names the latency tradeoff specifically, not just "use a faster database."