Transcript

[Banjo music]

MANTRA: Just Build Websites!

Dave Rupert: Hey there, Shop-o-maniacs. You're listening to another episode of the ShopTalk Show. I'm Dave--the Base--Rupert and with me is Chris--

Chris Coyier: [Laughter]

Dave: --Catenation--Coyier. Hey! How are you? [Laughter]

Chris: Whoa!

Dave: That was good, right?

Chris: That was really good. Those, dear listeners, were very dumb database jokes.

[Laughter]

Chris: Apparently, databases are cool again. We've been talking a lot about data here on this show because, as I've told you, Dave, I'm a backend developer now.

Dave: Oh, hey. Looking good.

Chris: Switched over.

Dave: Yeah.

Chris: Yeah, I'm going to keep mentioning that until it sticks.

Dave: You're beard is a bit lower.

Chris: Mm-hmm.

Dave: Yeah, it's good.

Chris: Yeah.

Dave: A bit neckier.

Chris: It stops a little too high, though.

Dave: Yeah.

Chris: I'm going to get it growing down here soon.

Dave: It's good.

[Laughter]

Chris: We have some special guests to talk about another data product. Just last week, we were talking about it. We had some guys on from Sanity who have a very different approach to data. This is going to be very different from that.

I'd say the scale of it is going to be a little bit more planetary this week. Dave, who do we have with us today?

Dave: We have two special guests from PlanetScale. Iheanyi--

Chris: You're both Texas guys, right? Apparently.

00:01:34

Iheanyi Ekechukwu: Yeah.

Dave: Yeah.

Iheanyi: H-town for me. Met in Austin, though.

Dave: Met in Austin.

Iheanyi: Met back there way back when.

Chris: Mm-hmm.

Dave: Seven, ten years ago.

Iheanyi: Yeah.

Dave: Then you brought along a buddy from your work, Mike. Hey, Mike.

Iheanyi: Yeah, Mike Coutermarsh.

Mike Coutermarsh: Best friends. Iheanyi and I have been on the same team for, what is it, four or five years now.

Iheanyi: Going on five.

Mike: Going on five. We get attached.

Iheanyi: We're a combo package.

Dave: [Laughter] Yeah, you come together, a set. Yeah, well, we were talking before the show. You both have pretty deep... Maybe it's worth getting into before we talk about PlanetScale. You both have pretty deep histories working at some big companies and stuff like that. Mike, do you want to walk through y'all's journey together?

[Laughter]

Mike: I can start with me and I'll come to where we met up.

Iheanyi: Yeah.

Mike: I've just been working on really cool Rails apps for a long time. I got good at Ruby, and I just stuck to it. I worked at Product Hunt, which is a Rails app with a cat mascot.

Chris: Is it really a Rails app? You never know.

Mike: Yeah.

Chris: I knew GitHub was.

Mike: Yeah.

Chris: Famously. But yeah, okay, so a Rails guy goes to major Rails installs in the world. That's great.

Dave: How does Product Hunt, an app known for publicly shaming Rails apps, be a Rails app?

[Laughter]

Iheanyi: That's a pretty good question. I never really thought about that.

Mike: Wait. Does Product Hunt shame Rails apps?

Dave: No.

Iheanyi: The community. The community. The community.

Dave: The broader, you know.

Mike: Oh, well, maybe they just don't know the backend is all Rails. Hey, so originally, the UI was in Rails and then we installed React when it was still beta.

Dave: Oh, wow. Wow.

Mike: I know. I got the pain and the gray hairs.

Dave: I was going to say, that's a horror story if I've ever heard one.

Iheanyi: Is that whenever you became a gray beard is whenever you started using React in beta, beta moments?

Mike: Thankfully, seven years later, it's improved quite a lot.

Iheanyi: A lot, a lot, a lot.

Chris: I can feel that. We still have some hilarious pages on CodePen where the front-end is all React and the back-end hits a Go server that's running a GraphQL thing. It has nothing to do with Rails. The front-end has nothing to do with Rails, and the back-end has nothing to do with Rails except for Rails puts the little div there.

Mike: Hmm...

Chris: You know. It uses nothing of Rails.

Iheanyi: Then y'all are just like, "Well, it works, so let's not even waste time undoing that."

Chris: Yeah, right. It hits the little routes file, and it says, "Oh, I know what to do. I'll render this little ERB file that has nothing in it." Anyway--

Dave: Okay, so you're working, doing Rails, and then you ended up where, at GitHub, after Product Hunt?

00:04:24

Mike: Yep. I joined GitHub to build this part of the site called Marketplace. I worked on that for maybe a year and a half, and then GitHub Actions was spinning up internally. It wasn't called Actions at the time, but they kind of just brought--

Iheanyi: Yeah.

Mike: --a team together and, with a bunch of work, a couple of years later, what came out is what everyone gets to use today. Iheanyi and I--

Iheanyi: Yeah.

Mike: --built Actions together. We were on the same team.

Iheanyi: Yep.

Mike: That's where I think we experienced the, "Hey, there's a small beta project," into huge, scale-up problems for the first time, really.

Chris: It's got to be the biggest thing GitHub has done in five years, easily, right?

Iheanyi: I call it my magnum opus. Also, it's a fun fact. The iteration that people are using today is like the third iteration of the product.

Mike joined at like iteration two or three, I think. I'd been there from like early... The back-end got rewritten like three times to what was launched today. Lots of different trial and error. But what we ended up landing on is what stuck.

Lots of learning lessons. It was a good learning experience figuring out how to build a product that people love and use. Lots of flights, lots of offsites and meetings, lots of whiteboards, but it was a good time.

Chris: I believe it, and I would say it is fricken' awesome now and has a long way to go. I know neither of you are there now. Let's get to that. But my God, I hope whoever picked up the torch after... people come and go from that. I'm sure it wasn't just only you two, right? But maybe you're very important to it. But whoever picked up your old--

Mike: It's probably a 100-person team, 100+ at this point.

Chris: Hmm.

Dave: Oh, wow.

Iheanyi: It's crazy.

Chris: All good.

00:06:02

