August 10, 2023

Mastering The Art Of Scaling - Karthik Ranganathan | BCL #307

Karthik Ranganathan is a Co-Founder & the CTO at Yugabyte, the company behind the open-source YugabyteDB project that brings together NoSQL and SQL in a single globally distributed database. Karthik was one of the original database engineers at Facebook, responsible for building distributed databases such as Cassandra and HBase. He is an Apache HBase committer, and also an early contributor to Cassandra; he named it himself before it was open-sourced by Facebook.

Yugabyte is on its series C and to date has raised $291M in funding. Its last round was a big one -- $188M and they also hit Unicorn status with a valuation of over $1B.

Karthik:that's the most important thing that'll make or break the company. Yeah. Infact, not adopting it or embracing it is, is actually going to be in thelong-term detriment of any company, small or large.


Julian:  

Hey everyone. Thankyou so much for joining the Behind Company Lines podcast. Today we have KarthikRanganathan, CTO and founder of Yugabyte, the company behind the Open SourceYugabyte DB project, which is distributed Postgres with Resilience Scale andmore. Karthik, I'm so excited to chat with you, not only because of what you'vebeen working on at Yugabyte for.

I don't know howmany years now, but also your, your previous experience at Facebook, of coursebuilding the Cassandra project, which I'm not sure if a lot of people arefamiliar about it, but I think we, it actually touches more people. And, and,and really in, we've, we've been involved with it. If, if you've been aFacebook user, you've used it without even knowing, so that's super exciting touncover kind of what that process was as well.

Going through thatand, and really just, I, I guess learning how to build product at a really fastscaling company and, and what that experience was.  

But before we getinto all good act stuff describe your experience before Yugabyte and what gotyou to here.  

Karthik:Yeah, sure thing, Julian. And first off thanks for having me here.

Very excited. Somaybe let's just jump in. So before Yugabyte, I, we started Yuba, which wasactually a little over seven years ago, seven and a half years ago, nearly.Before that I was at Nutanix working on distributed storage. So Nutanix buildslike, block storage for the cloud, so it's for the private cloud.

So it's a storagedevice, but it's distributed systems, nevertheless. And before that, I was atFacebook for a number of years and, I had the good fortune of meeting myco-founders there. I worked with a lot of the people who, were fortunate enoughto join us here. So it's been, it is been an incredible journey.

And Facebook was astory of, crazy scale. Again, quick anecdote. This was around 2007 when I wastrying to decide if I should join this small, this, small but growing companyand which was Facebook. And I, I remember looking at their site and they hadabout 30 to 40 million users on the site.

And back then Iremember thinking, yeah, the, one of the biggest sites is Yahoo Messenger, andthey had like 50 or 60, so maybe the site can double, but I don't know. Theyseem to be bold. They're building interesting things. I love the product. I lovethe, their vision for infrastructure. So I joined and. Boy could I have beenany more wrong it.

We went to 2billion users over the next six years, so it was an incredible journey. Yeah.So, and speaking of this did spur the whole journey here, so Yeah.  

Julian:It, it's incredible to think about just when you kind of were joining thestart, I mean, you were at the conception of startups. I know the.com era getsa lot of hype and all, but really around that time post, recession is when allthese companies really started to find and, and, and achieve value and, andreally, Tackle what people were missing and describe kind of that whole processinternally.

Was there somethingdifferent about how it was communicated that kind of molded and shaped how youuncover problems, whether it's from users or technology or how you one, onething, you did a talk years ago and, and I was reviewing it and one thing yousaid that was so profound, it was like, we don't think about people wanting tocontact people.

We thought, wethink about what people wanna say to people. And I thought that was soimportant 'cause that that opens up the channels. You can do it. So describekind of mentality at that time.  

Karthik:Yeah, I think Facebook is a phenomenal place. It is move really fast. Be verybold. Try ideas, and it encourage people to fail fast.

And it's okay ifyou fail fast and learn the lesson. That's great. It's better than kind ofsitting on what would be, could be kind of success for a very long time. Youbetter go for the, the real thing. So number of such principles, like forexample the first, like we ended up building Apache Cassandra.

Actually, it wasn'tcalled that then, like we had an an internal code name. But you know, we endedup building this because people on the site could message each other, but theycouldn't search their messages. Right. And when we wanted to build something toallow that indexing and searching of messages, we found that it get way tooexpensive if we did it with MySQL.

And it's just like,you're not gonna be operationally easy. So we said, you know what? This thingdoesn't really, it has the scale characteristics and the availabilitycharacteristics, but yet has to be cheap. There's really nothing that can dowhat we want. So let's just build a database. Right? And you don't do thatlightly, right?

On theinfrastructure side. And, but you know, at Facebook we had the ability to dothat, right? And so we ended up building and open sourcing this thing. Opensourcing was more the hiring and do good for the world, et cetera. And weliterally didn't know open source databases would take off. So, in fact, Iremember like the, the three person team were working on it and we were askedto name it and the others wouldn't be bothered with naming a database or namingthe project.

And so I was like,okay, we're dealing with eventual consistency and any database has to be namedafter Oracle. So we ended up choosing the name Cassandra, because that's theonly other Oracle I knew other than Delphi and Delphi. Oracle of Delphi, right.Delphi was taken, Delphix had it. So we said fine.

Cassandra Ist, whoknew it would've become that popular, right? So anyways forward to. The nextproject we did, which was a database for messaging, and it was literally likedon't worry about how you reach a person, how they want to consume it. Oh, waita minute, that's. Like my, my uncle who really likes to get it in the form ofan email, oh, that's my younger cousin.

The absolutely s ms, this third person will be a, a power user of Facebook. Let them choose theirway, make it simple for them. Similarly, newsfeed was another way to quicklyinform people of what is going on in a lightweight way. And so in a lot ofthese, you could get lost in the complexity of building, but if you're doing itthe right way, you could unlock a lot of value.

Right. So it's beenan incredible journey of. Really going down to the basics and questioningeverything and figuring out is there a more efficient way, a smarter way to satisfythe need.  

Julian:And, and what other companies at the time when you would look externally weredoing some of the things which was building internally the tools that theyneeded to almost continue to like, I, I don't wanna say kind of moat this ecosystem,but it's like once, it's, once you're in the ecosystem of Facebook, it's hardto leave.

