The Swyx Mixtape

Listen to the Sourcegraph podcast: https://about.sourcegraph.com/podcast/sugu-sougoumarane/

Yeah, tell us that story. What happened between you and Elon Musk?

So, this was 2000. Elon had just founded X.com. He had sold off Zip2, which was his previous company, and he was considered one of those up and coming entrepreneurs. He wasn’t as popular as he is today. But when I read X.com, if you read the description then, it said that it was an online bank. So, basically, there’s Wells Fargo, there’s Bank of America, and now there’s X.com, which is an internet-first bank.

That’s what it looked like. I said, “Wow. If it’s a bank, I better be formal.” So, I wore a tie and suit.

Oh no. And I’m assuming the dress code was a lot less formal.

That turned him off instantly. So, I’m sitting there, he walks in and says, “Who the hell are you?” “I’m here for the interview.” “Oi, why are you wearing a suit?”

That’s hilarious.

So it turned out that this was 2000, where the boom was happening–‘99, 2000. And there were so many “me too” companies. “I’m going to change the world” kind of companies.

Sure. A lot of copycats.

And I had been interviewing with a bunch of them. And none of them had a real story. A lot of them didn’t even have code written, but they had raised money from VCs because that’s how desperate VCs were to give you money. Anybody that said “I have an idea” got money.

It was the height of the bubble.

Yeah, it was the height of the bubble. I was completely disillusioned saying that, “My God, this is a disaster. There is not a single company that has anything viable.” So I show up there and I’m kind of low energy because I don’t expect anything from this interview. All previous interviews were disasters and I had just walked out. And this one, I was like, “Oh, okay. Let’s hear it out. Let’s see what you got.” And so that came across to Elon as a guy who has no energy. And he was kind of disappointed. And I was wearing a suit. That’s even worse.

Two strikes.

Two strikes. And as I’m hearing his story, by the time the interview ended, I was so excited by what he was building. I just couldn’t believe it. I said, “Oh my God, this will change the world.” That’s basically how I ended up leaving. But that’s not how he ended up seeing me. I went through a recruiter. And the recruiter says, “Hey, they’re going to pass on you. They’re not interested. They think you have low energy.” I said, “What? Give me Elon’s email now. I’ll send him an email.”

So I sent him an email. Essentially, paraphrasing what I did, I basically sold him back his own company. I told him why this is going to be huge. And it turns out that, apparently, he was struggling to convince the greatness of his company to his own employees. And so he saw that and he was impressed that I was able to see what he saw. He even sent that email to everyone and told them, “See, there’s a guy outside who believes in what we are doing.” And so he called me back for an interview.

And now, looking back, I can see everybody was smiling. Everybody was passing me by, giving me second looks, and smiling.

You were the guy.

Yeah, I was that guy.

That’s awesome.

The rest is history. Then I joined X.com. And then soon after that, X.com and PayPal merged, and that’s how I ended up at PayPal.

Do you remember what it is you said in that email? Because I’m sure everyone who’s listening, who’s ever bombed an interview, is like, “What do you say? What do you say in an email that gets you that second chance with Elon Musk of all people?”

I think actually I relate to what I said even now, because what I said was, “The most important thing is that I am sold on this vision and I will do anything to be part of it. I don’t care what you offer me. This vision is awesome. This is going to change the world. So I want to be part of this. I don’t care. My low energy is situational. Don’t read into that.” I need to dig up that email. I don’t think I was as eloquent as I am now.

If you dig it up, we’ll link to it in the show notes.

Yeah, I’ll find out. I’ll see if I can find it. This is literally 21 years ago.

I was just trying to think of email systems back then.

Yeah, exactly.

But do you even remember what email you used in those days?

I think it was Yahoo.

Oh, Yahoo. Okay.

So it may still be there. I should go look for it.

Yeah, fascinating.

He may not remember me, but I think if I reminded him of the story, he would remember me if I ever met him again. If I told him this.

Yeah, it seems pretty memorable. I mean, a guy comes in and sells your company back to you so well–probably better than he could describe it. He shared it with the entire company. That’s awesome.







---

part 2
---

Beyang Liu:

Tell me about the key selling points of PlanetScale. So the front page says serverless database platform. What does that mean?

So here is what is changing in the industry. Vitess was in some respects, the first step towards what PlanetScale became. At YouTube, we literally ran tens of thousands of nodes. That’s how big the Vitess deployment was at YouTube.

Wow.

And there is no DBA team that can manage anything of that size.

It’s just too many nodes.

Just too many things, too many nodes. And those tens of thousands of nodes were running on Borg.

And Borg is the Google internal predecessor to Kubernetes.

It’s the predecessor to Kubernetes. It was in the Borg cloud. And the shutdown of a pod is something that is not human generated. Previous to that, even today, with MySQL deployments, there is a DBA watching over that machine. Right?

Super manual.

It’s super, super manual.