Iheanyi: When I first joined, it was like a ten-person team. It's just weird how it's just expanded, but they're doing great things and the product keeps on getting better. Loving it.

Chris: I feel like we personally pay one developer's salary in usage, just use.

[Laughter]

Dave: But smash ... Iheanyi, your path to GitHub was you were at a company that shall not be named (enterprise software).

Iheanyi: If you can even call them that, in Austin. I worked at DigitalOcean for two and a half years in New York City.

Funny enough, I started at DO as a front-end developer. Then - I don't know - I'm full stack, but DigitalOcean did some Rails stuff here and there. But then I joined the networking products team, and that's where I learned how to write Go.

I was working on cloud firewalls, DigitalOean's virtual private cloud offering on the product side just doing Go, a little bit of Ruby here and there because DigitalOcean also has a Rails API. Of course, Ember on the front-end.

I ended up at GitHub because the VP of design at the time hit me up. He's like, "We're working on this cool, new secret project. I think you'd be a good fit for it."

I had to sign an NDA and go through the interview process. I was like, "Oh, Actions look really dope, and I think it's going to be a game-changer for GitHub."

Yeah, I took that leap of faith and ended up going to GitHub and help launch Actions. Like Mike said, scaling it up from nothing to a lot of something was really fun.

Dave: That's cool. Then how many years, one, two years later, after Actions comes out, you both jump ship, right?

00:07:35

Iheanyi: Yeah. Yeah, yeah. I ended up going to PlanetScale. Funny enough, our skip-skip level, one point in time was the CEO, Sam Lambert. You know I enjoyed working under him. For some reason, that man is probably one of the most convincing people in the world. I don't know if it's the accent or if it's just how he's good at selling things, but the vision caught me.

Databases are one of those things that we use at every single point of our life in our careers as engineers, right? Nobody has really innovated on it, right? Things have been kind of stale, boring, not really pushing the needle forward.

I was like, "Okay, I think I have an opportunity to build something big here." You know there's this concept. We used Vitess at GitHub, right? I've known some of the tooling that we had built in-house to support database migrations and all that.

Taking the opportunity to productionize that and product-fy it and turn it into an actual product for other companies was pretty exciting. So, I'm like, "You know what? Let me take this leap of faith. If it doesn't work out, whatever. It's not the end of the world," but I've been having a fun time, and Mike joined a couple of months after.

Dave: Nice. Another poach.

[Laughter]

Dave: I mean, I guess, legally we can say that. Yeah. Mike, you joined. Mike, are you doing then more Rails stuff at PlanetScale? Is that your domain?

00:08:59

Mike: We both do a lot of Rails stuff. Yeah. Iheanyi downplayed it, but he's a big Ruby guy.

[Laughter]

Iheanyi: A little bit.

Dave: Pass himself off as a Go developer.

Iheanyi: I mean I built the CLI in Go. Me and Phani pretty much built the entire CLI, and that's in Go. But I'd done a lot.

I was the first commit to the Rails codebase, so I guess that counts for something. But yeah, I wrote a lot of Ruby. It's fun. It's grown on me.

We're just all full-stack engineers, and it's great being able to do front-end, back-end, and then sometimes doing systems work as well. I dig it.

Chris: I think we've got a good picture of you two, although any other stuff you want to add, don't let me cut you off. It's nice to see what developers' journeys are. But I am so interested.

You're compelled to move to PlanetScale from a string of otherwise great jobs. Obviously, I know there was this persuasive fellow that got you to go, but I'm sure you were persuaded by the product and what it's doing, too, which I know little about. I mean I know that it's a database product, but what?

Not that we want to make this whole thing a pitch, but pitch me. Pitch me. What is it?

Mike: I can share why I left, and then I think people will get it.

Chris: Okay.

00:10:13

Mike: The big thing for me was when we were at GitHub, we just had all of this incredible tooling. And people who have worked at bigger companies understand this. If you haven't, you sort of just haven't seen these things.

These companies build these tools internally. They make things really easy, easy to work together, handle these scaling problems. But the stuff doesn't really exist outside of these big companies.

The promise was, "Hey, we use Vitess at GitHub," and I was familiar with it. It works really well with some of our scaling problems. "We are going to build a cloud database that is using Vitess, and it's going to be perfect for serverless."

It was the combination of these things, "Hey, this is this tech that I know and I really believe in." Right? It's based on very solid fundamentals. It's a SQL relational database, MySQL, Vitess. This is stuff that's very mature and big companies rely on.

Then at the same time, this is when serverless was happening. We want to use a database from Cloudflare workers.

I don't know if people remember but, two years ago, that wasn't possible. Then this year it is. So, we were able to take these things that we had at GitHub and then just wrap tooling around it to make it really easy to use. Then also use it for serverless, which I was excited about. I couldn't say no to it.

Dave: That's interesting. Vitess, you've said that a couple of times. What is it exactly? I see it's a MySQL-compatible cloud.... But can you put it in idiot terms for me?

00:11:53

Mike: Yeah, so Vitess is a scaling layer for MySQL, and it was born at YouTube. YouTube was using MySQL, and they started to have--

Dave: Oh....

Mike: Yeah, you've heard of it. Yeah.

Dave: False startup. Yeah. Yes.

Chris: [Laughter]

Dave: Small startup. Yeah.

Mike: Yeah. It was at a small startup called YouTube. They started having these scaling problems. Nothing existed, really, to handle YouTube's scale, so they started adding tooling.

The first thing they did was, okay, if we get 1,000 queries asking for the comment section on a YouTube video at once, instead of hitting MySQL 1,000 times, we will just hit it once but then return the result 1,000 times. That's essentially a load balancer for MySQL.

Dave: Mm-hmm.

Mike: Then they just kept adding little tools. Eventually, they got to the point where, okay, we're going to start sharding and spreading the data over multiple instances.

Eventually, the engineers who worked on this pushed really hard to have it open-sourced. Then other companies started jumping on it, such as GitHub and Slack are now using this for their data.

Dave: I thought maybe... I heard, for scalability or whatever, and I didn't know if some kind of testing was kind of wrapped up into that, like load or whatever. You know?