You think aboutmarketplace now, you think about all these different things they've added inaddition to it. What other companies did you see at the time that were buildingthese external tools rather than relying on existing technology?  

Karthik:Yeah. I think there were a number of companies in our, in the Facebook bucketitself.

Obviously Facebookbecame massively popular, but there was Twitter naturally, like they were, theywere doing good stuff. Then there was MySpace, there was friend feed. Therewere a number of these type of social companies, so to speak, each with their ownphilosophy. Yeah. They had a slightly different twist on what it is that they,they would want to build underneath.

But they were allfearless. I mean, they were all moving fast. They were all building their ownthings. It was pretty good. I would put to a large extent, even though theystarted much earlier, Google in the same bucket. Like, because if you thinkabout what Google search and maps have done to us, it's like, you can't evenimagine life without these things today.

Right. And, and yetin 2000 we didn't really have them. So, so like around about that time whenYeah. Yeah. So that, that's, that was pretty fundamental. I would say Apple hada nice answer on then because they really changed the way we operate, like withthe smartphone and. Blackberry and Apple, those, those class of companies.

So I'd say therewas a whole set of companies that kind of took off around that time. Publicclouds, I think all three of them, they started in, give or take around thenthey figured, if we learned how to use our infrastructure, why can't we helpothers, use that infrastructure to, to some good.

So, so yeah, Ithink there's a lot of these type of companies that did bold things, buildingstuff open, sourcing it along the way if it wasn't directly their competitivesecret sauce. So yeah. It was a good time. Yeah, I think it still is.  

Julian:Yeah, right. You're right.  

Nowadays it'sactually very challenging to see a lot of people stay at companies for so long,and a lot of that is not necessarily the I, I don't wanna say the lower or, orI guess the what's the word for it?

The reputation ofthe company no longer really means as much as it did, but I think even backthen in, in the antithesis of a lot of these projects, what was it that wasreally keeping you around? Was it the newness of it? Was it the innovation? Wasit the culture of it? What was working within those companies that you see,even now, other startups model themselves after?

Karthik:Yeah, I think that's a great question actually. And I think this is a, a veryprofound question. I think there's a few things. Firstly, my, like, my gauge,when I was going through this journey personally, I can talk to how I felt,right? I used to feel that the interviews had way harder questions than reallife.

So it kind of gaveme a feeling of, okay, if you just wanted me to do this, why'd you ask me allthat? Right? Like, and, and don't get me wrong, I actually liked what theyasked in the interview. It's just that you wouldn't find it afterwards. And soit's, and, and that's because. Of the, I would say to some degree, a lack ofboldness on the part of the company.

Mm-hmm. They wantit to be a little safe, played safe. Right. And don't go disrupt and do crazythings. The second one is kind of getting caught in in the decision makingloop, like, as opposed to making the hard call, whatever it is, and, stickingthrough it right or wrong, like, and that's the a second piece.

The third thing hasto do with transparency and, and empowering, but yet accountable culture. So,junior people, yeah, they need to earn their chops. Senior people, theyprobably, but you know, Facebook was the first company I saw that broke all ofthese barriers. So I remember in Facebook, like, their, their philosophy wassimple.

They, when I joinedthey, they told me, Hey, this is how you check out code. This is how you dothis. You do that. Fine basic orientation. Okay. I said, now what? I said, Idon't know, go figure it out. And 'cause my manager was too busy to tell me whatto do, he said like, why don't you go figure it out and do something and tellme what you're doing.

And oh, by the way,just send me a couple of lines about it every week. 'cause I gotta send areport and and yeah, I'm, I'm busy with my own stuff. So they never said whatto do. And that was great because then people would find, it's not one personthinking it's like, A hundred people, 200 people thinking about what to do.

And that reallyempowered, but yet they used to keep it accountable. Right? You can't keeptrying to do stuff and not do stuff, right? Yeah. So it's that, it's that yinand yang that you have to manage, and it was extremely transparent and open.Like you could come and ask, mark Zuckerberg z he would say, ask the harderquestions inside.

'cause I'd ratherhear it from you guys than from somebody else outside the company and during aninterview. So just make sure to ask us all the hard questions. Whatever youdon't trust, make it all clear right now. I will at least practice with youguys before I go out. Right. So, so yeah, I think it's that culture of notbeing afraid and being bold and empowering people and, keeping it transparent.

And so that's whatmotivated me like. In fact, my reason to leave Facebook was not because Istopped learning or I didn't like Facebook. It was none of that stuff. It wasbecause Facebook had grown so big and I had ambitions of eventually doing astartup, like a, starting a company of my own, that the problems I was solvingat Facebook while technically and intellectually very challenging, were nolonger the problems that the.

The common companyor the common person would face, right. So yeah. So at that point I just had togo look for other avenues to learn other things. But I still loved Facebook. I would'vestayed there. Equally as much as I can believe.

Julian:So, yeah.

Well, it's so fascinating thinking about theamount of, obviously responsibility you had joining, but also the amount ofjust freedom, that in terms of pursuing the different projects and how valuablethat is.

But it's, I feellike it's, it's hard to have that level of trust, with whoever you bring ontothe team and, and and does that kind of now, Has that impacted the way youevaluate talent? Seeing kind of, I don't wanna say younger selves, young,younger versions of yourself, but almost, similar personality types, whateveryou want to describe it as that lead to that level of, ability to workautonomously, to innovate, to challenge, to have initiative.

Has that, has that experienceimpacted how you kind of.  

Karthik:Yeah. 100% count now. Yeah, a hundred percent. Yeah. Yeah. In fact, that isactually one of the most critical things I tend to look for when hiring is thedrive, the curiosity, the need to have impact, the hunger. Right. And it's not,it's, and, and I would say it's fair game or more than fair game to offset ifthe person doesn't specifically know a particular field, right?

Like, for examplewe may not end up hiring a person that knows everything about databasesbecause. That's okay. They can learn as long as they have the risk of theingredients that would, make them successful. Right? And, and a large part ofit is about both. It, it's I mean, you gotta have the two sides and check andbalance, right?

