4 ms·

> Beyond reliability, we faced other challenges: > - Usage-based pricing that punished our success, the more users chatted, the more we paid This is such a

by asib 1y ago

> Beyond reliability, we faced other challenges: > - Usage-based pricing that punished our success, the more users chatted, the more we paid This is such a strange position on usage-based pricing and seems telling.

gausswho 1y ago
Not necessarily. Netlify told me as I had blown past 20 bucks for 1TB of traffic that paying 50 bucks for every additional 100GB was 'a good problem to have'. Well no, not at all. If your project is one of love, the end game is not subjecting your audience to boatloads of ads.
- thinkingtoilet 1y ago
  But if your project is getting more and more usage, surely that requires more expenses. What is your alternative?
  - abound 1y ago
    I think GP is calling out the highly non-linear nature of the pricing. $20 for the first TB and then $50/100 GB after is a 25x jump in pricing. Linear usage cost makes sense, but the more common/sane thing is cheaper unit pricing as you hit scale.
    - mooreds 1y ago
      > the more common/sane thing is cheaper unit pricing as you hit scale. Depends on the provider's business model. Many devtools want to make it trivial to get started, and zero/low prices facilitate that. They know that once you are set up with the tool, the barrier to moving is high. They also know that devs are tinkerers who may take a free product discovered on their free time and introduce it to a workplace who will pay for it. But someone has to pay for all those free users/plans (they aren't using zero resources). With this business model, the payer is the person/org with some level of success who is forced up into a more expensive plan. This is a valid strategy for two reasons: - such users/orgs are less likely to move because they already have working code using the system and moving introduces risk - if they have high levels of traffic, they may (not certainly, but may) be a profit making enterprise and will do the cold hard calculus of "it costs me $50/100 GB but would take a dev N hours to move and will have X opportunity cost" and decide to keep paying The successful "labor of love" project is an unfortunate casualty.
      - Illniyar 1y ago
        It's definitely a business model. Just like a dark pattern is a pattern :) The counter to that argument is that it's creating an adverse effect on your most profitable customers, with an incentive to move to offerings that don't have free tiers (or where the free tiers are not considerably affecting your own costs). If your free tier is so lucrative that you need to 25x the cost, then your free tier is too expansive and you need to tone it down until the economics make sense.
        JavierFlores09 1y ago
        > The counter to that argument is that it's creating an adverse effect on your most > profitable customers, with an incentive to move to offerings that don't have free tiers (or where the free tiers are not considerably affecting your own costs). > If your free tier is so lucrative that you need to 25x the cost, then your free tier is > too expansive and you need to tone it down until the economics make sense. It does make sense, though. That's how almost every subsidized system works, and the benefit applies for everyone until they scale to a point where they are not legible for it. It does suck for the pool of people that just began paying the actual price of the service instead of the subsidized one, and certainly more so if they're not actually getting profit from it but then again, it isn't like they weren't benefitting from the price up to that point, otherwise they wouldn't have chosen it. Luckily enough, as far as databases go, there's a gazillion options to choose from and experiences like this are invaluable when it comes to picking one with a pricing model that fits the scaling requirements of a given project, and not only the technical merits. Also as a side rant, I honestly don't think "projects of love" are a good counter argument to anything. They're clearly not of love because otherwise they would find a way to make them profitable. Most people are either lazy to, or lack the knowledge of how to turn their hobby into a marketable thing. Which is fine, nobody wants to deal with business when it comes to their hobbies, but one can't have it both ways. Either your hobby project gets successful and you find ways to cover its expenses, or you realize that your hobby project needs to be kept just a hobby project.
        gausswho 1y ago
    - robertlagrant 1y ago
      Yes - they've inverted it to allow smaller projects to onboard very cheaply.
    - thinkingtoilet 1y ago
      Ah. Makes sense. Thanks.
  - gausswho 1y ago
    For the moment, streamlining bandwidth delivery and distributing across other free/cheap tiers. After that, the plan is to find a sales team that'll discount/sponsor the site in exchange for putting their logo in the footer. After that, maybe self-host or close up.
- asib 1y ago
  I hear you on that, but I would say "usage-based pricing" does not equate to "increasing marginal cost" at all. There are both usage-based providers that have increasing marginal cost and those that don't.
