[HN Gopher] Storage on Vercel
       ___________________________________________________________________
        
       Storage on Vercel
        
       Author : drecoe
       Score  : 220 points
       Date   : 2023-05-01 16:00 UTC (7 hours ago)
        
 (HTM) web link (vercel.com)
 (TXT) w3m dump (vercel.com)
        
       | crooked-v wrote:
       | This is cool and whatever, but after the work my company has put
       | in to actively move things away from Vercel I'm going to assume
       | it's hugely overpriced by default compared to even other similar
       | SaaS services.
        
         | 015a wrote:
         | Its extremely expensive, and I'm aware of two companies
         | migrating away from NextJS itself (neither were ever hosting
         | with Vercel, though).
         | 
         | I've only talked in depth with one of them, but the reason is
         | complexity: they want "a react framework" and every update to
         | NextJS substantially raises the complexity bar, introducing a
         | large number of features that they don't want or need. There's
         | also been at least one incident of a NextJS bug which only
         | affected non-Vercel deployments; and that incident came up in
         | this discussion as evidence for their concern that NextJS
         | doesn't have a future outside of Vercel (the company and the
         | platform).
        
           | riogordo2go wrote:
           | This is also my concern. If the happy path is Serverless/Edge
           | (on Vercel) with React Server Components I'm in for a big
           | rewrite. I'm holding off any new investments in the Next.js
           | ecosystem until the dust settles or a more community focused
           | and stable alternative arises.
        
             | niyazpk wrote:
             | What are the leading alternatives? I know about RemixJS,
             | but not too up to date on others and how each of these
             | compare against each other.
        
       | frankfrank13 wrote:
       | cloud was a mistake
        
         | grrdotcloud wrote:
         | I want to disagree but thanks be to the lack of agreed
         | definitions I will agree.
        
           | frankfrank13 wrote:
           | i was being intentionally stupid, but based on this pricing
           | I'm forced to think that Vercel et al. are just praying on
           | junior/inexperienced devs. This is like a 4x premium (maybe
           | more) over AWS, and that is already a huge premium.
        
       | lxe wrote:
       | A very natural step for Vercel. Not having a prescribed
       | statefulness/storage solution has been a pain since they've
       | pivoted into strictly serverless.
        
       | bluebeel wrote:
       | the margin that vercel makes on these products that you can
       | easily integrate with nextjs (or anything else that runs on their
       | infra) is crazy. All of them offer easy integration with the edge
       | or lambas functions... I don't see how vercel justifies this
       | price outside of DX
        
         | cccybernetic wrote:
         | Consumers have always been willing to pay a premium for
         | simplicity & convenience. No difference here: devs will pay for
         | DX.
        
           | bluebeel wrote:
           | I understand that bu Vercel KV is almost 2x more expensive
           | than Upstash. Even the vercel/kv package is just a wrapper
           | for upstash/redis - I mean what is the benefit of using
           | Vercel KV instead of Upstash? What DX is improved? Upstash
           | offers a nice UI and easy integration with edge functions and
           | lambas functions. It's the same with neon database and
           | cloudflare r2. The only plus value I see is the centralised
           | dashboard. Paying 2x for a single dashboard?
        
             | ethomson wrote:
             | Product Manager for Vercel's storage products here. Today
             | we announced three new storage products in beta; they're
             | based on infrastructure that are provided by partners.
             | There's a lot that goes in to pricing products -- and our
             | products are distinct from our partners' products. We have
             | different roadmaps and will introduce different features as
             | we continue development. So I don't love to make too many
             | comparisons between apples and oranges.
             | 
             | But I suspect that you might be comparing Upstash's per-
             | command pricing for _regional_ requests ($0.20 per 100k) to
             | Vercel KV's? In fact, Vercel KV is multi-region, so the
             | more apt comparison is Upstash's pricing for _global_
             | requests ($0.40 per 100k).
        
         | sroussey wrote:
         | I mean, you can say that for serverless in general. Heck, you
         | can say that for AWS etc as well.
        
       | babyshake wrote:
       | This is more or less like Railway, but hosted by Vercel?
        
       | jmull wrote:
       | > import { sql } from '@vercel/postgres';
       | 
       | Careful here. You'd be building a vercel-specific API into the
       | middle of your data access stack. That might be fine... e.g., if
       | it has a limited/specific use or lifetime, so that you know you
       | won't get stuck.
       | 
       | But otherwise, use a standard, portable client. The docs say you
       | can use any postgres client, so you should be able to choose
       | whatever you prefer.
        
       | MattIPv4 wrote:
       | Cloudflare's R2 costs $0.36 per million read operations (after
       | the 10 million you get for free) [1]. Vercel is wrapping R2 and
       | is charging $2 per million reads [2]. They're also charging
       | $0.15/GB for egress (after the 1GB you get free), when R2 charges
       | nothing, and the storage cost is doubled from $0.015/GB on R2 to
       | $0.03/GB on Vercel. That's quite the cost increase for the DX
       | improvement.
       | 
       | [1] https://developers.cloudflare.com/r2/pricing/
       | 
       | [2] https://vercel.com/docs/storage/vercel-blob/usage-and-
       | pricin...
        
         | doublepg23 wrote:
         | Hijacking this comment to ask if anyone has had luck
         | integrating Cloudflare R2 with Pleroma.
         | 
         | I've not had any luck getting it to work though I'm also not
         | well versed on the terminology.
        
         | carride wrote:
         | You will get better customer support from Vercel. Cloudflare
         | gives almost zero customer support if you are pay-as-you-go
         | plan.
        
           | DrBenCarson wrote:
           | That may be true but how much power does Vercel CS have to
           | help if the issue is fundamentally on the Cloudflare side?
        
           | vlovich123 wrote:
           | For what it's worth when I was TL I would regularly hang out
           | on discord and answer questions for R2. I believe the team
           | still does that and the community itself also answers a lot
           | of questions. Now that I TL Workers KV I do the same in that
           | chat room.
           | 
           | There's also the community forums although I find it's harder
           | to stay on top of those personally.
           | 
           | Not trying to say our paygo support is as good. Just saying
           | for those customers, I do personally try to offer ENT-level
           | support as an entire class of users (ie all paygo = 1 ent to
           | me for the products I personally support)
        
             | rozenmd wrote:
             | The Cloudflare Discord is where it's at.
        
         | datadeft wrote:
         | Does this mean I have to potentially deal with two vendors when
         | there is an outage? Awesome!
        
           | belthesar wrote:
           | That's their secret, Cap. You've always had to deal with
           | multiple vendors when there's an outage. Vercel has never
           | made it a secret that they're standing on the shoulders of
           | Tier 1 Cloud giants for their hosting backend.
        
             | alexeldeib wrote:
             | I only just read https://vercel.com/blog/framework-defined-
             | infrastructure
             | 
             | To me, the storage announcement + this blog really helped
             | contextualize where Vercel sits. And I really like this
             | approach. It's what I'd want to build on. I love the
             | partnerships with cos out of their core expertise like
             | Neon, and exuding integrations with supabase, planetscale,
             | etc
        
         | leerob wrote:
         | This isn't finalized yet, apologies for the confusion. We'll be
         | updating the pricing for Blob shortly (it's in private beta and
         | invite only). The pricing for KV and Postgres is up to date.
        
           | orf wrote:
           | Why not remove the pricing table or add a note about that
           | then? It's not great having it there if it's incorrect,
           | especially after an announcement.
        
           | dexterdog wrote:
           | I already lean away from S3/Azureblob/etc because their
           | egress prices are terrible. .15/GB is borderline criminal.
        
             | crftr wrote:
             | If you have a relationship with an account manager, talk to
             | them. There are options for better rates.
        
             | MuffinFlavored wrote:
             | What's a cheaper alternative that is of similar quality?
        
               | harporoeder wrote:
               | Backblaze is $0.01/GB egress and $0.005/GB/Month storage.
        
               | mattlue wrote:
               | I am currently developing an option that offers identical
               | quality and features but at a significantly lower cost.
               | Unfortunately, you will have to wait for approximately a
               | year until I complete the development process. However, I
               | believe that the wait will be worth it, and you will be
               | pleased with the outcome.
        
             | Demonto wrote:
             | 150$ for a TB traffic?! Wtf
        
               | mrcwinn wrote:
               | What's happening right now is a story we've seen plenty
               | of times before. Overhead cost of convenience mixed with
               | vendor lock-in, all while boasting about open source.
               | 
               | I'd love to create tools that were convenient and had
               | fair pricing. The challenge is that you're trying to grow
               | into a market with worse acquisition economics. Tough to
               | win if winning is the goal. If anyone has a solution
               | reach out. XD
        
         | paulddraper wrote:
         | > That's quite the cost increase for the DX improvement.
         | 
         | It depends how much you spend on egress vs developers.
        
       | MattIPv4 wrote:
       | Pricing for them:
       | 
       | Blob: https://vercel.com/docs/storage/vercel-blob/usage-and-
       | pricin...
       | 
       | KV: https://vercel.com/docs/storage/vercel-kv/usage-and-pricing
       | 
       | Postgres: https://vercel.com/docs/storage/vercel-postgres/usage-
       | and-pr...
        
         | leerob wrote:
         | KV/Postgres are accurate, that Blob page sneaked in. Blob
         | pricing should be figured out shortly, we'll update that page
         | (it's in private beta, invite only currently).
        
       | billiam wrote:
       | Is the (moderate) improvement in Dx and writing one check worth
       | the increased costs? In the case of blob storage, aren't most
       | Vercel customers paying Cloudflare already?
        
       | revskill wrote:
       | Cloud to me is overpriced and not transparent.
       | 
       | Example, with Upstash redis: i deployed a fly.io connected to
       | upstash. I don't use that service for a month (no query at all),
       | but it still counted in billing.
       | 
       | Wait, is upstash real serverless ? I have to pay for NOT using it
       | ?
        
         | mrkurt wrote:
         | Upstash on Fly.io is not serverless. You provision the RAM +
         | connection counts you want, and then pay for that capacity.
         | 
         | This is not what all our customers want, but it is much cheaper
         | to run this way for most fullstack frameworks. It's not ideal
         | for a Redis you don't use at all, though.
         | 
         | We're considering a serverless / metered billing option for
         | this. But what we have is much closer to spinning up a
         | permanent Redis. :)
        
           | revskill wrote:
           | The dashboard on fly.io didn't say it's not serverless. SO
           | it's not transparent. Look like a scam to me.
           | 
           | For now, i had to say goodbye for most of cloud services.
           | Good old VPS for now.
        
             | mrkurt wrote:
             | Ok that's a silly thing to say. Nowhere on our site do we
             | say we offer serverless _anything_. When you provision a
             | Redis, we offer you a selection of plans, you pick the one
             | you want, and off you go. I don 't understand why you'd
             | assume that's serverless.
        
               | revskill wrote:
               | Because Upstash is serverless redis.
        
         | epberry wrote:
         | Usage-based pricing in the cloud is a blessing and a curse. To
         | take best advantage of it you need a third party tool. At
         | least, this is the thesis behind my current employer
         | (https://vantage.sh).
        
       | pier25 wrote:
       | > _Simultaneously, as the world moves away from monolithic
       | architectures to composable ones_
       | 
       | It's been the opposite for me.
       | 
       | Back around 2015-2016 I was very excited about cloud functions,
       | serverless, etc, but these past years I've gone back to mostly
       | running VMs with regular persistent apps.
       | 
       | Complexity has gone down considerably and there's zero lock in.
       | With Docker I have full control over the platform and can run
       | these apps pretty much anywhere I want and how I see fit.
       | 
       | With Fly it's trivial to get scale to zero. I wrote a little
       | tutorial here recently:
       | 
       | https://community.fly.io/t/implementing-scale-to-zero-is-sup...
       | 
       | I still use some serverless stuff for very specific use cases,
       | like enhancing a static site with a bit of backend logic, but
       | definitely not as the main solution to run the bulk of my backend
       | apps.
        
       | wereHamster wrote:
       | The postgres code snippet is a text-book example of how to enable
       | SQL injection attacks. Great performance from the Vercel
       | marketing team.
        
         | [deleted]
        
         | teaearlgraycold wrote:
         | I don't think you understand what the code is doing. That's a
         | string templating _function_ , not a raw templated string.
         | `${formData.get('name')}` will get passed as a parameter in a
         | var-arg, not stuck straight into the string.
        
           | wereHamster wrote:
           | Right. The code converts all expressions into $N-parameters.
           | However Postgres does not support parameters in all
           | locations, eg. this would fail:                  import {
           | tableName } from "../shared"        sql`SELECT * FROM
           | ${tableName} WHERE id=${formData.get('id')}`
           | 
           | The @vercel/postgres package needs a big disclaimer that it
           | works very differently from node-postgres and what is and is
           | not allowed.
        
             | porsager wrote:
             | They've looked at Postgres.js
             | (https://github.com/porsager/postgres) before -- wouldn't
             | mind if they enabled those other cases in the same way.
             | 
             | Also, node-postgres is ripe for sql injections because you
             | just concatenate strings yourself when using it...
        
               | jmull wrote:
               | > node-postgres is ripe for sql injections because you
               | just concatenate strings yourself when using it...
               | 
               | Why the heck would you do that?
               | 
               | I guess for any library that accepts SQL, someone might
               | concatenate strings rather than use the parameter
               | handling.
        
             | jitl wrote:
             | That would result in an error then, not an injection
        
       | franky47 wrote:
       | > 'use server';
       | 
       | > Next.js Server Actions (to be announced Thursday)
       | 
       | Looking forward to have to re-learn the Next.js API, again! /s
        
       | torartc wrote:
       | Feels like the pricing is very high.
        
       | swyx wrote:
       | Vercel is the second company to "eat the cloud from outside in".
       | (https://www.swyx.io/cloudflare-go)
       | 
       | its now my defacto playbook for building lasting bottom up
       | disruptive cloud companies. start by giving away an extremely
       | good free tier (cloudflare - cdn, vercel - nextjs+hosting) then
       | add build time compute, run time compute, readonly kv store, and
       | now full read write storage.
       | 
       | (this is part of an overall cloud progression that i've been
       | studying for a couple years
       | https://twitter.com/swyx/status/1417136897894326277)
       | 
       | many other platforms try to start off offering everything under
       | the sun, claiming to care about the holistic end to end
       | experience. vercel bet correctly on one wedge, built it up over
       | years, and only now is expanding into storage. well earned.
        
         | waboremo wrote:
         | I believe this is a core factor as to why Supabase hasn't
         | joined Cloudflare and Vercel, they don't have that "outside"
         | aspect. By all other counts, they are well established to do so
         | and who knows maybe they do have something in the works to tie
         | in their offerings together from the "outside".
        
           | swyx wrote:
           | (am supabase investor) fortunately supabase's value prop is
           | so straight forward it doesnt quite need to do the "outside-
           | in" maneuver. just make postgres into a developer friendly
           | platform. huge TAM in itself. another investor i asked on why
           | they put $millions into supabase simply said "RDS has more
           | than $1b ARR"
        
             | waboremo wrote:
             | Great point about being direct, and the priority on DX
             | seems to be a semi-moat in itself, worked for Vercel and
             | Supabase so far!
        
         | c-hendricks wrote:
         | > https://twitter.com/swyx/status/1417136897894326277
         | 
         | Companies are leasing out the core aspects of computing
         | (storage, networking, CPU, GPU, auth), nothing really
         | insightful here. Just your average day in capitalism.
         | 
         | > many other platforms try to start off offering everything
         | under the sun
         | 
         | Do they? Or do they also start small, then build up over the
         | years until they have everything under the sun, rinsing and
         | repeating the process.
        
         | throwingrocks wrote:
         | > now my defacto playbook for building lasting bottom up
         | disruptive cloud companies
         | 
         | What companies have you built (or played a role in building)
         | using this "playbook" that fit your description?
        
         | youngtaff wrote:
         | Cloudflare own and run the services they're offering whereas it
         | looks like Vercal storage is just other people's services
         | rebranded
        
           | asadm wrote:
           | Users don't care about that.
        
             | the_mitsuhiko wrote:
             | ... for as long as there is no cheaper competition.
        
             | waboremo wrote:
             | Generally, that is very true. But when the bills start
             | hitting, users absolutely do care and will go out of their
             | way to avoid it.
        
               | asadm wrote:
               | Only when it reaches ridiculous enough number. Even as an
               | individual who can easily do any
               | cloud/k8s/lambdas/firecracker, I am paying Vercel a few
               | hundred for my side projects.
        
               | waboremo wrote:
               | True, but the ridiculous number might be lower than you
               | expect. Vercel in particular has got a lot of feedback
               | about their pricing!
        
             | mrkurt wrote:
             | They do, actually. We don't say anything about running our
             | own infrastructure. And every time someone finds out,
             | they're like "why didn't you lead with that?"
             | 
             | I'm surprised how much people care about what's under the
             | covers.
        
               | eropple wrote:
               | I think that in many ways is because Fly's approach is
               | sufficiently high-minded (in other words, aiming most
               | comfortably at relatively difficult problems) that it's
               | probably pretty automatic to assume that it's built on an
               | existing hyperscaler. Mentioning that you run your own
               | infrastructure adds encouragement that _you know what you
               | 're doing_.
               | 
               | Given the general state of PaaS offerings, this is a
               | differentiator.
        
         | ghc wrote:
         | Classic VC-backed B2B play. The trick, however, is finding a
         | "wedge" people actually want on its own. Unfortunately that
         | seems to be easier said than done.
        
           | swyx wrote:
           | well a good start is betting on the most popular framework in
           | the most popular language and building the production ready
           | stuff that is missing that the framework authors
           | constitutionally cannot compete with you on :)
           | 
           | there are better wedges financially speaking but theres
           | pretty much no bigger bottom up developer wedge than this one
        
             | mattwad wrote:
             | They built the framework too, or was it a purchase
             | originally?
        
               | dabeeeenster wrote:
               | Guillermo the Vercel CEO made Next.js
        
               | doodlesdev wrote:
               | Vercel (then called Zeit) developed NextJS themselves. I
               | believe swyx meant React when he said "framework", even
               | though one can argue that's technically incorrect it's
               | been commonplace for some time to call it a framework.
        
           | cccybernetic wrote:
           | There's a lot of magic with Vercel, but I think the true
           | "wedge" was clear to many people: DX. The trick was really
           | the execution, which they nailed. They realized early that
           | there was a whole class of developers out there, many of them
           | quite talented, who couldn't stand SSH'ing into Linux boxes,
           | configuring htaccess files, installing SSL certificates, etc.
           | Many of these developers also worked at big companies, and
           | held sway.
           | 
           | They distilled the entire deployment process into a few
           | clicks and boom, you have a real, functioning, fast website.
           | Then they added templates, good marketing, and doubled down
           | on React. The rest is history. It's a well executed vision
           | and I give them a lot of props for that.
        
             | antod wrote:
             | I kinda feel there was quite a time and tech stack gap
             | between sshing into a server to edit .htaccess files and
             | Vercel.
             | 
             | I wouldn't think that live .htaccess file editing was what
             | they were disrupting :)
        
             | youngtaff wrote:
             | What just like Netlify who did it a few years earlier?
        
               | no_wizard wrote:
               | They fell over by not having a Next.js type solution and
               | could have spent more time on DevRel.
               | 
               | Their pricing structure change didn't help either
               | 
               | If there was a Netlify framework that leveraged up the
               | platform that got you started quick I bet they would have
               | more mindshare
        
         | vultour wrote:
         | Will they run my workloads without requiring my attention for
         | decades? I'd love to rewrite and move some old PHP sites from
         | my webhost, but that one has been hosting them without
         | requiring my attention for probably close to 15 years. I'm a
         | little skeptical these fancy cloud runtimes will even exist a
         | few years from now.
        
           | diroussel wrote:
           | Also nodejs is deprecating versions at an impressive rate.
           | Todays LTS will be out of date soon. AWS and thus Vercel have
           | to follow along. So you can't run a node based serverless app
           | for more than a year or two before you either put the work in
           | to upgrade or just cross your fingers that the forced upgrade
           | won't break your app.
        
       | bambam24 wrote:
       | [dead]
        
       | scsteps wrote:
       | Very nice. I really wanted this to happen.
        
       | l5870uoo9y wrote:
       | Essentially added a "Storage" tab and configuration management in
       | Vercel for selected integrations. And then charge a premium for
       | that:
       | 
       | - Vercel Postgres pricing:
       | https://vercel.com/docs/storage/vercel-postgres/usage-and-pr...
       | 
       | - Neon Postgres pricing:
       | https://neon.tech/docs/introduction/billing
       | 
       | You can properly still buy Postgres directly from Neon or choose
       | another database provider:
       | https://vercel.com/integrations#databases
        
       | teaearlgraycold wrote:
       | I looked into serverless postgres offerings a few months ago and
       | came to realize that while it is possible, it doesn't appear that
       | we have figured out how to develop with it as well as we have
       | with traditional postgres. ORMs are fairly incompatible with
       | serverless postgres, and schema migrations are difficult to
       | handle because you have an unknown number of asynchronously
       | updated copies of your code spread around the world. Definitely
       | something you can account for with good planning, but probably
       | not worth the headache to the small and medium-sized teams that
       | would want to sign up for Vercel.
        
         | tudorg wrote:
         | This is why at Xata we have developed our own ORM-like SDK for
         | TypeScript and we store migration files in the repo. The SDK is
         | very lightweight so it runs in any serverless runtime. It also
         | means we can create DB branches on the fly for each PR, with
         | whatever schema is in the repo, and when the PR is merged, the
         | `main` branch gets migrated automatically.
        
           | teaearlgraycold wrote:
           | I don't quite follow, but I totally believe that solutions to
           | these problems can be made and maybe your solution really
           | does work well. The issue is that solutions here are not
           | standard yet and thus there will not be much collective
           | knowledge to draw upon. I'd _much_ rather ask engineers to
           | fix age-old RDBMS issues than novel ones that are
           | unsearchable with solutions whose repercussions are not yet
           | known.
           | 
           | There's also issues with complexity even if the solutions get
           | figured out. What are you getting in return? Serverless is
           | great IMO when it's the simplest solution to a problem, ex:
           | "I only have a front end but I really need a simple API
           | action that daisy-chains a few API calls".
        
         | theturtletalks wrote:
         | I had the same experience. I have a Next.js app and Postgres DB
         | I host on a server-ful PaaS. I hosted the same app on Vercel
         | with Neon DB and the app was significantly slower. The first
         | time Neon is connected, it will be slow so I was prepared for
         | that. Consequent reloads and using the app normally was slow
         | too. Maybe integrating Neon directly with Vercel will fix these
         | issues.
         | 
         | I just don't see the value prop to use Vercel for SaaS apps.
         | Using a running server for those works better, cheaper, and
         | faster. For consumer-facing storefronts, Vercel is a no-brainer
         | though.
        
           | maccaw wrote:
           | Have you two seen this?
           | 
           | https://github.com/neondatabase/serverless
        
             | theturtletalks wrote:
             | I used Neon's cloud DB service directly
        
       | jamesmcintyre wrote:
       | I'm wondering why vercel chose upstash vs cloudflare kv store?
       | I've worked on very large deployments of cloudflare workers + kv
       | store and the performance is amazing (and pricing). It would seem
       | to me that upstash would add hops/latency vs cloudflare kv store?
        
         | gsanderson wrote:
         | I would guess for people who want Redis? As I recall Cloudflare
         | KV is more limited and wouldn't be a suitable drop-in
         | replacement.
        
       | simonw wrote:
       | Will this be available for Python, too? The example code is all
       | JavaScript, but presumably this uses APIs under the hood that
       | could be called by other languages.
       | 
       | I've been a happy user of Python on Vercel for years, but I often
       | feel like languages other than JavaScript are very poorly
       | represented, both in the community and the documentation.
       | 
       | My notes on running Python on Vercel:
       | https://til.simonwillison.net/zeit-now/python-asgi-on-now-v2
        
         | cramforce wrote:
         | Yes! Any postgres and redis client will just work. And the blob
         | store has a REST API.
        
           | simonw wrote:
           | Based on this code example:                   import { sql }
           | from '@vercel/postgres';              const { rows } = await
           | sql`             INSERT INTO products (name)
           | VALUES (${formData.get('name')})         `;
           | 
           | Presumably authentication is handled transparently? I really
           | like that - reminds me of Deno's new KV cloud stuff too.
           | 
           | Is that done with environment variables? I'd want a way to
           | tap into that from Python code as well.
        
             | cramforce wrote:
             | Yeah, if you go into the dashboard it gives you a bunch of
             | options for connecting to the DB including the names of the
             | automatically generated environment variables. And that
             | includes POSTGRES_URL which most tools default to.
        
       | chrismsimpson wrote:
       | Serverless everywhere yields apps with massive latency & loading
       | times and if timeouts aren't well tuned (read: set unreasonably
       | high) you often get dropped connections on api calls. I am
       | currently migrating an app off vercel to raw compute (EC2) and
       | the difference is night and day.
        
         | dahwolf wrote:
         | I'm also noting a generic pattern of intermittent response
         | times in pretty much anything serverless.
         | 
         | When you take a traditional tech stack, say LAMP on a dedicated
         | server, performance is very constant overall. You even develop
         | a type of muscle memory for it and adapt a click pace/flow when
         | you use an application like that intensely.
         | 
         | No so much with cloud-native serverless. A page may respond
         | fast and then 10 times slower the next time. There's just so
         | many moving parts (virtualization, edge, cache, cold/warm
         | compute, out of network dependencies, etc) that it feels random
         | to a user.
        
       | luckluckduck wrote:
       | I really wish this had been Fly or Supabase. I've used Neon and
       | it is much less performant and often times completely non
       | responsive.
       | 
       | My company already uses Cloudflare so the rest isn't a big change
       | for us.
        
         | gigasmurf2077 wrote:
         | Can you elaborate on your issues with Neon? Interested to know
        
           | nikita wrote:
           | Please let us know what Neon performance issue you are
           | having. We have been steadily working on performance and it
           | keeps getting better. Our next ongoing investment is cold
           | starts.
        
       ___________________________________________________________________
       (page generated 2023-05-01 23:01 UTC)