41–50 of 71 posts
What exactly is PlanetScale Postgres? Is it plain managed Postgres ala RDS or something more bespoke like Neon? I know PlanetScale is working on a Vitess-like sharded Postgres (Neki?) but I’m guessing that is not yet running in the cloud?
Earlier quoted context omitted.
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: https://planetscale.com/blog/planetscale-for-postgres
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?
Earlier quoted context omitted.
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.
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.
If you have a constant base load of requests, lambda is just the wrong tool for the job.
Way too much for a project without a budget, and approximately zero for a project with a budget.
I realize this wasn't the main reason they switched, but from my perspective, $156/mo and $250/mo for db is essentially the same number: Way too much for a project without a budget, and approximately zero for a project with a budget.
I realize this wasn't the main reason they switched, but from my perspective, $156/mo and $250/mo for db is essentially the same number: Way too much for a project without a budget, and approximately zero for a project with a budget.
> 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.
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.
What exactly is PlanetScale Postgres? Is it plain managed Postgres ala RDS or something more bespoke like Neon? I know PlanetScale is working on a Vitess-like sharded Postgres (Neki?) but I’m guessing that is not yet running in the cloud?
It's more like rds but it has far better developer experience than rds with dashboards and better migration. Their unique offering is their metal offering which uses local SSD for superior performance https://planetscale.com/metal
Earlier quoted context omitted.
> 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 wi…
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…
> 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.