anthonyronning 1y ago
Yeah, at a certain point it's just always running 24/7, which they charge you usage-based if your company is over 750 hours in a month. If you're running databases continuously, I find a lot of their original unique selling point pretty moot, especially if you're paying them extra for it.
- halfmatthalfcat 1y ago
  This pitfall of "serverless" has been widely known since people started abusing lambda to be "always on". Serverless is a PaaS gaslight to make you pay more for the perceived convenience.
  - vasco 1y ago
    It's not a gaslight, but it's only cost effective for specific usage patterns. It's only a "gaslight" if you think you need to run every workload the same way and don't cost estimate before you roll it out.
  - swiftcoder 1y ago
    Serverless is often cheaper just so long as your workflows are bursty/infrequent. For example, we don't need to pay to permanently rent/colocate a beefy server, just to run a batch job once a week. If you have a constant base load of requests, lambda is just the wrong tool for the job.
    - const_cast 1y ago
      Even if it's pretty bursty, usually a perm server is still cheaper. Running the server only half the time isn't burning too much money since AWS is already 10x the cost of raw compute. You need really bursty workloads to make serverless make sense.
      - swiftcoder 1y ago
        If we're talking about relatively small workloads, and relatively stable traffic, then sure. But I think for large workloads with unpredictable requirements, the capacity planning alone in a perm setup is a nightmare for most early-stage businesses. Spinning up an extra hundred instances in EC2 takes minutes - getting the same number of boxes installed a colocation facility takes weeks at best
mrweasel 1y ago
I sort of feel like their own product, Maple.AI, have the same issue. The more users use the product, the more they have to pay. So they clearly understand that the pricing model is problematic, but they still use it themselves?
theamk 1y ago
Seems reasonable to me? After all, they went to "predictable pricing" which seems to be generally better than usage-based one. I think the only reason to go with usage-based pricing is if you want to take a risk to save money - you are getting unpredictable bills but hope that average is going to be cheaper. As any gamble, you can win or lose.
clarkbw 1y ago
I think this was actually trying to say, Neon prices were high. Because otherwise I agree it doesn't make sense. And Neon will be lowering prices dramatically... a day from now?

by asib 1y ago

gausswho 1y ago

Not necessarily. Netlify told me as I had blown past 20 bucks for 1TB of traffic that paying 50 bucks for every additional 100GB was 'a good problem to have'. Well no, not at all. If your project is one of love, the end game is not subjecting your audience to boatloads of ads.

thinkingtoilet 1y ago
But if your project is getting more and more usage, surely that requires more expenses. What is your alternative?
- abound 1y ago
  I think GP is calling out the highly non-linear nature of the pricing. $20 for the first TB and then $50/100 GB after is a 25x jump in pricing. Linear usage cost makes sense, but the more common/sane thing is cheaper unit pricing as you hit scale.
  - mooreds 1y ago
    > the more common/sane thing is cheaper unit pricing as you hit scale. Depends on the provider's business model. Many devtools want to make it trivial to get started, and zero/low prices facilitate that. They know that once you are set up with the tool, the barrier to moving is high. They also know that devs are tinkerers who may take a free product discovered on their free time and introduce it to a workplace who will pay for it. But someone has to pay for all those free users/plans (they aren't using zero resources). With this business model, the payer is the person/org with some level of success who is forced up into a more expensive plan. This is a valid strategy for two reasons: - such users/orgs are less likely to move because they already have working code using the system and moving introduces risk - if they have high levels of traffic, they may (not certainly, but may) be a profit making enterprise and will do the cold hard calculus of "it costs me $50/100 GB but would take a dev N hours to move and will have X opportunity cost" and decide to keep paying The successful "labor of love" project is an unfortunate casualty.
    - Illniyar 1y ago
      It's definitely a business model. Just like a dark pattern is a pattern :) The counter to that argument is that it's creating an adverse effect on your most profitable customers, with an incentive to move to offerings that don't have free tiers (or where the free tiers are not considerably affecting your own costs). If your free tier is so lucrative that you need to 25x the cost, then your free tier is too expansive and you need to tone it down until the economics make sense.
      - JavierFlores09 1y ago
        > The counter to that argument is that it's creating an adverse effect on your most > profitable customers, with an incentive to move to offerings that don't have free tiers (or where the free tiers are not considerably affecting your own costs). > If your free tier is so lucrative that you need to 25x the cost, then your free tier is > too expansive and you need to tone it down until the economics make sense. It does make sense, though. That's how almost every subsidized system works, and the benefit applies for everyone until they scale to a point where they are not legible for it. It does suck for the pool of people that just began paying the actual price of the service instead of the subsidized one, and certainly more so if they're not actually getting profit from it but then again, it isn't like they weren't benefitting from the price up to that point, otherwise they wouldn't have chosen it. Luckily enough, as far as databases go, there's a gazillion options to choose from and experiences like this are invaluable when it comes to picking one with a pricing model that fits the scaling requirements of a given project, and not only the technical merits. Also as a side rant, I honestly don't think "projects of love" are a good counter argument to anything. They're clearly not of love because otherwise they would find a way to make them profitable. Most people are either lazy to, or lack the knowledge of how to turn their hobby into a marketable thing. Which is fine, nobody wants to deal with business when it comes to their hobbies, but one can't have it both ways. Either your hobby project gets successful and you find ways to cover its expenses, or you realize that your hobby project needs to be kept just a hobby project.
        gausswho 1y ago
  - robertlagrant 1y ago
    Yes - they've inverted it to allow smaller projects to onboard very cheaply.
  - thinkingtoilet 1y ago
    Ah. Makes sense. Thanks.