You want to havethat drive hunger and take on something big and change, but yet do it in a waywhere you're, really accountable and responsible and you can make that impacthappen. So, it naturally forces you into talking to people to seeking advicerather than just doing something on your own and putting it out.

So it just changesthe way that you, behave and your ability to create impact and your confidencein yourself and in the next project will get bigger and then bigger. And so itjust gets, a lot more satisfying that point of view.  

Julian:Yeah. When.  

You, you wereleading up to Yugabyte and, and kind of thinking about the different ways thatyou could, solve not the common challenges, but I think maybe challenges that,that are commonly experienced, by a certain group of people or whatever.

How did you find that direction? What led youto the path that you are at now and, and what were some of the critical thingsthat kind of guided you there?  

Karthik:Yeah, yeah. In, in our, in, in, in the, Yugabyte Journey case, it's a, it's aquestion of having built depth already. So different people find motivations indifferent ways.

So this is just myjourney. So at Facebook, like I said, the first problem, the first big problemwe ended up solving was, how do people search messages without spending an armand a leg? Right? Like, because if you think about it, how often do you actuallysearch your messages versus. How many messages do you get?

Right? And how manywords in each of those messages. And you have to now enter every word of everymessage into a database. Just it's an enormous right, but rarely red problem,right? So we took that problem on and we solved it, and that was veryinteresting. The, the technology was innovative, we open sourced it.

It really took offvery satisfying to see this is Apache Casandra. So the next problem we saidwas, there's a lot of applications where you need consistency and the, and thetrade-offs we made when building Cassandra were not quite the trade-offs wewould need for this general purpose messaging system.

Right. And evenworse. Mm-hmm. We simply didn't know what to expect. Like people wereexchanging about 150 million messages per day. Right. And when we released thisnew thing where we're combining chat and S M s and email and everything, we didnot know what that number would become. We knew it would increase, but by howmuch?

Well, who knows?'cause it's new behavior of people. Right. And so we said we need to design thesystem. Yeah. That you can just add nodes and just expand and do whatever,blah, blah, all that stuff. And we, ended up picking up HPAC for a number ofreasons. We built it, we operationalized it, we put it in production.

And after the new,so the old messages product became Facebook Messenger, right? When Messengerwas fully rolled out, that one 50 million messages per day became 20 billionmessages per day. Right. And there was no way to predict it. Yeah, it was crazyand it just kept going up from there. So it's just like crazy, crazy growth,right?

How do you know?Yeah. If, if it would be 20 billion or it'd be 1 billion or it'd be a hundredbillion, well they don't know. It doesn't matter at that point, beyond acertain point, you just get ready, right? And so that was very formative for usin the way we were thinking because the Facebook, the product was evolving at arapid clip to encourage users to do stuff which simplifies their life, whichmakes it easier to communicate, to do whatever.

But Facebook, theinfrastructure had to deal with, well, I don't know if it'll be two x or 2000times. Is it two times the growth or 2000? Oh, who knows, right? You gotta beready for anything. And, and it could happen that it goes to 2000 times andthen, a year later drops down to two times, right? So this variability inbuilding is really a big challenge.

And put anotherway, I mean, you can think of what the applications teams do. As building a lotof features iteratively by listening to their users, by, understanding whatthey want. And it's kind of accidental success because you keep building,building, building, building and suddenly you hit a point when it just takesoff.

Right now, when ittakes off, if you're not ready for it, well that's gonna be a world of troublebecause I can tell you around 2007 and eight during those two years, yeah.Every week of e every week we would have the same discussion, which is, this isthe week the Facebook site falls over 'cause we simply don't have enoughhardware and there's too many people using it.

And, all theengineering heads like, Jeff Rothchild, the then VP of engineering, who'sactually an angel in our current company. He used to jokingly say, It's thepeople who write software. That's the problem. If we stop that, everything willbe okay. Don't give users the features.

Everything will befine. But you know, of course you couldn't do that. And somehow we made itthrough. We bought hardware, we threw it. We invested in efficiency, weinvested in operations. We did a lot of stuff to weather the storm. You mightknow Twitter's fail whale at the same time. We used to say, you know what?

We totallyunderstand their problem. We should probably get a mascot of our own in case itfails. But you know, it didn't come to it luckily, but it was just luck, right?We just somehow managed to by the skin of our teeth escape. Yeah, but that'skind of thing you have to be ready for. 'cause as a modern enterprise, youdon't know when that success will hit and when it hits, if you tell people,okay, okay, great, now we're really successful.

Wait, we'll comeback in three months or six months and we'll give you the same thing. Thatreally works well while you've lost all your success, that's just a waste. So,ah, the other thing about Facebook is you could just create a NoSQL databasewith any a p i, right? But enterprises, they have thousands of developers andthousands of applications trained to use relational databases like Postgres.

And, and other,other relational databases. So we needed to combine these two things, the needfrom the application side to innovate and grow quickly and shrink quickly andall of that stuff, and keep it familiar and simple. So that was the marriagethat, gave birth to. Yugabyte db, right? So. You post SQL DIS distributed postSQL with resilience and scale and more.

That's really whatit is about.  

Julian:What's so fascinating, thinking about the immense amount of variability betweenthe, the, the data you would have, right, or the amount of of data at a giventime, and what goes into. That we don't know. The complexity of buildingsomething that grows but also decreases the size and continuously is kind offlexible throughout this process and, and doesn't break, what, what was mamainly the, I guess the component of the breakthrough that you saw in, in, onyour end to actually make this possible.

Because if, forthose that don't know who do with big data, it. You don't necessarily deal withhugely decreasing amounts. Typically think about big data and pharmaceuticalsand things like that just ever expanding. Right? But this is, this is sodynamic.  

Karthik:Exactly. Yeah, exactly. So yeah, I think it wasn't it wasn't a one shot solvething.

It was done overgenerations. Right? As you would rightly pointed out big data on the originalNoSQL databases. It was all about one way scaling. 'cause if you could scale,well that was a big thing back then. You couldn't scale otherwise. Right? Soyou needed to move data around different machines and you needed to move yourquery processing around different machines as well, right?

