ABOUT THIS EPISODE
Sam Lambert, my former boss at PlanetScale, talks to me about PlanetScale moving from a MySQL company to now also having a Postgres offering. Sam shares why PlanetScale decided to move to Postgres, how MySQL and Postgres are different at a technical level, and how the change has impacted the company culture. Stay to the end for a special surprise!
PlanetScale Metal Episode: https://youtu.be/3r9PsVwGkg4
Join the waitlist to be notified of the MySQL for Developers release on Database School:
https://databaseschool.com/mysql
Follow Sam:
PlanetScale: https://planetscale.com
Twitter: https://twitter.com/isamlambert
Follow Aaron:
Twitter: https://twitter.com/aarondfrancis
LinkedIn: https://www.linkedin.com/in/aarondfrancis
Website: https://aaronfrancis.com - find articles, podcasts, courses, and more.
Database School: https://databaseschool.com
Database School YouTube Channel: https://www.youtube.com/@UCT3XN4RtcFhmrWl8tf_o49g (Subscribe today)
Chapters:
00:00 - Inaugural episode on this channel
01:46 - Introducing Sam Lambert and his background
03:04 - How PlanetScale built on MySQL and Vitess
06:10 - Explaining the layers of PlanetScale’s architecture
09:57 - Node lifecycles, failover, and operational discipline
12:02 - How Vitess makes sharding work
14:21 - PlanetScale’s edge network and resharding
19:02 - Why downtime is unacceptable at scale
20:04 - From Metal to Postgres: the decision process
23:06 - Why Postgres vibes matter for startups
27:04 - How PlanetScale adapted its stack for Postgres
34:38 - Entering the Postgres ecosystem and extensions
41:02 - Permissions, security, and reliability trade-offs
45:04 - Building Ni: a Vitess-style system for Postgres
53:33 - Why PlanetScale insists on control for reliability
1:02:05 - Competing in the broader Postgres landscape
1:08:33 - Why PlanetScale stays “just a database”
1:12:33 - What GA means for Postgres at PlanetScale
1:17:43 - Call to action for new Postgres users
1:18:49 - Surprise!
1:22:21 - Wrap-up and where to find Sam
