I have no idea what sort of bill I can expect with new costs for "edge network routing" or "incremental static regeneration" (neither of which I understand nor want).
I agree, the network part looks overly complicated to me as well.
Bandwidth was at least relatable to some extend. But now it looks like one needs to combine requests and client traffic as well as server traffic.
It wonder how that works if you proxy another vercel site through a vercel project. I.e. a nextjs projects proxies /docs to a docusaurus page. Because as of today the billed the bandwidth and requests twice :-(
Vercel gets a lot of shit for its pricing, but man from a developer experience standpoint, they are impossible to beat. As a developer first, devops distant fourth or fifth, it's such a pleasure when I get to work in the Vercel ecosystem and I'm happy to pay extra for them to keep improving the experience, but this reduction is welcome :)
I am still looking forward to have the same range of choices in Vercel Functions as in other serveless cloud environments, specially since they seem to build up on top of AWS Lambda and AWS Linux containers.
Right now it is hope the community offerings are good enough, or create a build image from scratch myself.
Not really "developer experience that is impossible to beat".
Vercels hosting is ok. I prefer cloudflare and AWS but vercel is still best for next.js first class support. Especially on newest versions. For instance, server functions currently don’t work on cloudflares nextjs hosting. There’s some discussion about it on discord and GitHub. However, once something becomes the new fad and takes over from nextjs, I’m not sure what vercel will do.
Also checking the vercel page, they have so many investors, how do they all expect a company predicated on a JavaScript framework to be around in 10 years.
Thanks to the deals that have done with several CMS companies, they are now pretty much the default option when using one of those CMS, if one wants tier 1 tooling support for all their workflows.
Example, it used to be when using Sitecore, most of its extensions points would be .NET, now in their SaaS products, .NET is 2nd class, if you really want to use their tooling, without filling in the gaps yourself, the answer is Next.js.
For a small subset of customers (~8%), these pricing changes are projected to increase bills — most of them $5 or less. For all customers with projected increases, new metrics will be free for the first 3 months. Happy to work with you on optimizing your usage further: lee at vercel dot com.
Question on the free Hobby plan: I'm assuming these included amounts are per month? Or per account? The documentation isn't explicit. https://vercel.com/docs/accounts/plans/hobby
Same thing here. Would be great if the email gives an idea of what the estimated cost will be from each service. Guess we will just have to wait for the first bill.
Before these changes go live (and before the grace period begins) you'll be able to see your current pricing vs. new pricing in the dashboard, so you can optimize from there.
Also seeing a 400% increase in pricing after this.
Mostly due to cache reads / writes if I had to guess, the dashboard isn't showing any data currently.
Overall, it's really not clear how this can be optimized.
It's... cache... You could have less cache writes, but it means your users see stale content, which isn't an acceptable solution.
The wording that 92% of people see smaller bills since many people host projects that aren't really being used, anyone who has traffic is going to get higher bills.
The tone of the email was a bit strange for a $960 a year increase suggesting we optimise but not yet providing what the cost increases are from. I appreciate we will get the updated usage metrics later in the month but it makes it slightly hard to explain to management why costs are increasing.
Most of our increases I assume will be the data cache pricing and the only real way to optimise that is to move data fetching out of data cache and use our own cheaper caching layer.
Hey, I'm on the Vercel team. You're right that we will have visibility for these pricing changes in the dashboard, but I'm happy to work with you on this before then. If you're already using ISR, one easy optimization today is to revisit how frequently you are writing (e.g. if it's every 3 seconds, is that necessary?) and potentially explore moving to the on-demand version of ISR.
It’s a e-commerce style site with ISR. Product pages are cached for 24h with pricing fetched on the client to save the revalidate. I think I worked out what the price increase is though and it’s the edge network £2.40 (London) per million requests. From what I can tell most requests are bots and scrapers so it might not be too easy reduce. The pricing actually seems quite high when compared to other CDNs but I might have misunderstood it.
New billing primitives. Cost per invocation on functions and edge requests where it used to included in GB/h and bandwidth.
Cost per cache read and write instead of lumping it all in the bandwidth bill.
My reading is that the criticism of the bandwidth egress fees and it's inevitable unfavorable comparisons has hit home.
Only they were using that bucket for more than just egress. So they are breaking charges apart and this is going to have winners and losers from their customer base.
Reminds me of cloudflare pricing. They don't charge you bandwidth but do charge for invocations and if you do the math on how they bill invocations, the egress is in there - you are not escaping it. But the press of no egress fees is nice.
ISR is just a fancy way to say Cache Hits with SWR headers? So you can mitigate most of the Read cost by either:
* Not using SWR headers
* Putting free tier Cloudflare in front of your Vercel instance(s)
You can improve the Write cost by having longer SWR cache durations. Folks that are seeing a cost increase likely have high traffic volume, a short SWR duration.
Edge Network Routing is also a bit nebulous. I would love to see this better defined, as it's not 100% clear what contributes to volume here.
Readit News
https://vercel.com/docs/pricing
I have no idea what sort of bill I can expect with new costs for "edge network routing" or "incremental static regeneration" (neither of which I understand nor want).
Bandwidth was at least relatable to some extend. But now it looks like one needs to combine requests and client traffic as well as server traffic.
It wonder how that works if you proxy another vercel site through a vercel project. I.e. a nextjs projects proxies /docs to a docusaurus page. Because as of today the billed the bandwidth and requests twice :-(
Deleted Comment
Vercel gets a lot of shit for its pricing, but man from a developer experience standpoint, they are impossible to beat. As a developer first, devops distant fourth or fifth, it's such a pleasure when I get to work in the Vercel ecosystem and I'm happy to pay extra for them to keep improving the experience, but this reduction is welcome :)
Right now it is hope the community offerings are good enough, or create a build image from scratch myself.
Not really "developer experience that is impossible to beat".
Also checking the vercel page, they have so many investors, how do they all expect a company predicated on a JavaScript framework to be around in 10 years.
Example, it used to be when using Sitecore, most of its extensions points would be .NET, now in their SaaS products, .NET is 2nd class, if you really want to use their tooling, without filling in the gaps yourself, the answer is Next.js.
Vercel: We’re changing our pricing. Our community has told us we’re expensive. Also Vercel: Your bill is going up.
They’re giving us a 3 month grace period, but unfortunately don’t offer a breakdown of what is causing the increase.
Overall, it's really not clear how this can be optimized. It's... cache... You could have less cache writes, but it means your users see stale content, which isn't an acceptable solution.
The wording that 92% of people see smaller bills since many people host projects that aren't really being used, anyone who has traffic is going to get higher bills.
Most of our increases I assume will be the data cache pricing and the only real way to optimise that is to move data fetching out of data cache and use our own cheaper caching layer.
I’m not doubting you at all, it’s just non-obvious to a non-serious user.
Cost per cache read and write instead of lumping it all in the bandwidth bill.
My reading is that the criticism of the bandwidth egress fees and it's inevitable unfavorable comparisons has hit home.
Only they were using that bucket for more than just egress. So they are breaking charges apart and this is going to have winners and losers from their customer base.
Reminds me of cloudflare pricing. They don't charge you bandwidth but do charge for invocations and if you do the math on how they bill invocations, the egress is in there - you are not escaping it. But the press of no egress fees is nice.
Edge Network Routing is also a bit nebulous. I would love to see this better defined, as it's not 100% clear what contributes to volume here.