Edge Config gives Vercel-hosted functions a globally distributed key-value store that returns configuration data in under 15ms at P99, frequently under 1ms, fast enough to put feature flags and routing rules directly in the request path without an origin hop. The trade is a 10-second global write-propagation window: a flag you flip can race against cached reads and route traffic to a region you just disabled.
How fast are Edge Config reads?
Edge Config reads complete within 15ms at P99 and often land under 1ms, according to Vercel’s Edge Config documentation, which is fast enough to evaluate a feature flag inside middleware on every request without bouncing to an origin database.
The low latency comes from co-locating the config data with the compute at each edge region, so the read never leaves the point of presence. The optimizations that produce the sub-1ms typical are on by default for the Edge and Node.js runtimes; Ruby, Go, and Python runtimes require manual enablement. For a per-request flag check, that is the difference between a check you forget about and one that surfaces in your P99 traces.
The number that matters for capacity planning is the 15ms P99, not the “often less than 1ms” headline. Tail latency is what breaks middleware budgets, and 15ms at P99 is competitive with a local Redis hit and well under a networked Postgres read.
What does the 10-second write-propagation window mean for your flags?
Writes to Edge Config take up to 10 seconds to propagate globally across Hobby, Pro, and Enterprise plans, per Vercel’s Edge Config limits, and during that window reads anywhere in the world can return the previous value.
This is not regional eventual consistency you can reason about per-region. It is a worldwide window. A flag flipped at 12:00:00 can still serve the old value at 12:00:09 in every region at once, including the one you wrote from. For config that changes slowly, a quarterly copy edit or a maintenance toggle you flip and then wait on, 10 seconds is irrelevant. For config that gates live traffic, a kill switch on a region that is erroring or a rollout percentage you are dialing back mid-incident, 10 seconds is precisely the window in which the system does the thing you are trying to stop.
You disable region fra1 because it is returning errors. For up to 10 seconds, every edge PoP holding the old value keeps routing requests there. You have taken the action. The system has not caught up.
What does Edge Config cost, and when does it add up?
Pro plans bill per unit at $0.000003 per read and $0.01 per write, following Vercel’s November 2025 pricing change; Hobby includes 100,000 reads and 100 writes free.
A read fires every time a request evaluates a flag, so the cost is linear in request volume. At 10 million monthly reads that is $30 (10,000,000 × $0.000003); at 100 million it is $300; at a billion it is $3,000. None of those figures is alarming alone, but the cost scales with traffic and is easy to overlook because the read is the entire point of the store. Writes at $0.01 each are cheap for typical flag-flipping volumes, though an integration that writes on every event or an automation that writes per config change can accumulate writes faster than a manual operator would.
Store size is the harder ceiling: Hobby gets 8KB, Pro 64KB, Enterprise 512KB, with a maximum of three stores per project on Pro, per the limits documentation. That holds thousands of boolean flags and a healthy set of routing rules, but it rules out using Edge Config as a general-purpose cache or a store for per-user state.
Edge Config vs Upstash Redis: which wins on latency and price?
Upstash Redis averages about 2ms latency from edge workers and about 18ms from Lambda, at $0.20 per 100,000 commands on pay-as-you-go, per Anand Thakkar’s benchmarks.
On raw read latency, Edge Config’s sub-1ms typical beats Upstash’s ~2ms edge read, though both sit comfortably inside the middleware budget. On price, Upstash works out to $0.000002 per command ($0.20 ÷ 100,000), about a third cheaper than Edge Config’s $0.000003 per read. The deciding factors are not the marginal latency or the marginal cost. They are portability and write behavior.
| Dimension | Edge Config | Upstash Redis |
|---|---|---|
| Typical edge read | <1ms (often), 15ms P99 | ~2ms edge, ~18ms Lambda |
| Cost per read | $0.000003 | $0.000002 ($0.20 ÷ 100K) |
| Size ceiling | 64KB (Pro) | MB–GB tiers [unverified] |
| Portability | Vercel only | any runtime, any cloud |
Upstash is a real Redis client. It runs from any runtime on any cloud. Edge Config only works on Vercel, and if your code ever leaves the platform, the SDK travels with it as dead weight. On writes, Edge Config’s 10-second global window applies no matter where you read from; Upstash’s write-propagation behavior is not characterized in the available sources, so benchmark it directly if read-after-write latency matters to your use case [unverified].
Edge Config vs Postgres: when is an indexed read fast enough?
Postgres with PgBouncer adds about 5 to 20ms per indexed read, per BuildMVPFast’s analysis, fast enough for server-side flag checks but on the high end for per-request middleware evaluation.
The question is where in the stack the check lives. If flags are evaluated once per request in middleware that runs before routing, 5 to 20ms per request is a real tax: at the tail it is worse than Edge Config’s 15ms P99, and it hits every request. If the check happens once deep in a handler or once per session, the Postgres read is cheap and you get strong consistency and transactional writes at no extra architectural cost. Flags also stay alongside the rest of your data, queryable, backed up with the database, and free of a separate propagation model.
The case for Postgres is the case against a second source of truth. When flags must stay consistent with user or billing state already in the database, an eventually-consistent edge store reintroduces the races that a transactional database exists to prevent.
What race conditions does eventual consistency introduce?
The core failure mode is a read returning a stale value inside the 10-second propagation window, which for routing flags means requests continue to hit a target you have already disabled.
Three patterns recur. The kill switch: a region you disabled keeps receiving traffic for up to 10 seconds, as above. The rollout: you drop a percentage from 10% to 0% to halt a bad build, and for up to 10 seconds the old percentage is live and new users still enter the cohort. The most damaging is the config-dependent write: a request reads a stale flag, takes a code path, and commits a side effect (charges a card, sends an email, mutates a record) based on old config. The staleness is not visible. The request succeeded, the write committed, but the decision was made on state the system had already abandoned.
The mitigations all accept the window rather than fight it. Treat a flag write as asynchronous: flip it, then wait, via a health check or a fixed delay past the 10-second bound, before depending on the new value. Do not let an Edge Config flag gate an irreversible action without an independent consistency check; for a charge or a destructive mutation the flag is a hint and the database transaction is the source of truth.
When should you not use Edge Config?
Edge Config is the wrong tool when the config must stay consistent with a transactional database, when it needs to survive outside Vercel, or when it outgrows the size ceiling.
If the flag gates an irreversible or money-moving action, the 10-second stale-read window is a liability that outweighs the latency win; origin consistency matters more than edge speed. If you run on multiple platforms or might leave Vercel, the lock-in is a concrete cost: the documentation states plainly that Edge Config only works on Vercel, and the portable alternatives are embedded JSON, remote JSON, or environment variables, each less capable. If your config exceeds 512KB or needs more than three stores on Pro, you have crossed into general-purpose cache territory and Redis is the right shape. And if your reads are infrequent, per-session rather than per-request, the latency advantage over Postgres vanishes and you are carrying a second store for savings you cannot observe.
Edge Config earns its place for high-frequency, low-churn config that lives entirely inside the Vercel request path: per-request feature flags, A/B routing rules, maintenance toggles, small lookup tables. For everything else, the consistency model and the platform lock-in cost more than the read latency saves.
Frequently Asked Questions
Can I use Edge Config outside Vercel, or with Python, Go, or Ruby functions?
No. Edge Config is Vercel-only; the SDK has no backend to call if you leave the platform. The sub-1ms optimizations are on by default for Edge and Node.js, while Ruby, Go, and Python require manual enablement in project settings and may not hit the same P99. If you need portability, use build-time JSON, a remote JSON fetched on an interval, or environment variables.
How does Upstash Redis handle writes compared with Edge Config’s 10-second window?
Edge Config documents a worldwide 10-second ceiling; Upstash Redis does not publish an equivalent propagation bound. Redis offers commands such as WAIT if you need to confirm a write has reached replicas, though that trades away the latency win. If read-after-write consistency matters, benchmark Upstash directly rather than assume it matches Edge Config’s documented window.
What is the cheapest possible Pro bill if every request checks one flag?
Pro has no included reads, so one read costs $0.000003. At one request per second for a month, a single flag check generates about 2.6 million reads and roughly $7.80. Hobby covers 100,000 reads and 100 writes free, so a low-traffic side project can stay at zero cost.
How do I prevent a stale Edge Config flag from triggering duplicate charges?
Treat the flag as a routing hint, not an authorization gate. Put an idempotency key or a database row-version check in the transaction path, so a request that sees the old flag still cannot commit the same charge twice. A real circuit breaker should fail closed at the origin, not rely on edge propagation.
If Edge Config’s consistency window becomes unacceptable, is Postgres the obvious replacement?
Postgres removes the 10-second propagation problem, but it reintroduces a database round-trip and connection management in the request path. At high RPS you may need PgBouncer plus read replicas, and a single-region Postgres does not give you edge-local reads. Distributed Postgres such as CockroachDB or Yugabyte can, but adds operational complexity that cancels Edge Config’s zero-ops appeal.
