Skip to main content

Vercel Repriced Four Times in 20 Months: The Predictability Tax Nobody Put in the Spreadsheet

16 min readDora NodaDora Noda
Share

You didn't get a price-hike email. You got a changelog. And then another one. And then two more — each one narrowing what was included, inventing a new meter, or moving a line item you thought was bundled. Vercel didn't raise a sticker price four times since 2024. It did something harder to forecast: it changed what gets measured four times in 20 months.

That's a distinct risk from "Vercel is expensive." Expensive is a number you can budget. Unstable is a process that eats your planning quarter after quarter, even when the new number is lower for some workloads. This post puts the four events on a timeline, reconstructs what each one does to a real mid-traffic Next.js app's invoice, and compares that moving target to the one invoice that didn't need a changelog at all — a flat Hetzner box under Cluster API.

TL;DR — Four repricings, one predictability problem

WhenWhat Vercel changedWhat got narrower or newly meteredEffect on a representative app*
June 25, 2024"Improved infrastructure pricing"Bandwidth split from one pool into three meters: Fast Data Transfer, Edge Requests, Data Cache. Overage clarified at $40/100 GB on Pro after 1 TB includedNo immediate delta for apps under 1 TB, but per-100 GB overage line now explicit — the cliff moves from invisible to metered
Dec 2024Managed Postgres + KV retired; Blob storage repricedPostgres/KV removed (migrate to Neon/Upstash at their own pricing); Blob billed at $0.023/GB-month storage + $0.05/GB transferStorage line that was bundled behind Vercel add-ons becomes a second vendor bill you forecast separately
May–July 2025Fluid Compute + Active CPU pricingBilling switches from wall-clock GB-hours ($0.18/GB-hour, $0.60/M invocations) to Active CPU time — CPU only while code is actually executing, not while waiting on an LLM or DBSSR-heavy apps see lower CPU-hour totals; AI/wait-heavy workloads see 30–95% compute savings vs. wall-clock. New meter to understand: Active CPU ms per function
Sept 2025Credit-based Pro + Universal Credit model20+ discrete limits collapsed into a $20 included usage credit on Pro ($20/seat still applies). Overages bill against credits first, then metered rates: bandwidth $0.15/GB over 1 TB, functions on Active CPU/GB-hours, builds on new Turbo-machine defaultSame sticker ($20/seat) but included usage is now a credit pool you can exhaust on any dimension — a bandwidth spike and a function spike now compete for the same $20

* Representative app for this post: Next.js 14 with ISR, 500k page views/month, ~800 GB bandwidth, ~12M function invocations, ~40 GB-hours wall-clock (pre-Fluid) — median of Vercel Pro case studies. Hetzner comparator: CPX21 (3 vCPU, 4 GB, 20 TB included) €13.44/mo or CX22 €8.21/mo — one invoice, no sub-meters.

The takeaway up front: none of these four changes, in isolation, looks like "a price hike." Together they are a ratchet — a pricing model that can be re-aimed at whatever dimension of your usage is growing fastest, on the vendor's calendar, not yours. A Hetzner box is boring by comparison: it doesn't get cheaper per dimension, it just doesn't move.


What "ratchet pricing" actually means

Most pricing arguments compare levels: "$X on Vercel vs. $Y on Hetzner." Ratchet pricing asks a different question: how often does the ruler itself change?

A ratchet model has three properties:

  1. Narrowing included usage. The headline plan (Hobby free, Pro $20/seat) keeps its name and base price, but what that price includes shrinks — bandwidth caps, function allowances, or bundled storage get smaller or more conditional.

  2. New metered dimensions. A cost that was previously invisible or bundled becomes a separately billed line: Edge Requests distinct from Data Transfer, Active CPU ms distinct from wall-clock, step/storage billing for Workflows (Cloudflare's parallel), or snapshots and private-networking meters (Fly.io's 2026 additions).

  3. Repricing on the vendor's schedule. The tenant doesn't trigger the change by scaling; the vendor ships it as a platform update. Your app can use exactly the same resources in Q2 and Q3 and still see a different invoice because the definition of "a unit" changed.

Why that matters more than level: if Vercel were simply 2x Hetzner and stayed there, you could decide. When the meter count and the included pools change four times in 20 months, forecasting Q4 from Q2's invoice is itself work — re-reading pricing pages, re-instrumenting which meter is now binding, re-optimizing code for a new billing axis. That work is the predictability tax, and no per-GB price comparison captures it.