Mike: Well, the thing with systems at this scale, it's difficult to test or set up a test environment that is similar to production. Right?

Dave: Yeah.

Mike: We've heard recently all of that, all about Twitter's infrastructure, right? They go, "Hey, we don't have a staging environment that matches production." Well, when you've worked at this scale, you understand it's not possible.

Iheanyi: Yeah.

Mike: Because you're running so much. But yeah, people will do load testing at smaller amounts. But really a lot of... Your best indicator of whether something works is in product.

Dave: Right, because it would cost a billion dollars to shoot that many computers at my computer. Right.

Iheanyi: Yeah. Yeah.

Chris: I understand that that's super extreme scale. But I feel like there's a medium one where it's a little bit more possible. Isn't it? I know at CodePen we have prod, and then we have a staging DB that is a replica. It just gets written to... It's - I don't know - five minutes behind or something. That's not totally out of the realm of possibility for us cost-wise to maintain them both. But Twitter is just too big to even do that?

Iheanyi: Yeah.

Mike: Yeah.

Iheanyi: Yeah.

[Laughter]

Chris: Okay.

00:14:28

Mike: The way these companies usually test rolling out new features, right, so for a lot of us, we go, "I deploy it at staging and then I test it there." You can't do that.

At GitHub, everything would be around feature flags, and you'd roll it out to a small percentage of people. Say I had this new feature. It's behind a feature flag. It goes to 1%. Then I'm monitoring those metrics to make sure it's okay. Then you slowly roll it out. That's how you test in prod.

Chris: Hmm. Yeah. It's all flags all the time. No wonder there are so many startups that are just, "We help you do feature flags."

Iheanyi: Yep.

Chris: Yeah. There's an article from the fall of last year by James Reagan, and maybe you saw it, "Why you should really take a look at PlanetScale," and he mentions this Vitess thing. It's interesting, too. I wonder if I'll just read from it quick.

He was talking about there's vertical scaling, which is the idea that you have this database interest, and you just throw it on a bigger thing with more memory, more CPUs, so there's that. Then there's horizontally scaling like sharding, I guess, right? Have multiple copies of it or something. I can't talk about it particularly eloquently.

Then he's like, "Is it just those two things? Are those are only options for scaling a database?" He says, "There is a particular technology that addresses this shortcoming for MySQL databases. I'm talking about Vitess, which powers many of the largest and most trafficked sites on the Web like YouTube, Pinterest, Slack, and others. Vitess is an early Go project that implements and manages horizontal sharding, improves quality performance, and eliminates connection memory overhead for MySQL databases."

He says, you know, it sounds great. Sign me up. There's just one catch. Vitess can be complicated to implement in production - yadda-yadda-yadda. PlanetScale is powered by Vitess under the hood. That's half of what makes it so amazing, in my opinion.

Cool. Right? Good words from Mr. James.

00:16:21

Iheanyi: I like it. You know it's what we like to hear. We want to take away the operational complexity, right? Vitess can... At GitHub, we did have a whole database team that would spin up the test clusters for us and manage that in-house. But you know PlanetScale wants to bring the power of Vitess to every single developer.

The ability to do zero downtime, like migrations, like all of that to your schema, that is powered by Vitess under the hood. But building on top of it and being able to build a UI is kind of what is so great about PlanetScale, right? Vitess is a powerful primitive.

I think, also, we're trying to break the mold further down the line as well. For example, scaling. For example, what I'm most excited about that we shipped recently is PlanetScale Boost, which allows you to cache specific queries.

It uses dereplication, another test primitive, to keep the cache up to date. You can have an instantaneous cache to reduce your response times dramatically. It's just amazing.

I think it's just funny. There are so many things that databases can do to make the consumer's life easier or the user's life easier and more performance that I don't think people have really tried to explore.

There's a vision that we have at the company that's been very exciting to be a part of as we keep on doing these innovations. Even at work, like Edge, right? Another cool thing I got to work on with a coworker or two coworkers of mine was a database driver for serverless environments.

What ended up happening was that one of our engineers, Matt Robenolt, built this gateway, API gateway, that accepts a JSON payload and speaks like that protocol, and then can talk to a MySQL database to make the query or turn it back, so that way people can just use anything that's Fetch compatible in JavaScript.

Chris: Mm-hmm.

Iheanyi: And use that to make the database queries from every single serverless environment. We even have a demo of it at f1.planetscale.com, and we show. We built a proof of concept or a demo for every single serverless database provider. It's just stuff like that, right?

There's no connection limits, right? This theoretically can handle... We see people handling thousands or tens of thousands of connections and it's great.

00:18:37

Chris: Let me see if I understand that. The challenge the serverless, serverless meaning like a Lambda or whatever, like a cloud function, right? That cloud function might connect to a database, but the point is if that's the thing that I use to connect to my database, maybe there's a thousand of them running at once.

Iheanyi: Correct.

Chris: A thousand connections to a database might be a problem.

Iheanyi: Yeah. Yeah, yeah, yeah.

Dave: [Indiscernible]

Chris: Just be like... Yeah, they don't like--

[Laughter]

Chris: You've solved that somehow. PlanetScale is just straight-up ready for that. Do what you will.

Iheanyi: Pretty much. It's nice having a Fetch compatible interface, so if you know SQL, you just have to make the query calls normal, and it can speak a protocol that these Lambda environments or serverless environments understand.

Chris: Wow. That's so cool.

Mike: The load balancing of connections is huge. I had this one terrible morning at production where we were using Heroku PostgreSQL. I think if you check, their sort of standard plans, the limit is 500 connections. We had Lincoln Park (not LinkedIn) the band on our website that day. We were scaling up the servers, and then we just hit the max and went down. It was just--

Iheanyi: All bad.

Mike: --incredibly embarrassing. Yes.

Dave: Yeah, that hot new startup Lincoln Park. [Laughter]

[Laughter]

Chris: Tell me what this F1 page does. Why is this a demonstration? We'll put the link in the show notes here. It's literally F1 like the racing championship, right? It must be pulling data from something. What makes this interesting?

00:20:20

Iheanyi: Luckily, we have somebody here that built it. Mike, take it away.