So your applicationwould end up talking, start talking to one machine, and if you had a 10 nodecluster, 10 machine cluster, It'll end up seamlessly talking to all 10 machinesover time. With your data spreading over your query processing, spreading over.And you're using these 10 machines to do something right now.

Yeah. When you'reexpanding, you're not gonna expand all the time. You're not gonna push yourmachines to 90% and then bring it down to 70% utilization by adding one or twomore. You're probably just gonna double the cluster and say, you know what? I'mgonna go from 10 to 20. I'm like, 90%, let me bring it down to 50% and justmove on.

Right. So you areexpanding the operation of expanding a cluster. Can be complicated. It's okay.'cause it happens once in a while and you're not really going to removemachines. You can if you want to, but it's an equally complex thing. Right?That's really how you approach, how we approached it in the generation one withCassandra and other things, right?

But as things wenton, it became very clear that the general purpose use cases is not necessarilya hundred machines or 50 machines, or even 10 machines. It could be anythingthat doesn't fit on a single machine. So it could be like three machines,right? And wanting to go from three to six. Back to three actually represents ameaningful thing for an end user that needs just that.

Right? Yeah. So,and, and to make things I guess make this whole need even more critical. If youthink about what has happened with the infrastructure space that went from baremachines, like bare metal to VMs and virtual machines to containers. Where youcan do all this quicker and quicker and quicker.

Right? So you cancreate containers like that and take them away. Yeah, you can kind of createVMs like that and take them away and bear machines you don't even do that much.So as you see the progression on the infrastructure side and as you see theprogression on the application side, I. Where you're like, okay, now there's,like, for example, it's a Super Bowl.

Okay. Tons ofpeople are doing something right. Joining. If you're like, you're paramount.Plus, for example, you have tons of people signing up or doing something, or ifyou're like like Kroger, we work with them. Like if it's back to school day,they see a flurry of things come in, and so a lot of activity online, etcetera.

So, and or any, anyof the big retailers, right? During the peak season, you see a ton of activityand then it goes back down. This is actually quite a common pattern. It's anatural pattern. And as you're starting to automate your infrastructure withcontainers and VMs that are very, dynamic in nature and your applications alsowith features that are very dynamic in nature, then you kind of see that itpoints to the middle where the database is not dynamic and you're doingeverything possible to kind of prevent the database from slowing you down.

Right? And sothat's how, that's what gives birth to this need to not just expand, but comeback down quickly. And it's not just do it, it's do it in a way where An a p, Ican tell you I have started the process to expand. I'm gonna go through somephases and okay, now I've actually completed, whether it's the expansion or theshrinking.

So it's no longerpeople doing it with a process. It actually is completely automated and youneed the guarantee of the application won't be impacted. Your data consistencyis not impacted. Everything is business as normal, but we're changing stuff inthe underneath. Right. And yeah, one, one more aspect, which is actually oftenoverlooked in the six years that Yugabyte, or seven years that you, goby hasbeen in existence.

The cloud providershave changed their instance types, their machine types, about five times. Sowe're talking about roughly every year a new instance type comes out. Iremember we like, C three, C four, C five graviton, this, that, like, it keepschanging, right? And so it's not just expanding and shrinking, it's alsochanging your machine type.

It's an equal andoperation. I mean, nobody thinks about it, but you know.  

Julian:Yeah. And, and correct me if I'm wrong, describing the, the, the meaning behindor the reason why you would decrease or increase the, the machines kind ofreminds me of like, the, the, if you had an automatic car and if you're goinguphill and for, if you're going uphill, obviously you need more machine power,but only in one direction.

Versus if you'regoing on flat ground, you have a little bit more variability and, and if you'regoing up speed and increasing that, then you obviously are, are in a differentgear almost. And from what you're saying, it's almost like you kind of built,you kind of built the, the automatic version of of, of, the manual gearshifting process.

Karthik:Yeah, exactly. Yes, exactly. Yeah. Because there are times when you have acertain number of requests come to you as a, as a service provider like you,you build a service like, a login service or like a, a checkout service orwhatever the service are. Even a financial transaction service.

You see a certainamount of requests come to you. And if that is perfectly constant or if you canpredict ahead of time, just like in the Facebook case we talked about messages.If you know that it's always one 50 million messages a day at this rate, andyou know that okay, it might go to 300 million the next month.

Well that's great.You can do a lot of things to make sure you can handle that. Except whathappens if that one 50 million, you build a few features, goes to 500, and thenyou build a few more and goes to 20 billion, and then you need to say, okay,now I'm at 20 billion, and now it's uh uh, let's say there's some major eventhappening, like there's the elections or there's Super Bowl, or there'ssomething else going on.

Mm-hmm. And that 20billion becomes. 40 billion or 30 billion, right? Like, or even 25 billion. Andthen it comes back to 15 billion because there's, summer vacations andeveryone. So you want to play these shifts to say, I need 5,000 machines. Ineed 7,000 machines. I need now 3000 machines, whatever that number is.

And that actuallystarts to add up because it is forever. Otherwise, you'd be running at thebiggest capacity forever. And anytime any change happens, you'll be callingpeople to say, oh, why don't you take this out and take that out? And, and Iknow people like, and I'll tell you this true story. As we were talking to alot of people before starting the company and one of them story still, stickswith me.

These guys had todo a decommission of a old machine type and move to a new data center in thecloud, right? And so they did all this work to get all of the machines in oneof the databases, like five or six machines in one cluster. They replicated itto another cluster and did all that stuff and moved it all to the rightcluster.

This was over the.Christmas to New Year, time when it's downtime, period, et cetera, when youknow people are off and they can do all this stuff. So it was excruciatingamount of work to get there and they dropped the wrong cluster, so they droppedthe one they should have moved to. So they had to repeat the whole thing again.

And it's just likemy heart just went out so much time. Yeah. So much time, but also theemotional, mental energy to get this right. Yeah. Not one last step. Right?But, but machines are great at doing these repetitive things, right? They don'tfeel that the way we do. So, so yes. So that,

Julian:well, it's amazing to see, it's like, if you think about a use case of it, I, Ithink doesn't really it doesn't really consider the amount of value of justhaving something like that engine or like a Yugabyte to be able to not thinkabout it.