Render (100 GB → 5/25 GB egress, April 2026) and Fly.io (two new meters, early 2026) show the same ratchet. Vercel is sharpest because the cadence is fastest.


The four events, dated — what actually moved

1. June 25, 2024 — "Improved infrastructure pricing"

Vercel reframed bandwidth. Before: Pro included 1 TB bandwidth, overage at roughly $40/100 GB ($0.40/GB), plus a function bundle. After: bandwidth broken into three granular meters — Fast Data Transfer (edge → user), Edge Requests, and Data Cache — each with its own allowance and overage. Base prices were described as reduced, with Hobby still free-capped at 100 GB.

What to mark: not a price increase; a metering refinement. The tenant now tracks three bandwidth-adjacent meters instead of one. Apps that were comfortably under 1 TB see no delta. Apps that burst on edge hits or cache fills discover the new sub-meters matter. New behavior that shipped alongside: hard spend limits and usage alerts — an acknowledgment that finer meters need finer guardrails.

2. December 2024 — Managed Postgres and KV sunset

Vercel deprecated its managed Postgres and KV offerings, directing users to Neon (Postgres) and Upstash (Redis). Blob storage remains but at its own explicit pricing (Hobby 1 GB storage/10 GB transfer; Pro $0.023/GB-month + $0.05/GB transfer in 2026 schedules). This is not a line-item price change — it's an unbundling. A cost that was previously one Vercel invoice becomes two invoices with two pricing pages, two free tiers, and two overage models to forecast. For the representative app with a modest 20 GB Postgres + 50 GB blob transfer, that is on the order of $15–40/month shifted to Neon/Upstash — not dramatic, but now outside Vercel's $20 credit pool entirely.

3. Mid-2025 — Fluid Compute and Active CPU pricing

At Ship 2025 Vercel introduced Fluid Compute and Active CPU pricing. Before: functions billed on wall-clock GB-hours ($0.18/GB-hour) and per-million invocations. After: billing on Active CPU ms — time the vCPU is actually executing, not idling on an LLM response, DB wait, or fetch.

Why it exists: AI workloads spend most wall-clock waiting. Wall-clock billing taxed idle time; Active CPU doesn't. Vercel claimed up to 95% compute savings on wait-heavy workloads, and its docs note Fluid now powers 45B+ weekly requests.

What to mark: for CPU-bound SSR/API routes, the delta is modest (5–15% savings from better bin-packing). For AI/MCP-style workloads that wait 80% of the time, the delta is large and favorable — but the tenant must now understand and optimize a new meter (Active CPU ms, memory class, concurrency shape) rather than just duration × memory.

4. September 2025 — Credit-based Pro and the $20 Universal Credit

Vercel moved Pro to credit-based billing: Pro is still $20/seat/month, but that $20 is now an included usage credit consumed before overages. Twenty-plus discrete limits collapse into one pool: bandwidth overage ($0.15/GB past 1 TB), functions (Active CPU + GB-hours tiers), builds (Turbo machines now default at $0.126/minute as of Feb 2026), and ancillary meters draw from the same credit first.

What to mark: the sticker didn't move; the exhaustion model did. Previously, bandwidth and functions had separate included pools — a bandwidth spike didn't eat your function allowance. Now a spike in any dimension can exhaust the same $20 credit, and only then do metered overages appear. Forecasting now requires modeling which dimension exhausts the pool first for your traffic shape, not just "are we under 1 TB?"

Together, four changes in 20 months. None announced as "we raised prices." Each announced as "better granularity," "more efficient billing," or "simpler limits." All four require the tenant to re-learn what is measured.


What each revision costs that 500k-view Next.js app

Reconstruct the invoice for the representative app (500k views, 800 GB transfer, 12M invocations, 40 GB-hours wall-clock pre-Fluid). Assume 2 seats on Pro for the team.