Mike: [Laughter] That front-end page, it's a simple Next.js app. Then if you see that dropdown on the top right, that swaps out which serverless function the data is coming from. You'll see Cloudflare, Vercel, et cetera.

When you swap that out, it's just making a JSON request to that serverless function. That function is then entirely (over HTTP) hitting your database and getting data back. The reason HTTP is important here is because these serverless environments don't support TCP, which is required for making sort of your standard, long-lived database connection.

Chris: Hmm.

Iheanyi: Yeah. That's what I meant whenever I meant like protocol, like a compatible protocol. My bad.

Chris: Oh, that's great.

Dave: Yeah, that's cool. You can literally, on any provider, start hitting your PlanetScale DB.

Mike: Yes, sir.

Chris: But make it kind of user-facing in a way that you don't have to worry about it, in a way.

I was doing this dumb little side project, which I feel like... I have questions about that, too. I feel like there's a lot of enterprise stuff and it's solving really big problems at PlanetScale. Is that who you want as a client, or do you want me to start my little side project there, too, because then I'm learning your technology and can scale it and stuff? Or is it not for your side projects? [Laughter]

Iheanyi: No, it's for your side projects.

Chris: It is? Okay.

Iheanyi: PlanetScale is for the people, yeah, and people meaning everybody. Think about it. I think a lot of these problems--

It's funny because I think I was having this conversation with a friend of mine the other day. It's like a lot of these things, these best practices that I've had working as an engineer for however long now, a lot of the same things translate to my side projects, too.

Making branches for features, merging it in, and even doing the database migrations, like using deploy request from PlanetScale in order to make my schema changes. It's pretty nice and it's a nice workflow to make sure that you don't take down your database trying to apply a database migration on the app server booting. Right?

Chris: Mm-hmm.

Iheanyi: I think anybody can use it. You get a lot of these nice features for free with PlanetScale as well.

Insights, for example. I want to be able to see how my database is performing. I want to be able to see which queries are running slow and not have to shell into a production console to run explain queries on my own to debug things. Eventually, if it hits a good scale, I want to be able to use PlanetScale Boost.

I think PlanetScale is important for developers to try out. Developers are the ones that really can help make these technology decisions for companies. Once you get that hit of using something and falling in love with it, I've seen it at DigitalOcean. I've seen it at GitHub. It's important for people.

People love bringing, evangelizing technology that they love using. GitHub Actions, a lot of people moved over from it from other CI providers just because of its simplicity, and developers take the effort to show the value of the product to their leadership.

I think PlanetScale is a great database to use. Also, it scales with your project. Right? You may be little now, but the free tier is pretty generous. But whenever you do need to hit a higher... maybe hit the Scaler plan while at that point your side project is probably doing well and making money, so what's an extra $29 a month for a database, right?

Chris: Yeah. Do you literally do nothing to scale it? That's kind of great. It's just there. You pay more money. [Laughter]

00:24:04

Mike: It's definitely more complicated than doing nothing.

Iheanyi: Yeah. Yeah, yeah, yeah.

Chris: [Laughter]

Mike: I think the thing to know is when most people think of their database, it's kind of that single box, like I have a single box deployed somewhere. Maybe I added a replica. Right. It sounds like you all add a replica, so you have two databases.

Chris: Mm-hmm.

Dave: Yeah. It's three pancakes sitting on top of each other. Yep.

Iheanyi: Yeah.

Mike: Yeah.

Iheanyi: Yeah, yeah, yeah.

Dave: Yeah.

Mike: Everyone just thinks of that icon. A test cluster isn't like that. The way to think of a test cluster is the simplest database that we deploy for people, it looks more like a load balancer and then a database behind it, as well as replicas. And those replicas are spread across availability zones in a data center.

Generally, you'll be deployed to a single availability zone. If you lose one, you're in trouble. You're down. When you spread them across three, so in the same data center, if one fails, the test can auto-fail over to another availability zone, and you're still up and operating.

It's all those tools around resiliency that little startups like YouTube like to have--

Chris: [Laughter] Yeah.

Iheanyi: --available, just available in the most basic thing. Then as you grow up, you can start sort of adding things, like, "Hey, here's another load balancer, more replicas."

Chris: You're saying that's the free database does that?

Iheanyi: Yeah.

Chris: The free? That's crazy.

Iheanyi: That's the basic. Yep.

Chris: That's wild.

Dave: When U.S. West One goes down, U.S. West One goes down, as it does every summer during fire season, [laughter] it'll just switch me to U.S. East Two, or whatever, right?

Mike: [Indiscernible]

Iheanyi: [indiscernible]

Mike: Well, so one thing to clarify is an availability zone is actually inside the same region.

Dave: Oh, okay. Okay.

Mike: U.S. West Two has multiple availability zones. We'll keep you in the same region. But we do have replicas in other regions if you wanted to have a replica in U.S. East, for example.

Iheanyi: Yeah. Talk about read-only regions, Mike.

Mike: [Laughter] All right.

Iheanyi: [Laughter]

Mike: Yeah, so with PlanetScale, you can set up a read-only region in another region, so you have a replica across the country.

Dave: Whoa! Okay. They get their reads real fast. So, if they're just consuming, they're getting it - or even internationally, I assume. I don't know. Maybe that's stretching, but--

Iheanyi: Yeah. It's pretty cool. I think the folks over at Fly have a demo of using PlanetScale read-only regions with their platform. But it's nice.

In the future, getting that routing a little bit more automagically will be ideal, but there's a lot going on. Networking stuff is hard. So far, the person focusing on the innovation of the networking stuff has been one person, but I think he's going to get some help this year and some exciting stuff is coming up at the networking layer, so I'm excited for that.

Dave: That's cool.

Iheanyi: Back to you, Mike.

[Laughter]

Dave: The field correspondent. [Laughter]

Chris: I'm glad the region stuff is in there because the name does imply to me that there's multi-region stuff available of, if not, you automatically get it - or something. Obviously, it implies scale, but it seems like the edge stuff is a big deal these days, right?

