> - 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.
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.
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 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.
And Neon will be lowering prices dramatically... a day from now?
And 250 dollars/month was considered expensive for the infrastructure handling that? My first impression is that based on the stakes alone, that would warrant a full time dedicated engineer.
Not gonna lie, although I appreciate the comparison and that they shared their experience publicly, this post sounds like half a technical write-up, half an ad for both companies.
No, it was not my intention for price to be the main thing people hooked in on with this article. It's the combination of it all. Better reliability, performance, and infrastructure AND it's more affordable.
> warrant a full time dedicated engineer
TBH, it's basically my sole full time job as the CTO.
> half a technical write-up, half an ad for both companies
I've been frustrated by Neon for months now and excited about PlanetScale's new postgres offering. Was pleasantly surprised by it too and wanted to write about it. I do appreciate you writing this and sorry if it comes up too much like an ad for us. Only meant to share our unique experiences and satisfaction with a new thing.
Initial results are actually pretty cool when using the UI to spin it up. The API leaves some things to be desired (bad error messages that obfuscate the actual error, undocumented rate limiting, ..).
Plus, there's been quite a number of strange bugs we ran into, like tables that don't recreate correctly because of dangling resources.
Overall, I'm pretty excited about the product because it makes life a bit easier, but it's not really 'production quality yet'.
(Alternatively, maybe we're just doing things in a bad way while we're learning to use it, so it could be a PEBKAC type of issue, rather than a Lakebase issue).
Quote from the article:
> At $250/month for 4 databases without any replicas, we were paying premium prices for subpar reliability.
Way too much for a project without a budget, and approximately zero for a project with a budget.
Here's their announcement blog post with a bit more info, like their benchmarks:
Usage based pricing typically implies paying per number of requests.
But I for one see zero acronyms on their managed postgres product information page: https://fly.io/docs/mpg/ *
* Except in the url