And, and the luxuryof not having to think about it. I think a lot of people generally just, justtake a lot of things for granted as we, age over time. And this is one of thosethings in terms of, not only the ability to be flexible, but I'm sure it tookso much time to change the machines and more of a manual process and you hadsomething variable like a sports event.

I'm sure it waslimiting on. The amount of maybe promotions you could do, or if you think aboutthe simple tactics that companies deploy that increase the amount of volume.When you think about a large company, I can only imagine how much time and costis spent into changing the machines just to execute.

If they didn't havesomething that variably changed it on its own and yeah.  

And thinking aboutYugabyte a little bit more, is there any is there any use case of the of, ofthe, the technology that you didn't expect when building it?  

Karthik:Well, the use cases are always like when you start building, at least when westarted building, it was more like, we wanted to simplify the way, app, modernapplications are built.

We wanted to enablestuff, et cetera, et cetera. So that's how we started. And sometimes it's hardto predict what comes your way, what really happens, et cetera, right? So, butthere's a lot of very, very interesting use cases out there. So, like forexample all of the General Motors cars, right? They send their you might'veseen these OnStar vehicles, right?

Like you might'veseen the logo on, on cars, the OnStar symbol, right? All of those cars, forexample, they, they have some capability or some, it's called different, it'scalled a different name now. But they have some special capability to make themsmart vehicles, right? So for example, like, you wanna do a 9 1 1?

Emergency. Likecall from the car, right? Or you want your car to open when you walk right nextto it and it's gotta open, or, or, or, whatever you want it, want, you want itto tell you, like, you know what, if you drive from here to there and back, youprobably need to fill gas or whatever it is, right?

You want a bunch ofsmart stuff. Right? Now, all of this stuff is back by a database, right? And soin this case, it happens to be a, a yoga by db. Now, the crazy thing about thisuse case is like, its volume is off the charts. It's like a million rights persecond. More than that. Right. And so it's 'cause these vehicles are alwayssending stuff and, and, and, and similarly, like the res are on top of that.

So now you talkabout how can you find out is, is there a 9 1 1 call? There's that, there's awhole bunch of suite of applications that keep getting built, right? So, so wenever thought of use cases. We've heard a big data use cases and we've heard ofuser applications, but here we are seeing a lot of merger between the two.

So where there aresmart user applications built on big data, that's an interesting one.  

Julian:It just seems like it. I guess one thing is, is to consider just how muchthey've been so good at implementing that technology in every car and how muchpeople, how many people are using it, but just the mere amount of just offeringsomebody a capability can just, spread immensely.

But yeah, continuewhat you were saying.  

Karthik:Yeah, I mean, there's a number of these type of things. Like for example likewhen Covid came right, it just like did like, so much of change that sometimesit's hard to hard for us to think through the Im imp implications, right? Yeah.Like, like for example, a lot of the retailers, they said, you don't need tocome to our store.

You can just likeorder online and pick up curbside. Or you can mm-hmm. Go to the store and shipit home. Right now we don't think much about, I, I never used to think muchabout all this. It's like, sure, of course you do that. It makes a lot ofsense. Like, what do you mean you don't even do that? Really? But, well, itturns out that's actually quite complex because the number of people placingorders now, you can never say no.

'cause if youwalked into a store, you're never gonna be turned out. Right? You might standin a line, but you still get inside. You still do your thing. Right? And evenstanding in a line isn't much unless it's covid. But, People started opting forthe, pickup, curbside, shipped to my home, like, come and drop it at the backof my car.

Contact free, allof this stuff. And those are actually done online or with an app, and now youhave to build on those. So those type of use cases, which are like, I would sayedge and distributed, those are quite interesting. Like, you need to do thingsin different places. You need to synchronize different data locations, right?

Like, you know howyou. How do you do the inventory on store with your, ability to find thisonline with your sync? So it's just a lot of synchronization across the board.Like, and this is happening across the board, like banks, for example. You candeposit checks from your mobile phone by taking a photo.

So all of these typeof things where it's a very distributed way of, of handling things, right?Yeah. Like, that's another fascinating set of use cases, right? So there's a,there's a lot of that, a lot of that interesting stuff going on, so I neverexpected that. A third very interesting one is, because of the rise of thesedigital things, all company, all countries are figuring out who owns the data.

Like if, forexample, I'm a, I'm a European government, right? A government in a Europeancountry, and my citizen, a country, somebody living in my country does atransaction and the server that that transaction is stored on the databaselives, say in the us right? And that lives on US soil in a data center in theus.

Does it belong tothe US government or the European government, or who owns it, right? Wow. Yeah,yeah, yeah. Craziness. Because is it the physical location? Is it the personwho started it? So now this is leading to a whole bunch of geopolitical thingswhere you gotta keep your data local to where it's generated.

And so that meansif one of us travels. One week to Europe and then comes back here, and then youlook at your transaction history. But you gotta compose the first 10 rows. Thefirst 10 transactions from the one week in Europe, and then the next one fromEurope. From from the us Yeah, because you're local.

So now over timeyou'd get five transactions from us, two from Europe, and another five from us.'cause that's what the. Laws say and for good reason. Right? And so now youneed a database that can pretend to be one database, but living in manylocations, right? So it just makes it very interesting. So

Julian:yeah, it's so fascinating and, and seeing that, you've been seven yearsunderway and, we've talked to founders who you know are, are launching their MV P, some of 'em who just raised their first round of funding, others who have.Just got their first partnership and are starting to really figure out theirchannel partner network and start to grow and scale.

Where are youcurrently at and what, what is kind of the next milestone for Yugabyte?  

Karthik:So for us well, fortunately we're past a number of those stages, like, thanksto the years. Yeah. And, and, and like firstly I'll say that. For everybody,the hardest thing out there is to figure out your messaging and your productmarket fit.

So those two thingsare absolutely important to nail and they're very, very hard to do. Right? Imean, any, anything that's disruptive, which a lot of the technologies aredisruptive by definition, means you can't tell people what it is. Because ifyou could, then there's already something and somebody else would've done itbetter, right?