- gausswho 1y ago
  For the moment, streamlining bandwidth delivery and distributing across other free/cheap tiers. After that, the plan is to find a sales team that'll discount/sponsor the site in exchange for putting their logo in the footer. After that, maybe self-host or close up.
asib 1y ago
I hear you on that, but I would say "usage-based pricing" does not equate to "increasing marginal cost" at all. There are both usage-based providers that have increasing marginal cost and those that don't.

anthonyronning 1y ago

Yeah, at a certain point it's just always running 24/7, which they charge you usage-based if your company is over 750 hours in a month. If you're running databases continuously, I find a lot of their original unique selling point pretty moot, especially if you're paying them extra for it.

halfmatthalfcat 1y ago
This pitfall of "serverless" has been widely known since people started abusing lambda to be "always on". Serverless is a PaaS gaslight to make you pay more for the perceived convenience.
- vasco 1y ago
  It's not a gaslight, but it's only cost effective for specific usage patterns. It's only a "gaslight" if you think you need to run every workload the same way and don't cost estimate before you roll it out.
- swiftcoder 1y ago
  Serverless is often cheaper just so long as your workflows are bursty/infrequent. For example, we don't need to pay to permanently rent/colocate a beefy server, just to run a batch job once a week. If you have a constant base load of requests, lambda is just the wrong tool for the job.
  - const_cast 1y ago
    Even if it's pretty bursty, usually a perm server is still cheaper. Running the server only half the time isn't burning too much money since AWS is already 10x the cost of raw compute. You need really bursty workloads to make serverless make sense.
    - swiftcoder 1y ago
      If we're talking about relatively small workloads, and relatively stable traffic, then sure. But I think for large workloads with unpredictable requirements, the capacity planning alone in a perm setup is a nightmare for most early-stage businesses. Spinning up an extra hundred instances in EC2 takes minutes - getting the same number of boxes installed a colocation facility takes weeks at best

mrweasel 1y ago

I sort of feel like their own product, Maple.AI, have the same issue. The more users use the product, the more they have to pay. So they clearly understand that the pricing model is problematic, but they still use it themselves?

theamk 1y ago

Seems reasonable to me? After all, they went to "predictable pricing" which seems to be generally better than usage-based one. I think the only reason to go with usage-based pricing is if you want to take a risk to save money - you are getting unpredictable bills but hope that average is going to be cheaper. As any gamble, you can win or lose.

clarkbw 1y ago

I think this was actually trying to say, Neon prices were high. Because otherwise I agree it doesn't make sense. And Neon will be lowering prices dramatically... a day from now?