Maybe you were referring to specifics of Neon's usage-based pricing.

The bullet I quoted makes it seem like you feel punished for having to pay more because you used more resources. That's, like, the fundamental idea of usage-based pricing. If you feel punished, it seems as though you misunderstood the whole idea.

I see. Yeah I'm not against usage-based in general. Just specific to database's, especially in my instance where it feels like I'm paying more for the luxury of having a scale-to-zero feature that I've quickly grown beyond.

I'll reiterate that it's not the only reason why I'm moving off of them. Reliability, performance, insights, etc.

It just happens to be a lot more affordable too.

In the database world, serverless/autoscaling pricing is almost always more expensive for real workloads. The % of workloads where it makes sense is small. Ones where 90% of the time there's little small traffic and 10% of the time the DB sees large traffic spikes. Otherwise, just pay a fixed cost for the hardware you need.

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.

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.

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.

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.

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

Having plugged your numbers into the pricing for both Neon and Planetscale I'm rather confused. At Planetscale, given the numbers cited in the post, you're paying for 4 servers (+ replicas) with one eighth of a vCPU each, running 24/7. That's equivalent to about 375 Neon compute-hours per month. Your $69 Neon plan included twice that. Neon only goes down to 1/4th of a vCPU, but that does include the same amount of memory as the 1/8th at Planetscale, so take that 4 times and you have 4 databases running all month for the price of your $69 plan at Neon. How did you get to $250?

Honestly, I don't even know. My last month bill was for 1947 compute hours for a total of $260. I just have the 4 databases. Looks like two of them are at .5 instead of .25, maybe that's it? Unless they are auto scaling me up occasionally and I'm not aware?

Two of them being at 0.5 brings the total to 1.5 vCPU, which over an entire month adds about another 375 compute hours for an extra $60, which is still much lower. Indeed autoscaling seems like it could be the cause. According to the documentation that's a setting you can configure per "compute", but I don't know if it's the default.