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.
Their dashboards and metrics are really good. Plus the performance is great even on their non-metal offering too. I hope to one day be able to justify the upgrade to it.
Here's their announcement blog post with a bit more info, like their benchmarks:
Possibly silly question, and not specific to this DB offering, but why is it a good decision to connect to your DB over the Internet vs keeping it in the same data center as your db clients, given the network-latency based performance hit I believe it causes?
Good luck with the startup. TBH, I think going for as much managed solutions as possible while you bootstrap makes sense. Something more tailor-made often doesn't make sense until you start scaling.
Thank you! Yes, totally agree. I do hope to get there one day and would LOVE nothing more than to have a DBA take this to the next steps when we're bigger.
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.
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.
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.
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.
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
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.
