Lee Robinson (VP, Dev Exp @ Vercel) just tweeted: https://twitter.com/leeerob/status/1653636931291602953
Vercel Service Markup
81–90 of 109 posts
Re: Vercel Service Markup
#82Earlier quoted context omitted.
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.
Can I do that with something like a digital ocean droplet?
Re: Vercel Service Markup
#83How does Neon compare with planetscale for free dB hosting? I know fly also has free dB's, but it really isn't a managed dB service.
Neon CEO here. Much much better :) 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.
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.
Re: Vercel Service Markup
#84A 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…
horrific contemporary JS lol
It's straight up one of the smoothest developer experiences ever to exist.
Re: Vercel Service Markup
#85A 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.
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.
Re: Vercel Service Markup
#86Earlier quoted context omitted.
Neon CEO here. Much much better :) 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.
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…
1. Right now cold start is 3-5 sec. We are actively working on bringing it down. This is our users #1 complaint
2. Yes to pg bouncer. You have two connection strings with and without it
3. Yes. Check out our serverless driver.
Re: Vercel Service Markup
#87Earlier quoted context omitted.
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.
Likewise in Vitess. It is architecturally possible to add 100% compatibility :)
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.
Re: Vercel Service Markup
#88Earlier quoted context omitted.
Likewise in Vitess. It is architecturally possible to add 100% compatibility :)
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.
Re: Vercel Service Markup
#89Vercel 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 pla…
> 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, wh…
> 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.
Javascript Java React NextJs
i.e. it sits another 2 layers below.
Re: Vercel Service Markup
#90Vercel 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 pla…
> 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, wh…
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/