A while back I tried to reproduce a Vercel enterprise invoice using logs generated by an external service. After multiple round-trips with their support team I concluded it is actually impossible to verify what was billed even remotely reflected actual usage. It's essentially an AWS reseller in the form of a random number generator attached to some horrific contemporary JS, that the brand is so popular speaks more to the state of the industry than it does the suitability of their product
I feel like I have Stockholm Syndrome because I really don't mind it, through granted I've now spent just about every day of the past year staring at a various AWS dashboard.
Overall I think AWS is one of the greatest products to ever come about in my lifetime, though I think one of their greatest fumbles is not getting AWS Amplified more right, they could have squashed both Vercel, Netlify and most other "resellers" like a bug.
And I also want point out Vercel Enterprise, start from 3000$/m and I can get more things, and also cheaper, better with Cloudflare. A lot vercel features are just not really useful. (Yes, I'm talking about Next.JS)
This is really interesting, kudos to the creator! My only note is that Vercel is probably paying less than you and me, in which case the spread is a bit greater than the "vs. retail" comparison.
As I type this the responses are mostly negative, so to balance that I'd like to point out that (1) integration is often undervalued, and (2) nothing prevents developers from using the other services directly, or even creating and managing their own databases, object storage, etc.
My point is that Vercel's markup is higher than what's listed if Vercel is paying less than retail. As a specific example, if Vercel is paying Neon 10¢/GB/month for storage, Vercel's markup vs. their costs is 200% instead of 150%.
The appeal of a no-ops workflow for basic frontend apps is there. We’ve got a bunch of static docs sites built with vuepress and docusaurus that are a great fit for this. Not that we can’t whip up a CDN with terraform and a CI/CD pipeline with preview environments, but my team would rather spend its energy on our core product.
However we’ve been badly burned by vercel, netlify and render.com switching their pricing models to user based instead of infrastructure based pricing. We’re migrating to AWS amplify right now, which also happens to be wonderfully integrated into our wider IT landscape with an AWS landing zone, automated internal chargeback etc. It’s 90% the same for our use case and charges only for infra at standard AWS rates.
At this point I’m starting to wonder why it isn’t more popular.
> At this point I’m starting to wonder why it isn’t more popular.
The last time I tried it, most of the "automagic" quickly turned into "do everything by hand if you don’t want to get burned, and oh, we say we handle this use case but, as obliquely mentioned in passing, you really shouldn’t use it. Also, we don’t see the point in having our CLI tool spit anything more than the most generic errors.
What? What do you mean access control? What is that?"
I ended up on Firebase.
And, on my current project, found a single-table DynamoDB to be more reliable and predictable.
It's obviously a trade off. But we've been running a GitHub Action/Gitlab Job/pick-your-poison task, to just dump build output on an FTP server. It's just static websites, and it has never broken.
In my mind, this is so basic, that anyone (who is a developer), should be able to do it. But that's just my take.
I've been wondering what the limits of the user-based pricing actually are
If it's just the number of people who can go in the UI and press the button (when it automatically gets deployed from git anyway), or change env secrets, can't you just have a single admin account and call it "one user"? That could be a single actual person (how often do you change those things?) or could even be a single account shared by the whole team
It’s simple. It’s not more popular because of bad UX.
I would not be surprised if the best customer that Vercel chasing is also a customer that can add these costs to their customer or take a hit on the margin.
This is why I'm bear-ish on Next.JS as a framework. Vercel has some super cool features for Next.Js that are easy to integrate into your app, but is that de-incentivizing Next.JS to implement them in an open way?
Vercel is a hyper for-profit and closed platform, is that blocking innovation on Next.JS as an "open-source" framework?
Right around the time when Vercel introduced their performance analytics upsell service, they deleted the NextJS documentation on "web vitals" gathering - same thing, but without the service.
Then again when they introduced their new Image component for the longest time it would by default use Vercel's paid image optimisation services, eventually it could be disabled but only with some weird and poorly/confusingly documented custom configuration entry.
There are more instances of similar such questionable actions by the NextJS maintainers. I'd rather have seen them just be open about what drove them to do these things.
The image one was what I had in mind as well. Looks like they've updated the documentation with code snippets to help people out a little more, but back when I first did it, those docs were SLIM
Not really. Next.js is built on Node.js + React (both of which are also open source).
The services Vercel offers have to do with deployment mainly. That's never going to be something a back end or front end framework will help you with directly.
App hosting and deployment has always been a secondary concern. Choice of database, caching, queuing service, etc has also always been a secondary concern apart from a backend/frontend framework.
Next.js is incredibly popular in the industry. Some of the largest companies out there use it. Whether they host on Vercel or not I can't say, but I'm sure that number isn't zero.
Of course we are talking more about auxiliary stuff like landing pages, marketing sites, blogs and documentation, not hosting for their core business.
Vercel's revenue was 25.5 million in 2022 (according to Nathan Latka who has pretty reputable figures) on a 2.5 billion dollar valuation [0]. They're hyped but it doesn't seem like any big players actually use them at scale, as it's likely much, much cheaper to host on bare cloud providers like AWS, which Vercel themselves wrap (with Vercel also now wrapping the services included in OP's site).
He interviews them on condition of revealing the numbers, which he sells to investors. He has enough clout in the industry that people want to reveal their numbers to him in exchange for being able to raise more money.
I know of five or six companies using Next; none of them use Vercel. I tend to think that their moat against “write a five line dockerfile” just isn’t all that large. I use Vercel for my personal site; I’m familiar with the product suite; I genuinely don’t know why anyone would pay the markup beyond not knowing better.
The auto branch deployments on PRs is pretty cool.
Larger companies already have their workflow, compliance etc.
Developer productivity alone is not going to be worth going through audits / signoffs. It doesn't add enough to the product itself e.g. does it beat Cloudflare, Fastly, Akamai, etc in that space? No.
The wrapper is pretty straightforward, I can see how it's a teensy bit simpler to have Vercel manage things for you, but it's not really much easier...
Vercel raised $300m+ at the top of the market and paid over the odds to hire a ton of JS ecosystem luminaries. Those investors are going want to see a return, not just an eyewatering wage bill. Anyone building on top of their ecosystem is going to get fleeced, they have no other route to possibly justifing their valuation or ever providing a passable return on that capital. Everyone else should be preparing their plan b for what happens if they impode and Next.js, Turborepo etc development fractures or grinds to a halt.
The problem are SaaS headless platforms that are now making Vercel/NextJS their main SDK tooling for frontend code, where everyone that decides to use another stack is faced with having to implement by themselves what those SDKs offer out of the box in Vercel/NextJS integration.
> Everyone else should be preparing their plan b for what happens if they impode and Next.js, Turborepo etc development fractures or grinds to a halt.
Isn't next.js too big to fail? Currently we are trying to define a modern stack for our front-end, and I always thought next.js/react to be the next java -> Perhaps Solid.js is much better (IMHO it surely is) but I probably won't get fired for choosing next.
If not, what would be the alternative? I really don't want to restart with the hassle of configuring a js project from scratch. Done it already a thousand times, and that's a thousand times too many :)
> I really don't want to restart with the hassle of configuring a js project from scratch. Done it already a thousand times, and that's a thousand times too many :)
This is the key. For small apps, it's far more effective to pay the premium to not deal with any DevOps. Once an app gets bigger, it'll make sense to spend more time optimizing cost.
I feel like Vercel is the new Heroku circa 2015. I'm hoping it won't follow Heroku's trajectory, but who knows.
Those are necessary but not sufficient conditions to having a healthy community which actually continues developing such forks, likely for free if the main company backing the original product goes away. I don't know why people think OSS is a panacea to community development, lots of things are OSS and have few to no contributors.
Honestly even the previous stable edition of Next.js before server components would be fine to peg to.
But history has shown that when a framework or backend was sufficiently popular that people did indeed step in to support it. It happened with Node.js itself (which Next is built on) a while back with what was then called io.js, before io.js eventually re-merged with Node.js after the organizational kinks were worked out.
Next.js promotes serverless deployments and in that scenario it’s not sufficiently Open Source. Vercel (or amplify) adds proprietary stuff that’s missing in next itself. There is an Open Source serverless implementation for aws lambda (open next), but it’s not official.
> Isn't next.js too big to fail? Currently we are trying to define a modern stack for our front-end, and I always thought next.js/react to be the next java -> Perhaps Solid.js is much better (IMHO it surely is) but I probably won't get fired for choosing next.
There is a huge amount of difference.
Java is currently backed by Oracle, which has a huge history of staying around (setting the reputation aside for a moment).
Vercel is currently not profitable, raised too much money and is stuck trying to generate enough profit to match that valuation.
Also NextJs is relatively small in the world you compare to.
there is alternative for vercel though they don't have storage service they are pretty decent and they don't rely on VC money. https://www.stormkit.io/
Is better tooling support for Elixir on the horizon? I’ve found eg VSCode code completion leaving something to be desired. With TS, I feel like IDEs have my back, but with Elixir I (as a newbie) keep getting stuck. There’s also a lack of readymade idiomatic solutions to common problems out there, requiring me to browse the Elixir forum a lot.
There are tons of really good solutions to this problem that are incredibly affordable but they just aren’t popular in the React ecosystem which is once again off doing its own thing seemingly detached from everyone else and trying to just fit the React mental model into any abstraction they come across and patting themselves on the back about innovation in the process.
Honestly React is an actively terrible place to have as your center of the universe when trying to build the kind of app you described. Not to say you can’t or shouldn’t use it but it most certainly shouldn’t be where the core is.
This is a good chart. But I’d argue using Vercel is entirely justified for many indie devs or startups. I bet most won’t get to the point where the extra cost of using Vercel really hurts. If someone is lucky to get there, they can just switch to using Upstash / Neon if they feel the benefits of Vercel’s extra layer don’t outweigh the added costs.
What's the feasibility of replicating Vercel's services and architecture?
Without supply side limitations, resellers generally become reduced to commodities over time. This is especially likely with high margin markups, which seems to be the case with Vercel.
Is the integration of Next.js on Vercel really that superior to other platforms?
That tweet by Lee Robinson isn't really about markup, it's about unbound spending, which seems to be more related to, for example, this recent complaint where a bug led to an accidental $3380 bill in just 6 hours
Well, if nothing else, at least Vercel's new integrations have put new things on my map of free things to use in side-projects (I had never heard of Upstash before now) :))
On a serious note, Neon is Postgres and Planetscale is MySQL. Neon has 100% compat with Postgres and Planetscale supports most but not all MySQL. Neon has unlimited storage a single node compute. Planetscale is scale out architecture on top of Vitess.
Neon scales to 0 and more cost effective b/c the architecture.
Agree on the callout. This one we are going to enable soon so it's fixable. So the correction is that it's architecturally possible, but temporarily disabled. Hope we will be able to run Supabase on it soon!
Also there are some storage plugins that won't work b/c we take over Postgres low level storage.
Well it’s much much harder. Query plans over the distributed system should be different and transaction coordination is different when queries span shards.
It’s impossible to give 100% performance compatibility.
Vitess maintainer here. I feel like the discussion was about 100% feature (queries/protocol/...) compatibility and that somehow it shifted to 100% performance compatibility? 100% performance compatibility is trivially not something to claim.
I'm interested in Neon and considering migrating to it. A few questions that I couldn't find a quick answer to:
1. When scaling to zero, what is the cold start for a request (including the time needed to make the connection)? Do you have benchmarks on this you could share?
2. Does Neon run a pgbouncer service or are customers expected to run their own? Is it better for AWS lambda functions to leave a connection open for the duration of the container lifecycle or open/close on each request?
3. Does Neon support HTTP for doing queries like serverless Aurora v1 does with its Data API? The use-case I have is direct AppSync GraphQL resolvers, not V8 isolate runtimes.
nextjs is sick and I've always been vercel-hesitant. this is probably an app-specific dilemma that should be solved with spreadsheets to compare costs based on your very specific needs.
This is a bit of a copy/paste from a comment I made in another thread like three weeks ago[1]:
#######
I'm very much starting to distrust these huge companies with infinite product/feature lists and generic marketing-lingo websites.
"Vercel is the platform for frontend developers, providing the speed and reliability innovators need to create at the moment of inspiration."
Seriously?
I want serverless providers that tell me the 4-5 products they offer (Compute, maybe a KV store, maybe a database, maybe some pubsub, maybe a queue?), give me the pricing, and leave me the Hell alone.
I don't want to feel locked into a system promising end-to-end whatever, ones that heavily push a certain framework, and most importantly ones that look like the homepage was designed by a team of sales people instead of a team of engineers.
It's the difference between the Cloudflare Workers website and the Vercel website: Vercel looks like the new-age big-brother con artist, while Workers looks like a utility.
Sorry, what were we talking about? A runaway bill?
#######
This kind of stuff is exactly why I don't trust Vercel. They're selling some """experience""" on top of utilities. This works for Apple in the non-technical space, but for developer tools? Absolutely no chance.
I wasn't going to use Vercel before, but I'm certainly not going to now.
hah. that was exactly my impression too. years ago, they showed a command like "next up" or something and boom your app is deployed. never used it. didn't even look into it, just assumed it would cost an arm and a leg because there's no way they wouldn't add a bunch of markup ontop of a basic vps
A whole industry has sprung around charging front end developers for basic server management tasks. They will quite literally pay for anything that means they don't have to SSH into Ubuntu server. The irony is they are taking on a ton of overhead with multiple services instead of learning how to set up Nginx and sudo apt install Postgres.
There's a lot more to running your own server than that. I set up a Hetzner VPS just for play one weekend. I forgot all about it and came back a couple days later: it had already been compromised and was being used to mine crypto coin. All because I left something running (related to Docker) which I don't even remember starting.
Hardening your servers, ensuring proper port exposure, ensuring upgrades and security patches, is thought and time you need to spend. It's hard to keep track of all vulnerabilities in all software. That'd before even talking about zero-downtime deployments and all of that.
Running NGINX and Postgres is not the difficult part that people are avoiding. There's a good reason these services exist.
I’ve got a lot of dumb little things living out on the internet deployed this way, and I don’t think I’ve ever been compromised. Maybe you were just especially unlucky?
There are some things I’ve deployed without much care and yet they’re always as I left them.
I’m not saying there’s nothing to worry about. I’m just not sure it’s all that difficult with some rudimentary (but sane) security practices.
It is a common theme. Bots and others scan ports and IP ranges all the time. Looking at server logs I always see random server connections trying to get to things like wp-login.php to look for an exploit.
If you put it out there and don't actively secure it it's bound to get compromised - just a matter of when.
Maybe I'm blind to something because I've been in server administration for 15years; but my -really old- IRC network requires about 3 hours of maintenance a year; I have 10 machines and they're constantly being "attacked" (as per logs) but the only time I've ever been compromised was when I was trying to overcomplicate things with fancy tools to make administration easier
That's like saying it's outrageous that a consultant charges $xxxxx for a 5minute fix. You've said it - you've got 15years of experience in server administration. That's what people are paying for.
Having said that I never said it was "hard" - just something needs to be done. I responded to a comment that took it for granted that you'd automatically be safe on the Internet.
Yeah, but most adminsys people are autodidacts; thus there was a time when they did not have 15 years experience and were running systems on the internet.
I'm not saying there can't be a problem, but it's so easy and the alternatives (cloud+terraform+ansible+packer et al.) are so complicated in comparison that it beggars belief that people are choosing an "easy" path here.
Yeah, it's actually crazy just how much every open address gets spammed. You freak out like why are there thousands of attempts to login to my server that I haven't advertised at all, then you Google it and find out it's just the normal state of the internet.
Set up fail2ban then good luck to anyone to anyone trying your address, it's very simple. Ensuring upgrades and security patches is literally running sudo apt update and sudo apt upgrade. Should be a piece of cake for anyone who has been running Linux for a few years.
I dont think this is the right argument to make. People do this not to avoid setting up nginx and Postgres, they do it to avoid needing to worry about scalability later down the line.
Yes, for hobby projects and proofs of concept you can easily get away with a VPS from DigitalOcean or Vultr (are they still around?), but for anything with super variable traffic? Planning to post a link to HackerNews or ProductHunt? Cloudflare Workers and Fauna keep your site online, the VPS crashes.
What percentage of projects ever need that scale? Is it not something crazy like 95% of startups fail? A lot of the successful ones will be in niche categories as well that just don't have scale problems like major social media and tech companies.
Even then most VPS providers offer a load balancer and you can add multiple VPS. It's not so black and white on 1 server vs infinite scaling. There are midpoints.
Yes, but the second you grow beyond one server the complexity of keeping both in sync, sharding the database, etc etc etc, makes it way more simple to just write a worker and let another company handle it.
A whole industry has sprung around charging back end developers for basic networking tasks. They will quite literally pay for anything that means they don't have to place a server in their basement. The irony is they are taking on a ton of overhead with multiple services instead of learning how to plug in the Ethernet cable and turn the server on.
A lot of those services are usually free for hosting small things. And are incredibly easy to deploy, free versioning, free builds, free pull request preview urls, rolling deploys, multi tenant databases etc etc
I much prefer the above, then waking up to my droplet dead on a Tuesday night because I forgot to also rotate my stdout logs.
it's great for contractors with small projects where the customer is happy to pay for less maintenance fees. Not sure I would use it for a company I worked for full-time, though.
The bill can cost you more. Often see contractors implementing things like marketing campaigns - short lived websites, yet at $400/TB anything with some attention can cost you a lot more.