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.
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.
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?
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?
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.
17 comments
[ 2.8 ms ] story [ 43.0 ms ] threadUsing 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!
Would love more details tbh, but will be watching regardless.
[0]: https://supabase.com/blog/multigres-vitess-for-postgres
[1]: https://pgdog.dev
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.
https://youtu.be/28q9mFh87KY?si=SK3f1OEApWRlcr83
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?
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.
...Depending on how many tenants that is, Turso may fit your use case.
https://turso.tech/
Wondering will any of the tech be open source?