If I'm going to run a cloud function, it sure is neat if I'm in Melbourne and it hits a data center in Melbourne. Isn't that cool? And that I know that there's an extremely difficult upscaling of that problem is, "Oh, I also want my database to be close, too."

00:27:40

Iheanyi: Yeah. Well, here's the interesting stuff about the edge driver that I was talking about, the JavaScript driver that we have, is that the benefit of using that like an HTTP protocol is that whenever you... We have this API gateway deployed to every single region that we serve databases in, right? The first call to that database may be the real-time. It may be slower. But subsequent calls are cached, so it reads the hot path of the connection. Therefore, you're getting faster speeds in the edge environment to the subsequent, in the subsequent calls. That way it keeps every single region or every single API gateway in every region keeps a warm cache of connections to every single region or database cluster that we have available over the world.

The first one will be slow. But after that, everything is faster. So, you see a really huge speed improvement after the fact as well. That's not even including things like PlanetScale Boost, right?

That's the benefit of HTTP. You can get speed improvements that way. Speed of light is always a problem, but hey.

Chris: Right.

Iheanyi: We can mitigate that.

Chris: [Laughter] It might be something like reducing 500 milliseconds to 50 - or something - in a distant region or whatever.

Mike: Ooh... You never want a 500-millisecond database query. [Laughter]

Iheanyi: Yeah. If you're doing that, something really is going wrong. [Laughter]

Chris: But I mean the entirety of the cloud function might actually be....

Iheanyi: Yeah, yeah, yeah.

Mike: Yeah.

Dave: I could make it happen, guys. I'm pretty good at... [Laughter]

Mike: [Laughter]

Iheanyi: That's why I'd be like, "You want to check your insights tab to see what's going on there."

Chris: Yeah. [Laughter] You slip that in, but that's a special feature of PlanetScale that you get these dashboards that tell you stuff like that is going on, right?

00:29:26

Iheanyi: Yep. Then you can also use it. Normally, a way of debugging things is using explain query, and it tells you what's going on, what indexes are (or not) being used, what fields could be indexable, right? I think the problem with a lot of these things that people may not know is that it's not necessarily taught that much anymore. I didn't learn about it until my second job.

I took a whole database class in undergrad and they didn't teach me about explain queries. But then on the jobs, Mike was like, "Oh, check out this explain command." I'm just like, "Oh, this is sick." You know?

Chris: [Laughter] I have no idea what you're talking about.

[Laughter]

Iheanyi: But having it in the product and having the product do that for you, your database do that for you, and also translating it to a UI that's easier to digest than this whole big table inside of your terminal, is a nice experience. I'm not going to lie.

It's helpful for the average user to do or to use, rather. It makes things very simple and clean for them to understand, and that's what I really love.

I don't know. My last three jobs ... I just loved being at a company where we build products that make developers' lives easier, from PlanetScale to GitHub to DigitalOcean. I feel like database is kind of like the final frontier of things that haven't really been innovated on, and it's just exciting to me.

I guess one of the days I'm waiting on is email, but I feel like we're kind of in....

[Laughter]

Dave: Good luck. Good luck.

Chris: Woo!

Iheanyi: The Web has been pushed forward except for email, but it's okay.

Dave: Yeah.

Iheanyi: Yeah.

Chris: What was that weird Google thing? Remember that when they tried to reinvent email?

Mike: Wave, Google Wave.

Dave: Wave.

Mike: That was Wave, I think. Yeah.

Iheanyi: Ah, yeah, yeah, yeah.

Chris: Oh, so strange. Okay. Here's a dumb one that I don't know the answer to. Is it PostgreSQL?

Iheanyi: No.

Chris: It's MySQL?

Iheanyi: Yep.

Mike: MySQL.

Chris: Okay. Interesting. Is there any more to say there? Is that just a simple answer?

Dave: Is PostgreSQL a limitation, or is MySQL... that's part of the test package?

Iheanyi: There are differences about how... Yeah, it's part of the text package, one, and I think there are... Between PostgreSQL and MySQL, they do have operational differences, like ways of managing it.

It's just funny because that's kind of like it being MySQL was another reason why I joined because I've actually never used PostgreSQL on the job. I've always used MySQL at my last three jobs. So, I'm like, "Okay. This is kind of like... I see a trend here of databases at these really big companies." Not knocking PostgreSQL. It's a great database, but yeah, I do like I had some familiarity with the underlying technology that it was helping solve these problems with.

Chris: It's not that different. It's fine.

[Laughter]

Mike: Yeah. It's really not that different. If you're an application developer, sometimes when you're building your app, there are things in one or the other that you sort of gravitate to and you like more. But in the end, it's kind of the same.

Like Iheanyi said, the main reason we use MySQL is because of the operational problems that have been solved in MySQL. We've talked a lot about replication and failover and backups. All of that stuff that was important to YouTube, that's what really Vitess is solving for us and with MySQL makes it easier.

Dave: Yeah. Well, the thing about database stuff, which is what's got me kind of excited about this, I'm PostgreSQL, so maybe I'm not able to just hot swap right now, but you don't move your data. [Laughter] Then with data, you find out very late that you have problems, like, "Oh, there are too many people hitting this," or "Oh, there's--" You don't find that out until later, if you've never done it before.

It seems like having something like PlanetScale in place would be huge because I'm looking at your screenshots. It's got insights, but it's also got just... I guess you were doing sharding and stuff like that, which is a hard problem to manage by yourself - or whatever. It just seems that ounce of preplanning might save you massive heartaches in five, ten years, or something like that.

00:33:49

Mike: Yeah. It's really... When you start with a small database on Vitess, it's like, "Okay, there's no upper limit unless you're going to grow bigger than GitHub." Probably not.

Dave: Yeah.

[Laughter]

Dave: No. Very generous plans right now, so it's very compelling.

Chris: They are! Five gigabytes of storage, one billion row read/writes, ten million row writes, one production branch, one development branch, and support - for free. Woo!

Dave: I want to ask about branches. What's branches? Is it what I'm thinking of, like literal--?

Chris: Staging? Is it environments?

Mike: Yeah. It's get branches, so we allow you to branch your database. Say you have your main production branch. You can say, "Hey, I want a new branch of this." It branches off. Then you have an entirely new database with the same schema.

