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!

We've really enjoyed working with Postgres to bring this product to market. I am here if anyone has questions.

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

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.

Congratulations! What's the availability of extensions? Any limitations worth knowing about?

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.

off-topic, but from the same website: this gem https://planetscale.com/learn/courses/mysql-for-developers

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 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.

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?