LinePre-June 2024 baselineAfter Event 1 (June 2024)After Event 2 (Dec 2024)After Event 3 (Fluid/Active CPU)After Event 4 (Sept 2025 credits)
Seats$40 (2 × $20)$40$40$40$40 base, $20 credit included
Bandwidth (800 GB)Included in 1 TBIncluded (now 3 meters, still under cap)IncludedIncludedIncluded — burns $0 of credit (under 1 TB)
Functions (12M invocations, 40 GB-hours)~$7.20 (GB-hours) + ~$7.20 (invocations) ≈ $14~$14~$14~$6–9 Active CPU (40–60% savings on mixed workload)Drawn from $20 credit first, then metered
Blob/Postgres-adjacentIncluded Postgres/KV bundle ~$0–20~$0–20+$15–40 to Neon/Upstash (outside Vercel)samesame (outside credit)
Vercel-side subtotal~$54–74~$54–74~$54–74 on Vercel + $15–40 external~$46–69 on Vercel + $15–40 external~$46–69 drawn against $20 credit, then overage; effective Vercel charge often $40–49 if under credit

Two reads matter:

  • If your app is under every cap (our 800 GB example), Events 1 and 4 barely move the number — the credit absorbs it. The savings from Event 3 is real. The tax is not on this month's invoice; it's on the next time traffic shape changes.
  • If bandwidth or invocations spike 2x (1.6 TB, 24M invocations — a good launch week), the math changes sharply. Bandwidth overage jumps from $0 (under 1 TB) to ~$90 at $0.15/GB for 600 GB over. Under the old separate pools, that overage was at least predictable as "bandwidth only." Under the pooled credit, that spike also wipes the $20 credit that would have cushioned function overage the same month. The interaction between meters — not any single rate — is what makes Q4 hard to forecast from Q2.

Sensitivity: where the shape matters

Monthly profileVercel-side (seats + overages after credit)External DB/Blob (Neon/Upstash)TotalHetzner CPX21 flat
250k views, 400 GB, 6M invocations (quiet month)$40–44$15–25$55–69€13.44 (~$14.60)
500k views, 800 GB, 12M invocations (baseline)$40–49$15–40$55–89€13.44 (~$14.60)
1M views, 1.6 TB, 24M invocations (launch spike)$130–150 (includes ~$90 bandwidth overage)$25–60$155–210€13.44 (~$14.60) — same box, 20 TB included