So, so figuring outhow to explain, like, for example, the first person that built a phone, Or thefirst person that built a car would they call it a better horse or would theycall it something else? It's just very tough, right? Like, it's just verytough. I have a really good horse. It's just get into all of this type ofstuff, right?

So that valueproposition is very hard. So that's something that you shouldn't taketrivially, like, it's, it's totally worth doing. As to our stage, I'd say, likethose things, fortunately we are beyond, we know, why we're doing it. Thesecond thing to nail is to figure out your own growth story or what peoplecalled go-to market story.

I used to hate thatword in the beginning as a founder. Like, why do you keep asking me this stuff?I'm just gonna build it and then gonna go sell it. What's the big deal? Right.But, and of course, use the channel, what's the big deal? Right? But there isactually a lot of nuance there. So it's like, just totally worth figuring out,are you gonna make it open source?

Is it, are yougonna make it a fully managed or is it gonna be a hybrid? All of that stuff.Who your exact market segment is. It's funny that over time, What you do andwhat you address actually decreases and becomes more specific rather than staytoo general. Yeah. So, so I'd say for us where we stand, we have our main focusis.

Business criticalapplications, so things that matter. So if it goes down, then businesses willhurt for it. So availability and making sure it's always running and you haveyour machine type change or your increase in scale or your data center failure.None of this should affect business, right?

So anything that'sbusiness oriented, business facing, end user facing, these are critical thingsfor us. The other thing is use cases that need scale. So, if you have a lot ofdata coming in and you have a system that you have to manage with relativeease, well that's another thing that, that we go after.

So there's a,there's a lot of those use cases we are seeing, like a number of use cases thatyou know, you probably have interacted with in your daily life. Like Imentioned, a couple of them. A lot of your if you're going to most of theonline, retailers that's not amazon.com and you, buy something, some part ofyour.

Order processing orshipping or some part of that actually lands on a Yugabyte DB somewhere, forexample. So in, in, in North America at least. Yeah. So, so there's a lot ofthat, like if you're using Comcast that's hitting Yugabyte DB for health of theComcast, like, the device, the, and, and same thing with Sky and Bell Canadaand a bunch of other, so, so it's.

We are seeing a lotof usage. For us, our next milestone is, there's tiers of criticality insidethe enterprise. And so we're starting to climb up in those tiers to become, tostart to address more and more critical use cases. So that's one thing that,that's the next milestone for us.

Like, becausepeople want to put the highest grade applications on top of us. These are themost critical, like, things that move money. Yeah. Or like in paychecks, likeit's that type of stuff. They're starting to look at those type of things.Which is, a tall order, but very satisfying.

And similarlythere's a lot of smaller companies that want to use us for the ease of, simplyrunning it on our fully managed offering. And here there's a lot of interestingasks about, like I gave you the example of keeping data local or like justscaling on demand without even seeing what happens behind the scenes, enablingthem to build applications really quickly without worrying about downtime orany of these things.

So we're seeing alot of that. I say it's most of the, so yeah. Milestones for us is to make iteasier to like use the database to scale. Like to make it look more likePostgres to help onboard people to mm-hmm. A Postgres like database or fromPostgres to a, a resilient and available Postgres so that they can like,continue their journey.

So I'd say a lot ofthat we are seeing a fair bit of people that are moving their applications tothe cloud and have to move their databases from Oracle DB two, SQL Server,these type of databases, they have to move them to the cloud 'cause theirapplications are going there anyway. And there is no good database that has allof the relational features yet is as cloud native as they need it to be.

So I'd say thoseare the areas where we're most focused.  

Julian:And what do you view as the biggest challenge your company faces today?  

Karthik:So right now I'd say that the challenges are more internal, more than externalright now. Mm-hmm. There is, like, for example, we see a clear line of sight todemand and the need from the customers.

They are telling uswhat they need quite clearly, in fact, and they tell us how they currently getaround these problems and why they cannot do that in the, they're pretty clearabout it. Right. So that's not a no problem there. Our messaging, I think is,is pretty reasonable. Like, as in people get the idea pretty quickly.

There's always moreto do there, but, it's, it's pretty reasonable. So we're okay there. I'd saythe main things are, the first one is awareness, and awareness and adoption.Like more people need to know that we are handling as critical a level ofworkloads. Like, because it looks like a new database and how much are youreally doing?

But we're prettyunique as a startup because we are handling pretty critical use cases for ourjourney as a database company. I mean, database companies are notoriously hardto build anything that's deep technology is notoriously hard to build. So, sothat would be one. And then I'd say the other one is other risk is our ownexecution risk.

We just need tokeep our heads down and build like the, the trick is, obviously we cannot justreplicate something like Postgres. 'cause then we end up with Postgres, whichis already there. There's nothing to build. And we cannot deviate too far fromPostgres because then people are like, oh, what the hell is this new stuff?

I, I, I don't dothis that way in Postgres. This seems. So we gotta blend the two and kind ofmake something that's familiar enough, yet different enough in the rightplaces. And so that that line we have to, keep maintaining that line. Right. Ofcourse, as a database, company quality and.

Stability, all ofthat stuff goes without, right? So,  

Julian:Yeah.  

I love this nextsection. I call it my founder, f a Q. So I'm gonna hit you with some rapid firequestions and we'll see where we get. So, first one I always like to open it upwith is what's particularly hard about your job day to day?

Karthik:I. I'd say the number of context switches. There's a fair number of contextswitches. So it's like a lot, a lot, a lot of small threads. And the hard, butalso the fun part about the job is to keep track of all current trends, liketechnology trends. Yeah. Like, so say generative AI or edge, or it matters,right?

So, and how does itmatter and how is it relevant? So I'd say those are the, those are the twoparts.  

Julian:Yeah. Yeah.  

And, and what whatwas the reason behind building an open source? And making that decision. When alot of companies, they have the opportunity to do so now, and Web three isobviously making it popularized, but when you did it, it's not necessarily themost popular choice.

Karthik:It wasn't. Everybody was going the other way. Actually, that's a interestingstory. When we started the company, right, our founding thesis for the companywas we would build a database. And we would make sure that this database worksvery well as a DBAs, fully managed service, right? So build a database that cando everything we need and make sure that it is built to run as a database, as aservice as opposed to a bespoke database.