And when we deployed Vitess in Borg, we had to make it developer-friendly. Make it such that a DBA was not needed to be watching over those nodes, so we had to actually automate a large part of those things away, so that we could deploy things at scale. The DBAs’ role actually changed, such that they would not manage a single instance. They will be doing things for the cluster. I think that trend is now more prominent. They are called DBEs or DBREs–there’s lots of names.

They’re going from minding individual pets to being cattle herders.

To managing fleets. So that was what Vitess did at YouTube, which became extremely relevant at Kubernetes. But it still had an administrative mindset, where you still had to know a few things.

The way I would describe it and now what Vitess is evolving into is, I kind of see two types of developers in the community. There are the tinkerers and there are the builders. There are application builders. They are kind of non-overlapping. They want to do different types of things. The tinkerers like to install software, configure it, play with it.

Vitess is a tool that relates to that type of person. They like to learn.

Nitty-gritty, get your hands dirty.

Yeah. How do I configure this relationship in this data?

Diving into Unix internal… yeah.

Yeah. They’re actually this one level above Unix. It’s more like understanding data, modeling relationships with them.

Doing cool things with the data. Like when you shard… optimizing your sharding algorithm. That’s what Vitess relates to. And then there’s the other category, which is the application builder. The biggest turn off to an application builder is that they say, “I want something…” and you say, “How much CPU do you need?” You’ve lost them. “How much display?” ‘I don’t know.”

I don’t want to care. Just figure it out.

I don’t know how much I’m going to need. Whatever it takes. Just give me something to get started. Those should be taken away. If the developer comes and says, “I want a database.” You say, “Here’s a database.” So PlanetScale is for this person. The person that says, “I want a database and we shouldn’t ask any more questions.”

Yeah. It should just work.

You want a database, here’s your database. “How do I connect to it?” “Here’s your connection string. Go.”

And another big problem that PlanetScale solves is the problem that’s been plaguing the database industry, which is managing schema deployment. A large number of developers who like databases, who like SQL–many of them are using key value stores.

They like SQL, but they’re using KV stores for some reason.

Yeah. They decide to use KV stores, say, “Why did you do it?” “It’s because of schema. I just don’t want to deal with the headache of schemas.”

It’s almost a universal story. But then what the database industry has been saying, “Well, it’s necessary. Schema is necessary.” Yeah, it’s needed.

And you’re talking specifically about schema migrations or conversions, right?

That’s where the disconnect came, right? Nobody tried to go in and find out why schema is such a big headache.

I mean, it’s almost like a type system, right? It imposes certain constraints, but then this thing can change too.

Yes. And not only that, it’s not only a type system. It’s a disruptive system. The moment you deploy schema and you make a small mistake, you have an outage that goes into many hours.

Yeah. I’ve been there.

One small fat finger, and you have an enormous outage of epic proportions. So that’s very scary. You cannot just say, “Here’s a schema change. Boom done.” This danger exists, right? How do companies solve the problem? They install gatekeepers. People to review your change.

Only certain people can directly access the database and you have to go through them.

Only they can directly access data, and they will review your code. And I have a schema that is ready to be deployed, but this DBA is on vacation, now I have to wait three days for them to come back. Or, they are busy fixing, taking backups, so they are not available. Because a DBA’s job is not to wait. That’s not their priority to review your schema change. So the entire process becomes a huge headache. And so Sam, who is our chief product officer, he kind of developed that system within GitHub. He came, he said, “I know what the developers want, and this is what we’re doing…” So this whole thing was his idea.

And you can see how the developer community is responding to these features. “I’ve been waiting for this all my life,” is what the developers are saying, which is self-serve schema-safe schema deployments.

The full power of SQL, but with none of the hassle.

With none of the hassle. And also, the way we deploy the schema is underlying… I don’t know if you’ve heard of gh-ost, which is the MySQL schema deployer.

No.

Basically, it allows you to deploy schemas without downtime.

So if you have a billion rows in your table and you want to add a column, MySQL is going to lock that table, and you’re not going to be able to write to it. And gh-ost actually allows you to do the deployment without locking that table. It’s called gh-ost, which stands for GitHub Online Schema Tool. But it’s also gh-ost, because it creates a ghost table for you.

Oh, I see. That’s the trick. It just copies stuff over.

And basically it forms an atomic switch. And it turns out that Vitess has the same technology called V-replication as a core primitive that you can use.

That’s convenient.

And the author of gh-ost coincidentally happens to work for PlanetScale, and coincidentally decides to implement that same feature in Vitess. So the same offline schema deployment now is available through Vitess.

I feel like every organization or company that operates a database, they over time accumulate a bunch of scripts that automate certain tasks, whether it’s schema deploy, or pulling certain pieces of information. It sounds like you’re just productizing all of that and turning it into an out-of-the-box, non-hacky, non-duct-tape solution.

Exactly. I mean, the writing is on the wall. GitHub kind of showed this model for source code already as a viable model, right? Where they took away what each enterprise had internally and productized it as a generic uniform method of managing source code. And now enterprises are all moving towards that, right? Instead of having each one implementing their own way of managing source code. We’re kind of doing the same thing for databases.