The spike row is the point. No code changed. The pricing model did. A team that budgeted "~$70/month on Vercel" in Q2 based on the 500k-view baseline sees 2–3x that in a 1M-view month — not because $0.15/GB is outrageous (it's actually down from the older $0.40/GB), but because 1 TB is a cliff the pooled credit doesn't soften when multiple dimensions spike together. The flat Hetzner line doesn't have a cliff to fall off.

Method note: rates from Vercel pricing/changelog pages and Hetzner Cloud list (Aug 2026). Run your own bandwidth/Active CPU profile against the current meters.


The predictability tax — the cost that never appears on the invoice

If the last section is the level, this section is the drag.

Budget variance. Finance can model "bandwidth $0.15/GB past 1 TB" easily. It cannot model "in nine months Vercel may redefine what counts as bandwidth" without a history lesson. Four redefinitions in 20 months imply a ~5-month mean time between pricing-page audits — each one requiring a pricing-page diff, an architecture review ("are we still billed on wall-clock or Active CPU?"), and a revised forecast. One mid-market platform team estimated half a day per event for pricing review plus instrumentation changes — ~2 days/year of senior-engineer time. At loaded cost, that is $2k–4k/year of forecasting labor before any overage.

Re-optimization churn. Each new meter rewards a different optimization. Wall-clock billing rewarded shorter functions; Active CPU rewards less CPU per request but is indifferent to wait time; pooled credits reward whichever dimension you can pull under the credit first. Code that was optimal under meter N can be pessimal under N+1. Teams report re-tuning DB pooling (Fluid's attachDatabasePool), cache hit rates (Data Cache meter), and build concurrency after each event — work that ships no feature.

Alert fatigue vs. hard limits. Vercel's own answer — hard spend limits and usage alerts — is necessary precisely because the model is harder to predict. Every new meter is a new alert to configure, a new dashboard to watch, a new "which meter is binding this month?" triage. Hetzner has one alert: "disk/CPU high."

Compounding across vendors. Vercel is not alone. Render's April 2026 egress cut (100 GB → 5/25 GB, $0.15/GB over) and Fly.io's early-2026 private-networking + snapshot meters mean a team running one service per PaaS must track three moving pricing pages. The tax scales with vendor count.

The honest counterargument: Vercel's changes lowered costs for many workloads (finer bandwidth granularity, Active CPU idle savings, credit pooling). That's true, and this post's baseline shows it. The tax is not "you paid more every time." The tax is "you had to do work to find out whether you paid more, and you couldn't lock a forecast for longer than a quarter."


Owned hardware doesn't get cheaper per dimension — it just doesn't move

The same 500k-view app on a Hetzner CPX21 (€13.44/month, 3 vCPU, 4 GB, 80 GB SSD, 20 TB transfer) or the smaller CX22 (€8.21/month) looks boring next to Active CPU graphs: no idle-vs-active distinction, no credit pool, no per-100 GB cliff at 1 TB. Twenty terabytes of transfer are included whether they are Fast Data Transfer, Edge Requests, or Data Cache — Hetzner doesn't have those meters. The invoice is the same in the quiet month and the launch-spike month: €13.44.

That is the structural difference. A PaaS can add a dimension (snapshots, private networking, workflow steps, cache operations) because its pricing page is its product surface. A Hetzner box has one product surface: the machine. When Hetzner reprices — and it did, materially, in 2026 on the back of DRAM/HBM supply pressure (CPX/CCX lines up 2–3x in some regions) — it raises the machine price. It doesn't invent a new meter for inter-region traffic, because the tenant's VPC is the tenant's.

This is not "self-hosting is free." It isn't. The cost you pay instead is ops: Cluster API control plane, node provisioning via CAPH, upgrades, on-call, and incident response that a managed PaaS bundles. That ops tax is real and, for many teams, larger than any bandwidth overage. The argument here is narrower: if you have already decided to pay the ops tax — because you want sovereignty, portability, or cost control — the hardware underneath rewards you with a second property no usage-based PaaS can structurally offer: the pricing dimensions don't change on someone else's changelog.

For a concrete shape of that platform: a Cluster-API fleet on Hetzner (what Bex.co ships as its default substrate) gives you Render-style git push ergonomics at the tenant surface with Kubernetes-portable machines underneath. bex.yml declares the app, the control plane reconciles MachineDeployments through CAPH, and the tenant's invoice stays one Hetzner line per node pool — whether the node ran 6M or 24M requests that month. You still do capacity planning; you just don't re-do pricing-page archaeology.


What to do if you're on Vercel today

  • If you stay: turn on hard spend limits before the next traffic spike, put alerts on each of the three bandwidth sub-meters (not just total transfer), instrument Active CPU ms per route (not just wall-clock), and model the $20 credit as a shared pool — budget for the case where one dimension exhausts it and exposes the others. Re-audit the pricing page quarterly; the 5-month cadence suggests the next refinement is never far.

  • If the forecasting overhead is the problem: the fix is not "find a cheaper PaaS" — Render and Fly.io are on the same ratchet — it's to move the meter out of the vendor's control. That's what a fixed-machine fleet does: the only repricing event is a machine-price change, announced once, on Hetzner's schedule, with months of notice and grandfathering. You trade per-dimension optimization for predictability, and for teams where predictability is the binding constraint (regulated workloads, fixed-price contracts, grant-funded projects), that trade is worth making even when the level comparison is close.

  • If you're choosing: price the spike month, not the baseline month. Run the 2x-traffic sensitivity row with your own bandwidth and invocation profile, include the external DB/storage line that left Vercel's bundle in Dec 2024, and add a half-day/quarter line for pricing-page review. Compare that total — with labor — to a flat Hetzner box plus the ops cost you actually pay (whether that's your own on-call or a PaaS like Bex that owns the fleet for you).


The spreadsheet you actually need

The Vercel-vs-Hetzner decision was never "which is cheaper today?" At baseline traffic, Vercel's post-Fluid pricing is defensible — $55–89 all-in for a 500k-view app is not the horror story X threads make it. At spike traffic, the gap widens to 10x because a cliff and a pooled credit compound.

The durable lesson from four repricings in 20 months is that the level comparison has an expiry date. The question that survives the next changelog is not "what does 1 TB cost?" but "who gets to decide what a unit is, and how often?"

A flat box answers that question once. A usage-based PaaS answers it every quarter.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. One Hetzner invoice, no per-dimension meters to re-learn next quarter. Star the repo on GitHub or deploy your first app today.


Sources

All pricing figures as of August 2026.

Related articles

Run this on infrastructure you own

bex is the open-source, AI-native Render alternative — push a git repo and get a running HTTPS service on your own machines.

Get started with bex