So those were thetwo things. So we invested in the DBAs also early on, but you know, this isfunny. We wanted to open source it because. Hey, Apache, Cassandra, ApacheHBase. Well, what's the trend, right? We've just done open source for thelongest time and not one, but two databases before in the open source.

So we said, yeah,we gotta open source the database. That's how it is. And our investors told us,and with good reason that, you guys can make that decision lightly. 'cause willyou have a company after that? It's not clear. This was back in 2016 and itwasn't really clear that, open source was a viable commercial model.

So we said, okay,that makes sense. We don't need to go open source in a hurry 'cause that's aone way street. So let's keep it ready to open source, but we will think aboutit, right? And so, we did our research and we looked at all kinds of licenses.We looked at A G P L often called Amazon g p l at the time to make sure Amazondoesn't run.

We looked ateverything, right? And then we said, you know what, if we're doing this thedatabase needs to be adopted in, in, in, great amounts. For the company to besuccessful, but the commercial portion of the company is not gonna come fromsupport. It's gonna come from database as a service because there's a lotpeople who need to make sure just take this headache off my hand.

I don't need todeal with running the database. I wanna build my application and succeed.Right? So we said that's what we're gonna do. Our investors still urged us.That's not a real open source model. It's not a real business model if you'redoing it all open source. So we say, you know what the hell?

Okay, fine. We'llkeep 80% of the database open, 20% close. It's called Open Core and we'll keepour DBAs as commercial. Right? That's what we said. And then a year and a halfdown our Postgres messaging, we said, we are gonna be like Postgres. Becausewhen people say, oh, there's like, 350 databases literally, and you know you'regonna build a new one and it's a very competitive space and why do I want a newone anyway?

Well, our answeris, there's really just a couple of databases. There's Postgres or MySQL iswhat you start with. And Postgres is the more popular one now, but it was a betback then. And we said, we're just making Postgres cloud native. If you'rebuilding an application that's cloud native, but you pick Postgres, you have alot of work to do, we're simply making sure Postgres becomes cloud native soyou can go build your cloud native application on what is just Postgres, right?

And so they cameback a couple of years later and said, yeah, all that's great except Postgresis a hundred percent open source and you guys are only 80% open source. Whatabout that 20%? And we said, okay, fine. Dammit, okay, we gotta do this. So wesaid, let's go. Actually. Pull the trigger and see what happens.

Because our thesiswas people were finding enough value in the DBAs that the database wouldn'thave detracted from our business. So we just overnight made the database fullyopen source, and guess what? It didn't detract, it actually accelerated thenumber of people that had adopted it. So, it just, yeah.

It was a difficultmove at the time because everybody was going the other way, and we said, yeah.If Amazon, if the, the other fear was if somebody like Amazon or one of the bigcloud providers pick us and start running us as a service, then what would wedo? But we had built the company around being DBAs, so we said, yeah, we'd haveto compete with them on DBAs.

That's what we'dhave to do anyway eventually. So might as well do bold choice.  

Julian: Ilove it. And I love, it's like, one thing I hear a lot of really successfulcompanies and founders in terms of it, its ability to have adoption and also,ability to execute on a particular model is having this kind of inception ofbeing open and available almost just like almost this free adoption now, Iguess popularized freemium model or whatever, but.

Companies whoreally allowed access to their technology, but then realize that the, and, andobviously you can add to this, the, the portion that is where the money is, isthe is not only the intellectual property, but also how you use the technology,how it implements, how it scales. A lot of people don't want to do thoseactivities and trust those who are experts at it to do those.

Activities and themore you have out in the world to actually, be an expert or for people to knowyour product or see your product to find it only adds to the validity. Andobviously I think, I think you made a bold choice then, but seeing everycompany now kind of take on that similar approach it's really cool to see howthat paid out, over, over the time paid out.

Karthik:Yes. Yeah. So, yeah, it's funny, these turning points, right? Like we doubled,like same thing when we doubled down on Postgres, we had been building. Whatlooked like Postgres, but was in fact a brand new engine for about five, sixmonths. And then we said, yeah, I mean we didn't know how deep or complicatedPostgres was.

And then we said,dammit, if we were to build everything in Postgres, it's gonna take us another15 years 'cause it's been built over 30 years. There's only so much time youcan compress. And so we said, you know what? Throw it all out. Let's startagain. Let's go and make Postgres distributed instead of making a distributeddatabase look like Postgres.

And there was a lotof risk in doing that, but the best time to do it is early in the company. So afew of these. Fundamental shifts. Yeah, it worked out. Thank you.  

Julian:Yeah, I mean, it, it's part of the playbook and I, and I see it and it'samazing.  

And one thing youmentioned earlier was this whole idea about new behavior.

You mentioned itwhen you were talking about, what you had built for Facebook and, and youdidn't know whether or not it was gonna scale to, 200,000 beyond, what is itabout, I guess can companies always predict a new behavior? 'cause that'ssomething that challenges me as a founder as well, is, putting out a product tosolve a problem and then maybe.

Thinking about,there might be new behavior, but I feel like I'm always wrong. It's like this,this whole new behavior aspect. Describe that phenomenon a little bit more and,and how, as a founder you maybe even attracted, maybe even shift your businessmodel towards it. Decide upon it or ignore it completely.

Karthik:No, I think it's always there. I, I think it's, that's the most important thingthat'll make or break the company. Yeah. In fact, not adopting it or embracingit is, is actually going to be in the long-term detriment of any company, smallor large. In a small company, it's more in the near term 'cause that's what thecompany is built around.

And large companieshave more of a cushion, so they erode over time. Right? Like, but, butessentially that's actually the, the biggest danger, which is to be complacentin the behavior and not notice the behavior shift. It's kind of like this, whenyou start driving, everybody in the road is driving in the same direction asyou, and then a little bit later you'll find that 10% of the people are drivingin the opposite direction.

And then a littlebit later you'll find 20%. And now you're like, wait a minute. Or you can say,what the hell's wrong with these people? They should all be driving the otherway and you keep driving the way you wanna go. So that's the time to kind ofask the question, should I be changing sides and driving the other way to be anearly adopter, or is this thing truly not?

