Ep 513 Blog 5:47 w/ Justy & Cody

PlanetScale the world’s fastest and most scalable cloud hosting for Vitess and Postgres

Justy and Cody react to PlanetScale’s pitch that its cloud databases are built around speed, scaling, and operational simplicity, with Vitess for horizontally sharded MySQL and PlanetScale Postgres for managed PostgreSQL. They dig into the actual mechanism claims, where the sharding story is real, where the marketing gets broad, and who would actually feel the difference.

Embed this episode

Paste this on any site — the player is a self-contained iframe with no cookies or trackers.

<iframe src="https://sandrise.io/exploring-next/embed/513"
  width="100%" height="180" style="max-width:640px;border:0;border-radius:12px;overflow:hidden"
  title="Exploring Next — Episode 513 audio player"
  loading="lazy" allow="autoplay" referrerpolicy="strict-origin-when-cross-origin"></iframe>
Embed & API docs →
Script GPT-5.4 mini Voice ElevenLabs v3

Transcript

Justy Okay, this is either a very clean database pitch or the most confident sentence on the internet. "Fastest databases available in the cloud" is doing a lot of work.

Cody Yeah. The useful part is underneath that slogan. Vitess gives you explicit sharding, so you can spread MySQL data across a bunch of nodes and still present one connection point through VTGate. That’s real architecture, not just speed glitter.

Justy I got snowed in by errands this morning in the most boring way possible. Forgot my charger, sat in traffic, and then spent ten minutes looking for a coffee place that wasn’t packed. Very glamorous life over here in L A.

Cody Mm-hm.

Justy Anyway, that’s why I care about this. If a database vendor can take some of the scarier scaling and failover stuff off a team’s plate, that changes what a product team can ship without staging a tiny rescue mission every week.

Cody Right, but the trade-off is that Vitess is not a casual upgrade. You’re buying into a shared-nothing system with routing, shard management, and the discipline that comes with it. That’s great when you actually need thousands of nodes and petabytes. It’s less cute if your app is still figuring out whether it has five real tables or six.

Justy No way.

Cody And the source does give one nice anchor there: Vitess was built at YouTube, then it’s now used by places like Slack, HubSpot, GitHub, Etsy, Blizzard, Block, Bloomberg, Yelp. That at least tells me this is not some demo-ware abstraction. It’s battle-tested in ugly traffic patterns.

Justy That part I buy more than the slogan. Also, the Cursor quote is the kind of thing product people latch onto immediately, because millions of queries per second on hundreds of terabytes sounds like someone already did the terrifying version of the job and lived to tell the tale.

Cody Exactly.

Justy What I like is the second half of the pitch, too. PlanetScale Postgres starts at five bucks a month, says it’s fully managed, and keeps the developer experience front and center. That’s a very different buyer than the huge sharded-workload crowd, and I think that’s smart.

Cody It is, but I’d be careful not to mash those stories together too hard. The Postgres offering is about managed reliability and decent defaults. The Vitess story is about horizontal scale and routing complexity. Same company, very different pain points.

Justy Thank you for refusing to let the marketing brochure become a personality.

Cody Somebody has to do it. Also, the NVMe part matters more than the copy makes it sound. Fast local storage and high IOPS can absolutely change tail latency and write-heavy workloads. But if your bottleneck is query design or bad indexes, no drive on earth is going to save you.

Justy Right, and that’s the practical filter. If you’re running a serious product and the database is already the thing making the room tense, this looks interesting. If you’re still early, I think the pitch should mostly read as, "we’ll be there when you outgrow the easy version."

Cody Sure, but I do think the compliance angle is real too. Bring your own cloud and the availability-zone failover story matter for teams that can’t just shrug and move data around. That’s boring infrastructure work, which is usually where the real budget goes.

Justy Okay, so the actual argument is less "database magic" and more "we made the hard parts explicit and packaged the rest." That feels like a sane thing to sell, even if the headline is a little extra.

Cody Very extra. But, yeah, the architecture is the product here. If you need that shape, it’s compelling. If you don’t, it’s just an expensive way to feel sophisticated about your tables.

Justy That is such an Exploring Next sentence, Cody. I’m going to pretend I’m not delighted by it. Anyway, I think I’m out of coffee and one charger down, which feels on brand for this whole conversation.

Justy All right, I’m calling it there before we start naming our tables out loud. This was weirdly the most database energy I’ve had all week, which is honestly rude.