I wonder why other providers don't use metal ssd sync replication technique that planetscale uses? Most of them just default to EBS.
My interest in it peaked when I heard about NVMe over Fabrics (NVMe/TCP) and SPDK from Xata[1] and apparently with that performance is as good as planetscale metal, but planetscale found their methodology flawed[2] and they Xata never responded.
@samlambert what exactly makes it hard? Isn't it as simple as setting synchronous_commit=remote_apply or does planetscale have a custom strategy or are there other operational issues?
Just asking since I find it both the planetscale's engineering and its impact on competitive landscape very interesting.
you have to make sure you will never terminate these nodes, that you have all the operations maturity to cycle them responsibly, and resize them. I am sure they will get there one day but most people are still figuring out how to run databases on k8s so it's a long road.
This is actually a really interesting offering to have available as someone who needs DEV tier PG databases for a better testing pipeline on a shoestring budget.
Should I consider this if I’m using Render or fly.io for my services? Would latency be an issue? On my day job I cluster in the same AWS AZ and don’t realize what impact this would have for an app that may not be colocated.
Really big impact! I'm not sure how fly or render work but if your compute instances are in $city make sure your planetscale instance is too. You shouldn't be far off 'in region aws' latency at the point.
oh how i wish they were in azure. azure's postgresql flex offering is horrid. for some reason the HA standby instance can't be used as a read replica, it's filled with maintenance windows / downtime-ful upgrades / etc..
Most people only need a single database node and will only ever need a single database node. There are many LOB apps in the world that you could reasonably turn off from 5 pm to 9 am every day. Five 9’s is an incredibly expensive and often unnecessary feature. I think this is a great offering.
Funnily enough I've been contemplating the idea of websites open during business hours and such for "local" as in kinda national scales. But it breaks down quickly once you factor in a potentially global audience.
So yeah, in the end available as much as possible (while sounding like "I needed it yesterday") might be the way to go even if you're not actually aiming for the extreme end of uptime.
Government websites like that aren't crazy uncommon because the letter of the law around accessibility can be interpreted to require a real person to be available any time the website is available for certain electronic forms: https://freakonomics.com/2012/08/this-website-only-open-duri...
(people in the comments did not get the correct reason why)
I like PlanetScale, but they already have precedent very recently for having a free-tier and then cancelling it for a minimum of $40/month plan, which made many people switch. What's to stop them from doing the same here?
Be wary of building a cheap hobby project on it expecting pricing to stay consistent. If $40+ isn't feasible for you, you may be trying to switch off to a hosted PostgreSQL option, with all the pain MySQL->Postgres entails, soon.
(Planetscale employee)
This is very different though: it's not a free tier, it's an actual single node DB as a paid product. It's definitely not a good fit for every usecase, but if you have a hobby project it's a great way to start with plenty of room to scale if/when you get actual usage
Similarly to other replies (but my own opinion): it's not a huge source of revenue today, on a single customer basis, compared to our biggest customers, sure. But our goal is to provide potential customers that can't justify larger scale, 3-nodes databases, something they can build on and grow on our platform.
We would never want to pull the rug on paying customers: we want to enable them :-) sure it's not a huge part of our revenue, but that's not the goal. We just want to provide a great product, in a way that's affordable to everyone.
You of course don't have to take my word, but I think it makes business sense to do this and not pull the rug.
Compare to a free tier where you bleed money in the hopes that customers will end up paying you. Hope isn't a good business strategy right? :-)
In what way? Companies drop/move on from small customers all the time as positions and analysis changes. $5 a month might make sense now, but with thin profits, a lower than predicted "upgrade rate" and maybe a higher than anticipated support cost etc and this becomes a less profitable option without price increases, which loses customers causing more increases because of none scalable costs etc.
Throw in a change of leadership or business focus and it's an easy short term boost to drop the many smaller customers and focus on the big fish who make the real money.
It's a common pattern, echoed over many industries, and while you might not see it being likely here right now, if the concept literally doesn't make sense to you, you need to look up some basic business ideas because it's a pretty valid concern.
It's easier to pull the rug out from under a group of customers who earn you 5% of your revenue than it is to do the same thing to a group of customers who make you 25% of your revenue.
This small $5 plan is obviously not going to make Planetscale very much revenue.
You were buying flow for your sales funnel with a free plan now you want to attract users with a low tier plan. Your reputation was hurt with the first rug pull so why be surprised that users expect another rug pull from you in the future?
Why would we? we make a (small) profit on these cheaper tiers. We are a sustainable and profitable company. Also the free tier wasnt cancelled very recently it was 1.5 years ago so you are reaching a bit here.
Your $5 plan may be gross margin positive but incentives are to push users into higher margin plans and from this pov this new plan looks much like your previous free plan which was rug pulled. Offering a free service to buy users then imposing migration costs on these users when you rug pull damaged your reputation. Next time perhaps grandfather existing users instead. If you want this new plan to be taken seriously update your terms to promise you will not rug pull again.
Case in point. Potential customers will see this dismissal as the equivalent of how long they expect this pricing to remain. You’re free to increase the price in a year and when customers are irked, “why isn’t it $5 anymore?” They’ll be met with “that’s not recent.” “That was so long ago”
If you want to rebuild reputation with hobby tier, you’ll probably want to put in a 3 year pricing guarantee, not 1 month like the notice last time.
I wonder why other providers don't use metal ssd sync replication technique that planetscale uses? Most of them just default to EBS.
My interest in it peaked when I heard about NVMe over Fabrics (NVMe/TCP) and SPDK from Xata[1] and apparently with that performance is as good as planetscale metal, but planetscale found their methodology flawed[2] and they Xata never responded.
[1] https://xata.io/blog/reaction-to-the-planetscale-postgresql-...
[2] https://planetscale.com/benchmarks/xata
It's very hard to do. They all want to do it but can't so now it's their marketing team's jobs to lie to people about why they shouldn't want it.
@samlambert what exactly makes it hard? Isn't it as simple as setting synchronous_commit=remote_apply or does planetscale have a custom strategy or are there other operational issues?
Just asking since I find it both the planetscale's engineering and its impact on competitive landscape very interesting.
you have to make sure you will never terminate these nodes, that you have all the operations maturity to cycle them responsibly, and resize them. I am sure they will get there one day but most people are still figuring out how to run databases on k8s so it's a long road.
This is actually a really interesting offering to have available as someone who needs DEV tier PG databases for a better testing pipeline on a shoestring budget.
btw I've used neon for that and it worked well. Disclaimer: I have no relationship with them, I just have a shoestring budget.
Should I consider this if I’m using Render or fly.io for my services? Would latency be an issue? On my day job I cluster in the same AWS AZ and don’t realize what impact this would have for an app that may not be colocated.
Really big impact! I'm not sure how fly or render work but if your compute instances are in $city make sure your planetscale instance is too. You shouldn't be far off 'in region aws' latency at the point.
oh how i wish they were in azure. azure's postgresql flex offering is horrid. for some reason the HA standby instance can't be used as a read replica, it's filled with maintenance windows / downtime-ful upgrades / etc..
Will it be planet scale still?
Going from 3 node highly available multi region DB clusters at 30$ per month to 5$ a month for a single DB node
Most people only need a single database node and will only ever need a single database node. There are many LOB apps in the world that you could reasonably turn off from 5 pm to 9 am every day. Five 9’s is an incredibly expensive and often unnecessary feature. I think this is a great offering.
Funnily enough I've been contemplating the idea of websites open during business hours and such for "local" as in kinda national scales. But it breaks down quickly once you factor in a potentially global audience.
So yeah, in the end available as much as possible (while sounding like "I needed it yesterday") might be the way to go even if you're not actually aiming for the extreme end of uptime.
B&h photo video closes their order system on Jewish holidays in the NYC time zone. I often find myself saving items to order the next day on there.
Government websites like that aren't crazy uncommon because the letter of the law around accessibility can be interpreted to require a real person to be available any time the website is available for certain electronic forms: https://freakonomics.com/2012/08/this-website-only-open-duri...
(people in the comments did not get the correct reason why)
What does the durability story look like for this single node offering ?.
data is still replicated safely from the single node which is also backed by EBS.
How much vCPU, memory, and storage will this have?
Stay away from them, You never know when they pull the rug
How hard could it be to migrate away from $5/m worth of a managed PG?
pull the rug on what? a profitable product?
Is it possible to install Timescale on those?
we are working on the open source licensed version.
I like PlanetScale, but they already have precedent very recently for having a free-tier and then cancelling it for a minimum of $40/month plan, which made many people switch. What's to stop them from doing the same here?
Be wary of building a cheap hobby project on it expecting pricing to stay consistent. If $40+ isn't feasible for you, you may be trying to switch off to a hosted PostgreSQL option, with all the pain MySQL->Postgres entails, soon.
(Planetscale employee) This is very different though: it's not a free tier, it's an actual single node DB as a paid product. It's definitely not a good fit for every usecase, but if you have a hobby project it's a great way to start with plenty of room to scale if/when you get actual usage
It's very similar in that it's not a huge source of revenue for Planetscale, so easy to pull the rug without disrupting revenue too much
Similarly to other replies (but my own opinion): it's not a huge source of revenue today, on a single customer basis, compared to our biggest customers, sure. But our goal is to provide potential customers that can't justify larger scale, 3-nodes databases, something they can build on and grow on our platform. We would never want to pull the rug on paying customers: we want to enable them :-) sure it's not a huge part of our revenue, but that's not the goal. We just want to provide a great product, in a way that's affordable to everyone. You of course don't have to take my word, but I think it makes business sense to do this and not pull the rug. Compare to a free tier where you bleed money in the hopes that customers will end up paying you. Hope isn't a good business strategy right? :-)
this makes no sense to me
In what way? Companies drop/move on from small customers all the time as positions and analysis changes. $5 a month might make sense now, but with thin profits, a lower than predicted "upgrade rate" and maybe a higher than anticipated support cost etc and this becomes a less profitable option without price increases, which loses customers causing more increases because of none scalable costs etc.
Throw in a change of leadership or business focus and it's an easy short term boost to drop the many smaller customers and focus on the big fish who make the real money.
It's a common pattern, echoed over many industries, and while you might not see it being likely here right now, if the concept literally doesn't make sense to you, you need to look up some basic business ideas because it's a pretty valid concern.
It's easier to pull the rug out from under a group of customers who earn you 5% of your revenue than it is to do the same thing to a group of customers who make you 25% of your revenue.
This small $5 plan is obviously not going to make Planetscale very much revenue.
It's not made to make money, but to funnel paid customers onto their platform.
but its entry level pricing for customers that grow. it will be great for us. there is no point hurting our reputation and slowing growth.
You were buying flow for your sales funnel with a free plan now you want to attract users with a low tier plan. Your reputation was hurt with the first rug pull so why be surprised that users expect another rug pull from you in the future?
I think what Sam means is $5/mo is already profitable for them. Free plan wasn't.
Why would we? we make a (small) profit on these cheaper tiers. We are a sustainable and profitable company. Also the free tier wasnt cancelled very recently it was 1.5 years ago so you are reaching a bit here.
Why would a company squeeze customers after making them dependendent? Never heard of it.
Also what was capitalism again?
the reason we make sure all our products are gross margin positive is so this doesn't have to happen.
Your $5 plan may be gross margin positive but incentives are to push users into higher margin plans and from this pov this new plan looks much like your previous free plan which was rug pulled. Offering a free service to buy users then imposing migration costs on these users when you rug pull damaged your reputation. Next time perhaps grandfather existing users instead. If you want this new plan to be taken seriously update your terms to promise you will not rug pull again.
This is a lazy response.
You currently make a small profit on cheaper tiers. Things change
Compute, storage, and network throughput are only getting cheaper over time. Assuming all other costs hold steady, it should only get more profitable.
A bit of unsolicited advice:
This post is the first time I've heard of your company and your blog post interested me.
When proprietors go to the mat in the comment section, I immediately lose any interest in patronizing them.
I know comments section drama is fun, but I'm not seeing it here and it feels like you're trying to create it from scratch.
I think it's great evening entertainment. Keep fanning the flames while I go make some popcorn!
Sam is a great twitter follow
thank you
Off-topic, but you have a typo on your pricing page: "high-availablity"
why is it going to the mat? i had to correct something that was untrue. 1.5 years is not very recently.
1.5 years ago is recently IMO.
Case in point. Potential customers will see this dismissal as the equivalent of how long they expect this pricing to remain. You’re free to increase the price in a year and when customers are irked, “why isn’t it $5 anymore?” They’ll be met with “that’s not recent.” “That was so long ago”
If you want to rebuild reputation with hobby tier, you’ll probably want to put in a 3 year pricing guarantee, not 1 month like the notice last time.