And there's alittle bit of art and science in this. It's not just pure reasoning because youhave to test. Because there are things that come up very quickly, as it'samazing. It's so useful. And then it settles into like, it's called the heightof disillusionment and then the trough of, or the height, the hype, hype cycle,right?

It's the, the, Iforget the names, but it's the peak of the, the, it is good for everything. Andthen there it goes to a trough of it's good for nothing, and then it settlesinto what is it really good for, right. So as you see it start building uptowards, it's really good for everything. It's good to reason through whichaspects does it matter?

Do does it matter?Does it not matter? What are we going do, et cetera, right? Like, but I thinkthose are, those are pretty critical. I can tell you a few in Giga by its ownhistory. So like I said, Postgres was one. Investing in the DPAs was another.So. We started building the database, I'd say sometime in, end of Jan, Feb,Feb, Feb of 2016.

And two to threemonths later, like around May, June, we started building the DBAs. So, rightaway, right, like we invested in the DBAs because our future, the bet that wewere taking was everything would go as a managed service, right? But what wenoticed in the next 200 conversations with enterprises that followed is thatpeople simply weren't ready.

They were like, Weare thinking about if public cloud should be on the roadmap. So it's not on theroadmap. They're thinking about if it should be on the roadmap, like, oh myGod, fine, but we said we're gonna stick to our bet. This is the bet because weare seeing a couple of people turn around. We saw how it played out in Facebookinternally, and we felt like that's where the world is headed.

But it just feltlike a long time before a majority of people would go away. So we said we'regonna build it our DBAs in a way that we can ship into the customer'senvironment or run it by us. Either way it works and we will decide based onthe customers that come. Well, the, out of the first bunch of customers, amajority of them wanted it in their own environment.

So we shipped itbecause they said, small company like you, new database. We aren't trusting youwith data. Not gonna happen. You gotta give us software. We said, sure, it cangive you it. It's a, it's pretty ally, a management software around a database.You take the whole thing and you run it. But by around 2020, I'd say like aboutfour years later, we saw that people were moving to the cloud and cloud managedservices were getting more interesting.

And it was nolonger a question of if it's already there. Now the question is, is it a liftand shift? Like, am I sticking to my database or am I actually rebuilding forthe cloud for value? Right. And by 2020 1 22, it's completely shifted around towhere people are saying, you know what? Lift and shift is fine, but I know I'mnot gonna get value.

In fact, it's gonnabe more expensive. I'm going to rebuild into cloud native for value. And so,now we find that our managed service is really, really taking off in a big way.But you know, it's about reading that because, we could have gone the other wayto say, yeah, nobody wants a managed service.

It looks likeeveryone says no, they don't even have it in their roadmap. Let's just go dothe other thing, whatever it is, and it would've been the wrong move. Right?And so same thing with Kubernetes. When it came up, we were early to embraceKubernetes and now it's happening in a big way and, and so there's a bunch ofthese shifts that's very important to read.

The thing thatmakes it hard is you're already so busy. You're already like 130% pool withwork and things to do, and this is just another 50% to add to that. Like, oh myGod, who has the time or the energy. But it's important to figure thatout.  

Julian:Yeah. There's, I mean, there's so many more routes we can go, and I know we'recoming to the end of the show, so I'll ask you this question just because we,we love to kind of add it to our reading list.

But  

what's One book ormaybe even an individual, a person who's had a lasting impact on you, whetherit was early in your career or now?  

Karthik:Book the, i I, I love the, the, I mean, I'm, I'm, I'm into this type of stuff,but the hard thing about hard Things is a book by Anderson Horowitz. It's areally, really nice book.

Yeah. It gives allthe highs and lows and yeah, I just love the book because it's, it tells youthe power of sticking through and being true to, whatever it is the goal youwant to get. So it's just amazing. In terms of people, yeah, there's been a fewpeople at different stages. Early on in my life when I was younger, I'd sayhigh school, undergrad.

I used to lovecomputer games a lot. And one of the games I loved to play growing up wasquake. I don't know if you've heard of his shoot, the first person shootergame. And I loved the person naturally who made the game, which was this guy,John Carmack. He's still, he's still around. He, he joined Facebook for Oculusand then he's doing his own thing.

So anyway, so itwas for me, his, i, I, I was following the evolution of three D shoot him upgames from, yeah. Wolfenstein three D to Doom to, and each of them has a veryinteresting technical story behind it, like how you composed the three Dgraphics with emerging processors. And it's just, it was very fascinating forme.

I'd say later in mylife, it was more recently it's Steve Jobs for his product sense, that aspectof Steve Jobs, I'd say because Apple products are just, yeah. Awesome. Likejust so easy to use and get to so much. Like, it's fantastic. And and yeah,and, and of course mark Zuckerberg, having worked with him personally andknowing him and as an in person, Quite a bold and awesome person all around.

So yeah, it's beena few people. Yeah, just,  

Julian:just a few. Just a few really, really amazing people. Well, it's been such apleasure. Thank you. Yeah. Yeah. Of course, man, it's been such a pleasurehaving you on the show. Not only just, going through your background, yourexperience, but how you think about technology, how you think about buildingthe different decisions you made and why you made them.

Everything's sointentional and, and I know as founders we appreciate understanding the reasonswhy and the intentionality behind decisions 'cause everything's sohypercritical. Last thing I always like to, to ask is, is there anything thatwe missed here, any question I didn't ask that I should have?

Anything left onthe table here today?  

Karthik:Well, if you ask an open-ended question, that's kind of hard, but no, I thinknothing I'd say well, the trend that's happening now nobody needs to say is Genai. So if I tell everybody to go figure out their heart in Gen ai, we arefiguring out ours.

So I. It's one ofthat extra to add on to your 120% schedule, but unfortunately you gotta do it,so, so yeah, look at both sides. But that's the only thing I'd say. No, no,nothing really. I'm just joking. Nothing really amazing.  

Julian:Yeah. Yeah. Amazing. Karthik, thank you so much for being on the show. I hopeyou enjoyed yourself.

Karthik: Ireally enjoyed myself. Thank you for having me, Julian. Really, really goodquestions. Thanks a lot. Really appreciate it. And yeah, thanks everybody forlistening.  

Other interesting podcasts