I used PlanetScale or a year or two before switching to Neon. I needed 1 database per tenant and PlanetScale didn't support that (you had to pay $30/mo per database, now it looks like $39/mo). My use-case is weird and I also don't need powerful servers (in fact I'd just as well prefer to run multiple databases on 1 server, I don't have a noisy-neighbor problem in my business). Neon let me do that but I couldn't on PS.
I get it, I'm a small fish trying to pay a little as possible for fully managed postgres (or MySQL before I switched to Postgres when I moved to Neon) to run my small, bootstrapped company with spiky [0] but fairly predictable load.
Best of luck to PlanetScale with this new offering, one day I hope I can use them again. I enjoyed the product and the support was great.
[0] I write software for food festivals, 9 months out of the year there is no traffic, ~2 months of the year there is a tiny trickle, ~3 weeks seeing high (but not "high" by any definition) and then 1-5 days (depending on how long the event is) there is a good deal of load but still not more than the lowest tier can handle most of the time. Like I said, I'm a _small_ fish and I don't expect them to cater to me, I just know what I want and almost no one provides it directly.
Is there some compliance reason or otherwise that you need one physical database per tenant, and can't just colocate multiple logical databases/schemas on one PlanetScale database?
That's kind of hard to do with the PlanetScale schema migration concept (branching). Doing something like prefixed tables doesn't work and you can't create multiple databases on 1 server (or at least you couldn't and I did ask support about it).
I could make my application multi-tenant in the application code but that would require a lot of refactoring and testing. It's possible but it's a big lift to do that. If I could do that, I'd have much more flexibility. I don't think compliance will ever be an issue for me so that isn't holding me back.
PlanetScale came out of Vitess, which was very MySQL-specific.
Does this new PostgreSQL offering share any heritage with Vitess or is this an entirely new piece of technology, or based on other components that PlanetScale have written since the Vitess days that aren't direct descendants?
> Vitess’ achievements are enabled by leveraging MySQL’s strengths and engineering around its weaknesses. To achieve Vitess’ power for Postgres we are architecting from first principles. We are well under way with building this new system and will be releasing more information and early access as we progress.
Simon I am a huge fan of your work. If you create a PlanetScale org and email me the name I will give you early access (free on us of course) s@planetscale.com
As a PlanetScale MySQL user for the past 2 years, this is really exciting for the Postgres community. (Worked at a company that ran both, was a bummer our tooling didn’t match.)
Using PlanetScale for db management is like using an iPhone after being accustomed to a Treo. The experience is just better in every way.
Really cool. It'll be interesting to see how Multigres (by Supabase) shapes up compared to this. I think it's great to have more/better competitive hosted Postgres offerings.
This is especially interesting because Multigres is being led by Sugu Sougoumarane, one of the Vitess co-creators and Planetscale co-founders - so the two projects are growing from the same soil, so to speak.
PlanetScale's move is intriguing, but sharding data across nodes is where the real challenge lies. Are the trade-offs similar to Vitess with MySQL, or does Postgres's feature richness complicate things further?
When data grows beyond a single machine, the hard work begins. Distributed systems sacrifice features like complex joins, extensions, and strong consistency. Maybe they should get Jepsen to poke at their setup. Who can show us what we lose compared to standard Postgres?
MySQL compatibility documentation https://planetscale.com/docs/vitess/troubleshooting/mysql-co... exists, it's not clear how that translates. I anticipate that even with a Postgres protocol, the practical experience of using PlanetScale will be fundamentally different from standard Postgres.
Hi! I'm the CTO of PlanetScale - the PostgreSQL offering we launched today is built on top of pure Postgres and doesn't come with any limitations.
The future sharded version will also be based on Postgres directly, and will be as compatible as possible. We're not looking to just speak the PG wire protocol to a different backend store.
Is there a particular reason on why Planetscale Postgres on Amazon EBS is excluded from the benchmarks? Although Metal would fit better in most cases but without it the benchmark looks incomplete.
I used PlanetScale or a year or two before switching to Neon. I needed 1 database per tenant and PlanetScale didn't support that (you had to pay $30/mo per database, now it looks like $39/mo). My use-case is weird and I also don't need powerful servers (in fact I'd just as well prefer to run multiple databases on 1 server, I don't have a noisy-neighbor problem in my business). Neon let me do that but I couldn't on PS.
I get it, I'm a small fish trying to pay a little as possible for fully managed postgres (or MySQL before I switched to Postgres when I moved to Neon) to run my small, bootstrapped company with spiky [0] but fairly predictable load.
Best of luck to PlanetScale with this new offering, one day I hope I can use them again. I enjoyed the product and the support was great.
[0] I write software for food festivals, 9 months out of the year there is no traffic, ~2 months of the year there is a tiny trickle, ~3 weeks seeing high (but not "high" by any definition) and then 1-5 days (depending on how long the event is) there is a good deal of load but still not more than the lowest tier can handle most of the time. Like I said, I'm a _small_ fish and I don't expect them to cater to me, I just know what I want and almost no one provides it directly.
Is there some compliance reason or otherwise that you need one physical database per tenant, and can't just colocate multiple logical databases/schemas on one PlanetScale database?
That's kind of hard to do with the PlanetScale schema migration concept (branching). Doing something like prefixed tables doesn't work and you can't create multiple databases on 1 server (or at least you couldn't and I did ask support about it).
I could make my application multi-tenant in the application code but that would require a lot of refactoring and testing. It's possible but it's a big lift to do that. If I could do that, I'd have much more flexibility. I don't think compliance will ever be an issue for me so that isn't holding me back.
> I needed 1 database per tenant
...Depending on how many tenants that is, Turso may fit your use case.
https://turso.tech/
PlanetScale came out of Vitess, which was very MySQL-specific.
Does this new PostgreSQL offering share any heritage with Vitess or is this an entirely new piece of technology, or based on other components that PlanetScale have written since the Vitess days that aren't direct descendants?
Update: to answer my own question https://planetscale.com/blog/planetscale-for-postgres#vitess...
> Vitess’ achievements are enabled by leveraging MySQL’s strengths and engineering around its weaknesses. To achieve Vitess’ power for Postgres we are architecting from first principles. We are well under way with building this new system and will be releasing more information and early access as we progress.
Simon I am a huge fan of your work. If you create a PlanetScale org and email me the name I will give you early access (free on us of course) s@planetscale.com
As a PlanetScale MySQL user for the past 2 years, this is really exciting for the Postgres community. (Worked at a company that ran both, was a bummer our tooling didn’t match.)
Using PlanetScale for db management is like using an iPhone after being accustomed to a Treo. The experience is just better in every way.
Congrats to the PlanetScale team!
Some cool scaling stuff [0] [1] coming out for pg lately. Looking forward to seeing what PS builds here, I've been a big fan for awhile.
Would love more details tbh, but will be watching regardless.
[0]: https://supabase.com/blog/multigres-vitess-for-postgres
[1]: https://pgdog.dev
We've really enjoyed working with Postgres to bring this product to market. I am here if anyone has questions.
I see benchmarks against Aurora, but I’m curious to see how this compares to Aurora Optimized reads which caches data in a local NVMe SSD. https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide...
Really cool. It'll be interesting to see how Multigres (by Supabase) shapes up compared to this. I think it's great to have more/better competitive hosted Postgres offerings.
This is especially interesting because Multigres is being led by Sugu Sougoumarane, one of the Vitess co-creators and Planetscale co-founders - so the two projects are growing from the same soil, so to speak.
https://youtu.be/28q9mFh87KY?si=SK3f1OEApWRlcr83
Oh I am late to the party on what should have been big news. Why isn't this on the front page!
Wondering will any of the tech be open source?
Congratulations! What's the availability of extensions? Any limitations worth knowing about?
off-topic, but from the same website: this gem https://planetscale.com/learn/courses/mysql-for-developers
Hey, that's me! Glad you liked it :)
PlanetScale's move is intriguing, but sharding data across nodes is where the real challenge lies. Are the trade-offs similar to Vitess with MySQL, or does Postgres's feature richness complicate things further?
When data grows beyond a single machine, the hard work begins. Distributed systems sacrifice features like complex joins, extensions, and strong consistency. Maybe they should get Jepsen to poke at their setup. Who can show us what we lose compared to standard Postgres?
MySQL compatibility documentation https://planetscale.com/docs/vitess/troubleshooting/mysql-co... exists, it's not clear how that translates. I anticipate that even with a Postgres protocol, the practical experience of using PlanetScale will be fundamentally different from standard Postgres.
Hi! I'm the CTO of PlanetScale - the PostgreSQL offering we launched today is built on top of pure Postgres and doesn't come with any limitations.
The future sharded version will also be based on Postgres directly, and will be as compatible as possible. We're not looking to just speak the PG wire protocol to a different backend store.
Is there a particular reason on why Planetscale Postgres on Amazon EBS is excluded from the benchmarks? Although Metal would fit better in most cases but without it the benchmark looks incomplete.