Then guess what. You can just go mess around in there and it's safe. You can change schema. You can connect to it, test it out. And then very similar to your GitHub flow that you're used to, you can then open what we call a deploy request from that branch back into production. In that process, we will dif the two schemas (very similar to get). You'll see what has changed, and then you can use our tooling around safe schema migrations to make those changes in production.

Iheanyi: If something goes wrong -- let's say something happens like you're just seeing errors -- there's a way that you can actually revert back to the previous schema that you had instantaneously. It also keeps track of the changes that happened, like the new rows that were written and, when possible, it will actually revert back to that previous schema with zero data loss because it'll also have track of that new data that was inserted into the database as well - in case something goes wrong, similar to undoing a pull request, or reverting a pull request, rather.

00:35:53

Mike: Yeah. This is a juicy one. I feel like we should talk about schema changes because I don't think people know.

Iheanyi: Bro, I have never. I was watching. I remember whenever me and Mike were building this. I did a lot of the UI stuff for it. I did the branching part. Mike did a lot of the pairing with our coworker Peki.

I'm like, "All y'all writing a three-way merge in Ruby?" [Laughter] This is nuts. Mike, talk more about that, why don't you?

Chris: Can we set the stage? I like to use... Dave's bookshelf is my favorite data thing to use. He reads a book, and he wants to publish it to his website with a review, so it needs a name. it needs a title. It needs an ISBN number. It needs a rating, maybe a URL to an image or something.

But then Dave is like, "You know what? Maybe I spelled ISBN wrong." I don't even know if that's a real thing. Or I'm adding a new column - or something. That's what you mean, right?

Iheanyi: Let's say he's adding a new column, yeah, like a volume column. Right? Usually people are like, "Okay, well, let me just go ahead and make this database migration. If it's a side project, like davesbookshelf.com - or whatever - maybe he'll make a migration file, you know, to go old bundle exec Rails G migration, tag new volume column.

Chris: Right.

Dave: Yep. I'm responsible. I do that. Yeah.

Iheanyi: Yeah. Yeah, yeah.

Chris: Rails does a good job. Rails helps with this quite a bit, right?

Iheanyi: What's great is that you couldn't connect to a production box and add that new column or whatever, right? But if you were trying to do that to a production branch in PlanetScale, it would actually fail. It would say, "Direct DDL is not allowed," because you don't want to be able to run these things on a production branch, like create a new table, dropping a table.

I've been at a job. Everybody drops a database eventually. [Laughter] We want to prevent that.

Dave: [Laughter]

Iheanyi: But instead, what you can do in PlanetScale is say, you know, if you're using the CLI, you can do P-scale branch create - I don't know - Dave's DB. Name it add volume to database, right?

You can connect to that new branch in your database and apply the migration there. Then you can do some testing on it to make sure that works as expected. Maybe fiddle around with the UI a little bit with it. When you're ready, cut open a deploy request.

If Chris is on the project in the database as well, he can give his approval. Then you just click the deploy button, and you'll see that database, that new column get added into your production database.

The beauty of this if you combine deploy request with your get flow of pull request and all that, it allows you to be able to, okay, let me make the schema change first and add this new column. Right? You'll add these new column volume, and you could have a pull request open at the same time.

A lot of mistakes that I think I've seen people do is when they do the migration in production, like whether it's on add boot, they try to merge the migration and the code at the same time.

Chris: Right.

Iheanyi: Then that produces a race condition, right?

Chris: Yep.

Iheanyi: But this gives you deterministic steps that are very distinct. You can add the new column. Then once you're done with that, you can go back to your GitHub branch. Once the deploy is done, then you can merge in the new code that uses that new column.

Chris: We always do this thing where you do all the work in a branch. Then you cherry-pick the migration and deploy the cherry-pick.

Iheanyi: See! [Laughter]

Chris: Then you do the rest of it. You know? That's cool.

Mike: Yeah. I think that is a good way to do it.

Iheanyi: Yeah.

00:39:17

Mike: That's how most people do it. At GitHub, we sort of had a similar flow. I think the one major difference is, when you're making a schema change to a database, you're submitting DDL to the database. That's data definition language.

Iheanyi: Yeah.

Mike: That's your create, alters, that kind of stuff. When you get to a certain amount of data, a lot of those DDL--

Iheanyi: ...yeah.

Mike: A lot of that DDL can cause a lock on the table.

Chris: Hmm.

Mike: I remember back when I was first learning databases, I had to learn this long list of, okay, well, it's safe to do this but it's not safe to do this because this could take down prod, and I can't write to the table. There's all of this complexity.

There's a lot of risk when using direct DDL against your table. As you get more data, you can get into these situations where say I'm just changing the data type for a string. I want to make it longer. If you have a billion rows, it could take three hours to run.

Chris: Hmm.

Mike: You now have that table is locked in prod for three hours.

Chris: Almost nobody can do that. You don't even want do that on your side project. Three hours!

Iheanyi: Yeah.

Dave: No.

Chris: Yeah.

Mike: Yeah, so the way companies solve this is with an online schema migration tool. The way these work is, instead of running DDL directly on your schema and on your production database, it will, first, make an exact copy of that table that you want to change.

Iheanyi: Yep, table.

Mike: It then copies all of the data from your production table into this other table. We call this the ghost table. Some people say shadow table.

You have these two tables next to each other. They become fully synced. Then the tool will actually run that DDL against the ghost table.

Once the change is done, we quickly swap them in production. Now you have all of your data with the schema change, no three-hour lock. Your site is still up. That's the online schema migration tool that all these big companies use, and that's what we built into deploy requests.

Iheanyi: Yep.

Mike: That's what you're getting when you're doing that.

Dave: Wow. Not that you want to sit around and talk about all your competitors and stuff, but that's what Amazon does, too, with their thing. Right? It's the same exact.

I don't know how we do it, but we do column migrations all the time with zero downtime, which is - whatever. But that's great. I mean you need to have a story for that. You cannot pick a database tool and not have any plan for how you're going to do migrations.

Dave: Well, again, you don't know that on your $5 Bluehost.

