Yes, but only under conditions most teams should verify before budgeting around it. Vercel’s OpenEvidence customer story reports a 90% reduction in serverless spend with Fluid compute, and the claim is plausible given the workload involved: a stateless, read-heavy clinical search frontend where requests spend much of their time waiting on databases and AI backends. What it is not, at least not yet, is a benchmark. Every number in the claim comes from a single Vercel marketing case study: there is no published baseline spend, no statement of what the 90% is measured against, and no independent replication. The same source also notes that Vercel accounts for less than 5% of OpenEvidence’s total infrastructure spend, which means the headline figure applies to a thin request-serving slice of a much larger stack.
That combination, a large relative number on an unstated denominator covering a small cost slice, is the pattern worth learning to audit. This article decomposes each claim in the case study into the architectural precondition it depends on, then checks those preconditions against independent serverless research to find where the economics reverse.
What the case study actually claims
The story is genuinely impressive on its own terms. VP of Engineering Micah Smith put it this way in Vercel’s OpenEvidence case study: “We reduced our serverless spend by 90% while maintaining the same performance, and even as we’ve scaled up to 1000x growth, Vercel is less than 5% of our overall infra spend.” The workload behind the quote is large: the same study reports more than 20 million clinical consultations in January 2026 and more than 100 million Americans treated by doctors using the platform in 2025.
Two operational claims accompany the cost figure. On deploy speed, Engineering Lead Kush Khosla says in the case study: “If I push a frontend change, I know that 650,000 doctors will see that change in about five minutes.” On elasticity, the study describes a TikTok spike of roughly two million views in under a week, during which “Response times stayed fast and error rates remained near zero, and with no additional capacity to provision, he went back to his work.”
Three things deserve care before these numbers travel into a migration decision. First, the 90% is a relative reduction on an unstated baseline. The study does not say whether it is measured against Vercel’s prior per-invocation pricing or against another platform, so it cannot be directly compared to a container bill without that denominator. Second, the case study’s under-5%-of-infra-spend admission scopes the claim: the AI inference and other heavy computation sit off-platform, so Fluid compute’s savings cover only the request-serving layer. Third, the spike anecdote is an elasticity claim, not a cost claim. Absorbing a burst without provisioning is operationally valuable, but it says nothing about whether the monthly bill went down. Do not let it stand in for the 90% spend figure.
How Fluid compute changes the bill
The mechanism Vercel attributes the savings to is specific enough to reason about. Per the case study: “Fluid compute lets multiple requests share a running function instance, so it can handle other work while a request waits for another service, such as a database or an AI backend, to respond. With Active CPU pricing, that waiting time doesn’t incur CPU charges, though memory remains billed while requests are in progress.”
Two consequences follow. The first is that this pricing model specifically rewards wait-dominated requests: workloads where a function’s CPU sits idle while an external service does the work. Clinical search against an AI backend is almost a canonical example. The second is the quiet caveat at the end of the quote: memory is still billed while requests are in progress. Waiting is not free, only CPU waiting is. A workload with long waits and large resident memory per request will accumulate a real bill under Active CPU pricing, and the case study offers no data on how that accumulated for OpenEvidence over time.
A transferability checklist for the headline claims
Each claim in the case study rests on a different precondition, and conflating them is where vendor numbers do their damage.
| Claim | Precondition it depends on | Where it likely fails |
|---|---|---|
| 90% serverless spend cut | Stateless, short requests dominated by external-service waits, on per-request or Active-CPU pricing | Long-running requests, data-heavy pipelines |
| Five-minute change propagation to 650K doctors | Independently deployable frontend surfaces on an automated build-and-deploy platform | Monolithic backends, stateful services with migration steps |
| Spike absorbed with no added capacity | Spiky, concentrated traffic that an elastic platform can scale horizontally | Long response times, where the migration study below found fixed-cost deployments cheaper |
The concentration half of that precondition has independent support. A large-scale FaaS trace analysis found that “the top 10% of functions accounting for over 90% of requests” in both the Azure21 and Huawei23 traces, and comparable skew appears in every platform it compares. Burstiness is a separate property, and the same analysis warns that provisioning “cannot rely on a universal assumption of burstiness”: Azure19 and Huawei23 stay within 2x of their average load, while Azure21 spikes reach 25x the mean and Globus24 reaches 310x. OpenEvidence’s TikTok spike, roughly two million views in under a week, is the kind of event those upper magnitudes cover, and absorbing it without provisioning is exactly what elastic platforms are built for. What the trace data does not tell you is anything about cost: burst absorption is an operational property, not a billing one, and a workload that is bursty and wait-dominated and data-light is a narrower intersection than “serverless traffic” generally.
The deploy-speed row deserves a note of discipline. Five-minute propagation is a developer-velocity claim, not a cost claim. It may be the most durable benefit in the story for a team shipping daily, but it should not be allowed to imply savings in a cost argument.
Where the math flips
The strongest reason not to generalize the 90% figure comes from independent research on workloads that look nothing like OpenEvidence’s.
An IoT-platform migration study comparing Google Cloud Run, GKE, and OpenWhisk found Google Cloud Run had the lowest cost per 1,000 requests across its tested scenarios, which superficially supports the Vercel story. But the same paper draws the boundary explicitly: “invocation costs with GCR will not be cheaper if the request response times become significantly higher than the GKE and OW deployments. For these scenarios, the fixed cost structure benefits the other two deployment strategies.” Long-running requests tip the economics toward fixed-cost deployments. The study also hit a hard wall on statefulness: “WebSocket and MQTT protocols are inherently stateful which prevented their adaption into OW and GCR functions.” If your application holds persistent connections, this class of migration is not merely less cost-effective; in that study it was not possible at all.
A second cost driver is invisible in a read-heavy search workload: “transmitting data via S3 and ElastiCache in a MapReduce application’s shuffle phase can account for 70% to over 99% of the total processing cost,” a study of data-intensive serverless workflows found. Active CPU pricing says nothing about data movement between functions. A team migrating an ingestion or shuffle-heavy pipeline and expecting Fluid-style savings would be optimizing a small fraction of the bill, not the part that dominates it.
One caution applies in both directions: these studies tested Cloud Run, OpenWhisk, GKE, and Azure Functions traces, not Vercel Fluid compute. They establish where serverless economics tend to break, not how Vercel’s specific pricing behaves. Neither side of the comparison has been independently measured on Fluid compute.
Five questions to ask of any serverless cost claim
The reusable method here is to interrogate the denominator before the number. For the OpenEvidence story, or the next vendor case study with a dramatic percentage:
- What is the baseline? Ninety percent of what, measured how? The case study leaves the denominator unstated, which makes the figure non-comparable.
- What slice of total spend does it cover? Here, the case study puts Vercel under 5% of OpenEvidence’s infra spend. A 90% cut of that slice is at most a 4.5% reduction in total infrastructure cost, on the study’s numbers, still worthwhile, but a different headline.
- Is the workload stateless with short, wait-dominated requests? That is the intersection Active CPU pricing rewards. Persistent connections or long-running compute move you toward the failure cases the IoT study documents.
- How much of the bill is data movement? If inter-function transfer dominates, CPU pricing mechanics are the wrong lever entirely.
- How long does a typical request run? This is the boundary the IoT migration study actually documents: Cloud Run was cheapest across every load scenario it tested, but its invocation costs “will not be cheaper if the request response times become significantly higher than the GKE and OW deployments.” Long response times, not traffic shape, are what flipped the economics in that study.
Practical verdict
Treat the case study’s 90% figure as a real but narrow vendor-reported outcome for one stateless, read-heavy, bursty workload, not as a number to plan around. I would take it seriously as a reason to run a proof of concept if your service looks like OpenEvidence’s: short requests, heavy waiting on external APIs or inference backends, independently deployable surfaces. I would discount it heavily for long-running ingestion, WebSocket-heavy products, or pipelines where data movement dominates, because the independent evidence points the other way on all three. And for any workload, the honest next step is a workload-specific cost model: the case study provides no baseline spend, no per-request breakdown, and no independent measurement, so no migration decision should rest on it alone.
Frequently Asked Questions
What is the baseline for the 90% serverless spend reduction?
First, the 90% is a relative reduction on an unstated baseline. The study does not say whether it is measured against Vercel’s prior per-invocation pricing or against another platform, so it cannot be directly compared to a container bill without that denominator.
What portion of OpenEvidence’s total infrastructure spend does Vercel cover?
The same source also notes that Vercel accounts for less than 5% of OpenEvidence’s total infrastructure spend, which means the headline figure applies to a thin request-serving slice of a much larger stack.
Does Fluid compute charge for CPU time while a request is waiting?
Per the case study: “Fluid compute lets multiple requests share a running function instance, so it can handle other work while a request waits for another service, such as a database or an AI backend, to respond. With Active CPU pricing, that waiting time doesn’t incur CPU charges, though memory remains billed while requests are in progress.”
Join the discussion
Share a useful perspective or ask a question about this article.