Chris: Yeah. You don't know that.

Dave: It's doing good, but you don't know, down the line, I can't just do that. Yeah.

Chris: Mm-hmm. Safely, too. Sorry, it opened up the door. I feel like Netlify and Vercel changed the front-end world, in a way, and it's all integrated into GitHub Actions how you do a commit to your code. At the end, it runs some fancy action. It runs the build on Netlify, and you get a URL to a fricken' copy of the changes to your site. It's like, "What?!"

Iheanyi: Yeah.

Chris: We never used to have that. That's amazing that we can do that now. But the limitation is, yeah, but you're still connecting to the same database, probably. I love the idea that a commit to PlanetScale might have that opportunity to have this forked copy of your database.

Iheanyi: Database.

Chris: Yeah. That's crazy.

Iheanyi: Or for your Vercel branch or Netlify preview branch, yeah.

Chris: Theoretically, your Rails app could have that same vibe as a Netlify deploy request. Literally, a deploy preview with an altered database. That's amazing.

Dave: Literally, yesterday, somebody was like, "Oh, do I get my own database? Can I have a pre-migrated database - or whatever - for a deploy preview?"

Chris: You're like, "No." [Laughter]

Dave: No, not yet.

[Laughter]

Dave: For $5 million, you could have that.

Chris: Yeah.

[Laughter]

Dave: But deploy preview is even like... Because I worked on a Rails app, Daytrip, a long time ago, and I think the honest-to-God data died. [Laughter] It's still alive, technically, I guess. But the day it died was the day I was working on a few feature in a branch. I'm migrating, adding tables, boom-boom-boom. Like, oh, it's getting epic.

Then somebody was like, "Hey, can you fix this bug in production?" I was like, "No..." [laughter] because I had to - whatever - commit that, like rollback my database, do a DB rollback, and then switch to my main branch, make sure the DB was fine, and then I had to fix it and push it back. Then I had to come back, like roll forward or rerun the migration in that branch.

I just was like, "This is too much and I'm not doing it again." [Laughter] That was the death of that. It seems like this whole branch thing is pretty radical for, like, I'm just going to cut a future branch, and I can just be on that. Right?

Iheanyi: Yep.

Dave: Man.

00:44:43

Iheanyi: Yes, sir. Yes, sir. Databases are fun, kind of like whatever I refer to as a database.

My friends were making fun of me, like, "Oh, look at this guy. He's going to go build a database. Ha! What does he think this is, the 2000s?" But I'm just like, "Okay."

Dave: [Laughter]

Iheanyi: Y'all laugh at me now, but just wait. We're going to blow your mind.

Databases can be fun. I think anything that may be boring, like, oh, being a database administrator or whatever - yadda-yadda-yadda. I think the problem is just that there's not enough attention to detail and the user experience. Right? We've all been on the various cloud providers, a database like creation pages, and it's so confusing just to get started.

That's kind of a huge differentiator for Heroku and Heroku PostgreSQL is just simple and clean to get up and running with the database, right? There's no reason why we can't have that for other databases in 2023. We've come a long way in terms of programming, technology, and innovation. I think that we have so many good primitives. Build a better database experience for everybody.

Chris: Yeah. You seem pretty focused on the DX and design and all that in a way that is a differentiator, right?

I would say a lot of people that run databases, they run them on Amazon - I would think. You probably have potential customers there to steal. Amazon notoriously sucks at DX and all that. So, anyway - I don't know.

Iheanyi: We have an import tool that people use for importing over from, like, Amazon, DigitalOcean, any MySQL database, over to PlanetScale. That's also using the test primitives for zero downtime, like switching over.

Chris: Woo!

Iheanyi: It's just wild how good the primitives are within Vitess. I don't even know everything that it can do. I read the website, but I'm just like, "You know what? I'm the product guy. I'll just hook up into it. I'll just read up more into it whenever I need to." But for now, it's just like, there are so many things within it that we haven't even gotten to build on top of that I think we're just scratching the surface. There's a lot more room for improvement, so I'm excited about it. The future is bright.

Chris: Yeah, it really is. It seems like a big deal. I wonder if we could talk a little bit about what other... how it compares to other stuff. Is that cool to talk about?

Iheanyi: Yeah, sure.

00:46:58

Chris: I recently needed a quick database in the sky, and I chose Supabase because I'd never tried it before. They're PostgreSQL-based, and so I did that.

I don't think they have the same kind of scale situation and the same stuff under the hood, but they do other stuff, though. For example, they have a client that's like I wrote zero SQL to use it.

Iheanyi: Mm-hmm.

Chris: Because they had a UI where I said, "I want this column to be an integer and this column to be a date." You know? Which was kind of neat. Then they gave me a JavaScript client - or whatever. I didn't even have to write SQL there because they provided some ORM kind of tool.

Do you have interest in providing those tools, too, or you just think of yourself in a different space?

Iheanyi: I think we see ourselves in a different space because Supabase is great, and I think Supabase also just isn't a database. They're also trying to do their own things with Lambdas and also are trying to do their own things with object storage.

Chris: Auth.

Iheanyi: Yeah, authentication like object storage. They've got a lot of things, I think, that are very good for people who want to use PostgreSQL and also get these other features. Kind of like ala Firebase, like way back then.

I think the beauty of it, though, with PlanetScale is that we don't necessarily need to have a dedicated client. We have other client... Prisma works with PlanetScale databases, for example. It is compatible with other tools. We use it with Active Record already in production because we run PlanetScale on PlanetScale. Right?

Chris: Hmm.

Iheanyi: There's a whole bunch of slew of open-source solutions that will work with PlanetScale out of the box.

Chris: If you're not opinionated, you almost widen the people that can use you.

Iheanyi: Yeah. Yeah, yeah.

Chris: BYO tools. Yeah.

Iheanyi: Yeah, BYOSS.

Chris: [Laughter]

Iheanyi: Or BYOOSS.

[Laughter]

Dave: Byooss... [Laughter]

Iheanyi: Byooss... yeah. [Laughter]

00:49:01

Chris: What do we get? How is the pitch coming so far? We got a generous free tier, easy to get started. It's got a cool CLI. It's got this branching thing, which I've never heard of anybody doing. That seems unique.

Iheanyi: We've got cool ads.

[Laughter]

Dave: I think you've got a bomber jacket, right?

Mike: Yeah, we do.

Iheanyi: Bomber jacket.

Dave: That's part of it. It all factors in. [Laughter] Yeah, you kind of said it already, but is this something I should grab now? Should I kind of be in this situation of, like, I think this is going to go big? Or is it just like, "Nah, just pick it up today and go"?

Mike: Yeah, I mean I don't see any reason not to start. Then, hey, when Dave's bookstore blows up and takes over Amazon--

Dave: Jeff's. Going to take over Jeff's store.

Mike: Peace out, Jeff.

Dave: Yeah.

Iheanyi: Yeah.

Mike: We can shard your tables and you'll be all set.

Iheanyi: Yeah.

Dave: You had me at shard your tables.

[Laughter]

Dave: I already know I don't want to do that. Yeah. Databases are so tricky because it's like, "Don't go down." That's the one thing, you know.

Iheanyi: Yep.

Dave: It seems like y'all solved that pretty well.

Chris: Maybe we should look at one tooling because I think this show's history is more front-end-y than back-end-y. Let's say--

Iheanyi: I'm going to say front-end-y. The database driver, that's written in JavaScript.

Dave: Yeah.

Chris: Yeah.

Iheanyi: There you go.

Chris: Nice. Nice.

Iheanyi: Yeah.

Chris: Well, I just see in your guide, you have stuff for front-end people, too. There's a Next.js guide right in the documentation. Let's say I was going to pick that, and I knew I need data, so I'm going to pick PlanetScale. What's the five-minute? How do I do this? What else do I need?

00:50:56

Iheanyi: Well, it depends, right? If you want to use Next.js and you're going to deploy to Vercel or Netlify or something else, you'd want to go to github.com/planetscale/databasejs and read the instructions for getting started with the--

Chris: Ooh, you have a starter repo? Nice.

Iheanyi: It's actually the database driver, but there's also a link to an example project as well. The F1 example project is a good starting point for using the database driver. It's pretty easy to get forward with. That way you can get started with writing your queries and using your database and getting started with the database. Or if you're not worried about the serverless aspect of it, you can just go ahead and start using Prisma and following Prisma's guide for PlanetScale and developing using that.

Chris: Mm-hmm. Yeah, Dave, are you on Prisma?

Dave: I use Prisma. It's fricken' awesome. [Laughter]

[Laughter]

Iheanyi: Yeah.

Dave: It's GraphQL-y, but more JavaScript forward. You just say, "Hey, go to this column with this data, and then give me this." It's awesome. Even now, I'm doing calculus in my brain. What am I using this truly PostgreSQL-y feature? It's probably JSON columns or whatever.

Chris: Yeah.

Mike: MySQL has those too.

Iheanyi: Yeah.

Dave: Uh-oh. Rip... maybe.

Mike: Oh...

[Laughter]

Dave: Oh, baby, we got sucked in here. Only purely on the, like, I don't want it to go down. That's the thing.

Iheanyi: Yeah.

Dave: Yeah. No, I think it's all just interesting. Because I'm using an ORM -- again, whyormsrule.com -- is I can switch. The ORM is really just like, "Dude, I don't know. Wherever you're pointing me, I'll just go. Tell me where to do."

Iheanyi: Yeah.

Dave: That's cool, but it plays nicely with Prisma because Prisma does weird migrations. It does shadow database sort of stuff. It's all copasetic, I guess, to PlanetScale.

Chris: It must play nice with all this.

Mike: Yeah.

Chris: If you're recommending Prisma, it must, huh?

Mike: We have a shared Slack channel with their team.

Chris: Oh, nice.

Mike: So, we're tight. Yes, we work together with them a lot to make it work well.

Dave: Yeah, it's such a... To me, it feels like GraphQL without buying into all of GraphQL. You know?

Chris: Hmm.

Mike: Yeah.

Dave: That's how I'd probably describe it.

Chris: Right because if I'm Dave's bookstore and I'm going to use PlanetScale and I'm going to use Next.js, at some point I've got to write... Something has got to query for the books. I've either got to write select star from books - or whatever - or I've got to use something else to handle that query. Your something else is Prisma, probably, Dave.

Dave: Oh, yeah.

Mike: Yeah.

Dave: I'll give it five stars.

Chris: [Laughter]

Dave: If you've heard of the boring.technology -- is that the website - or whatever -- but it's like--

Iheanyi: Yeah.

Dave: --innovation tokens, you know. I spent one of my Elon Musk innovation tokens on Prisma and I have zero regrets about it.

Mike: [Laughter] Nice when that happens.

Iheanyi: Yeah, most def.

Dave: Yeah. Well, cool. All right, well, thank you all so much for coming on the show. This has been educational.

Chris: Indeed.

Dave: And possibly expensive for me, so thank you.

[Laughter]

Dave: But before we go, how can people follow you and give you money? We'll start with Mike.

Mike: Mike Coutermarsh on Twitter. I am @mscccc. Come visit us at planetscale.com.

Dave: Awesome.

Iheanyi: Yeah. For me, I'm @kwuchu on Twitter. Yeah, check us out at planetscale.com. Always open to feedback and ideas. Yeah. Thanks for watching.

Dave: Are you still doing your side hustle job board thing, Seeker?

Iheanyi: You know I'm trying to rewrite it, but I hit 30 last year. I am just tired of computers after I finish working, so I'm trying to find new hobbies. But I am. I am relaunching that. yeah.

Dave: Well, it's pretty cool. It's like a job board on demand, so check it out.

Thank you, dear listener, for downloading this in your podcatcher of choice. Be sure to star, heart, favorite it up. That's how people find out about the show.

Follow us on Twitter -- if it still exists -- @shoptalkshow.

[Laughter]

Dave: Then join us over on the D-d-d-d-discord, patreon.com/shoptalkshow.

Chris, do you got anything else you'd like to say?

Chris: I heard it's the DB form. That's going to be the first thing to go over there.

ShopTalkShow.com