CLAIRE: 00:00:04
Welcome to Talking Postgres, a monthly podcast for developers who love this database. I'm your host, Claire Giordano, and in this podcast, we explore the human side of Postgres databases in open source, which means we delve into why do people who work with Postgres do what they do and how did they get there? Thank you to the team at Microsoft for sponsoring this community conversation. Today's guest, and I'm so excited, this is episode 29, is Shireesh Thota. Shireesh is the CVP for all the Azure databases at Microsoft. He's responsible for leading engineering and product management for databases, including Azure Cosmos DB, Azure SQL DB, and Microsoft SQL Server, MySQL, and of course, my favorite, my absolute favorite, Postgres. Shireesh has been working on databases either as a developer or a product leader or engineering leader since 2006. And in addition to working at Microsoft, Shireesh spent the better part of a year in like the 2022-2023 timeframe as SVP of engineering at SingleStore, working on a database that used to be, some of you might remember it as MemSQL. Welcome Shireesh.
SHIREESH: 00:01:23
Thank you, Claire. Really excited to be here today.
CLAIRE: 00:01:26
I am too. We started talking about this months and months ago. So I'm glad that we're here. Today's topic is titled How I Got Started Leading Database Teams. But the I is not Claire, the I is Shireesh in this case. And I think before we get focused on the leadership part, right? How you got started leading database teams. I'm really curious how you got started in tech at all. Can we go in the Wayback Machine and talk about that?
SHIREESH: 00:02:00
I'm happy to. So I've done my engineering in computer science. So I started right there. And then right after my computer science engineering, I did a brief internship at Oracle. So my database roots go all the way back to Oracle. And then it was just a quick few months. And then I started as a high availability engineer at Motorola. For those who don't know Motorola, this used to be a company and was acquired by Google. Motorola was a really big company that was basically into the embedded systems and it was trying to do wireless carrier software. So I started there, built a bunch of real-time operating systems code to do embedded packages for wireless carriers like Sprint, Verizon, etc. That was for one and a half years. Then I came to the United States to do my master's, again, in computer science. That was also... but it was mostly rooted in string algorithms, and I thought I was going to go into biotech. But I landed an internship at Microsoft, and then I spent almost 20 years at Microsoft ever since.
CLAIRE: 00:03:16
Wow. And what about then the transition from being an engineer to being a manager? How did that come about?
SHIREESH: 00:03:27
Yeah, you know, maybe I'll take a few minutes to talk about my journey at Microsoft, and then I'll touch upon your question, Claire, if that's okay.
CLAIRE: 00:03:32
Okay. Absolutely.
SHIREESH: 00:03:37
Yeah, so when I started at Microsoft, my first foray into Microsoft was basically being an intern in SQL Server. So I started working on Management Studio in SQL Server. It was very fascinating because what I was touching was impacting millions of developers, and it was touching so many important customers across the world. So it was super fascinating. I managed to build a tool that would compare two large databases. This was back in 2006.
CLAIRE: 00:04:08
Okay.
SHIREESH: 00:04:08
And then I loved the experience so much that I collapsed all my courses into one semester. I basically graduated in three semesters for my master's and came back and joined Microsoft full-time employee in the same team that I started. This was in SQL Server. So I spent around five years in SQL Server, contributed to major releases, 2008, 2008 R2, then a bunch of releases. And then I was the developer number one, effectively, for Cosmos DB. So I was there right from day one. Spent a lot of time in Cosmos DB, built various pieces, query engine indexing, elasticity, lots of things. And then I took over the entirety of engineering for Cosmos DB. And then ever since, I've been a manager. So to then answer your question about my transition, I definitely did not wake up one morning thinking that it would be fun to do one-on-ones, performance reviews, budget management, et cetera. It definitely was not the case.
CLAIRE: 00:05:07
T&E approvals, how about that?
SHIREESH: 00:05:12
I became the manager in the old-fashioned way. My manager at that time tapped me on the shoulder and said, hey, I think you are good with people. We need to scale. We were just five engineers on Cosmos DB back in 2012. We started in '11, and for the first one, two years, for two years, I think we were just five people. Around that time, he said, "We need to scale, we're going to hire a bunch of people. I need you to help me." I said yes, without fully reading the spec. Then there's a big contrast between the life as a developer and life as a manager. As a developer, it's binary. You have bugs, you have architectures that you need to go build, you have to fix bugs, you have to really design things. Success was measurable in commits, PRs, and just the amount of usage that you're seeing, et cetera. When you become a manager, you have to really understand that the job role, of course, changes significantly. It is not just about really going and fixing things anymore, but it is really about unblocking, aligning, and amplifying. My role changed massively in terms of that transition to not just be the problem solver myself, but to really make space for others to shine and to enable them to first and foremost build a great team. And those things did not come easily, of course. It takes time. And one of the most important things to remember, and at least the mistake that I have done, was that early on as I was transitioning into being a manager, I managed like how I coded, right? And that doesn't work. People are not functions. They're different, of course. They're all human beings with different aspirations. So you really need to connect the vision that we have with their aspirations. It takes time. And then...
CLAIRE: 00:07:14
Wait, can we pause on that for a second? [Yeah, yes, of course.] I managed like how I coded. Can you peel that onion and tell me more about what that means?
SHIREESH: 00:07:24
Yeah. So when you're coding, you basically think of a lot of pieces in an objective way. You basically think that these are the input metrics, these are the output metrics. You want to basically achieve a few things in terms of being quick, being precise. You want to think about resiliency, security, and you're acting as though the pieces are all obviously objective functions and without any emotions attached to it. And so you don't want to treat your people in that way. And that is a common mistake when most of the engineers who become managers the first time. There's no documentation on the people. You have to go poke them, understand what they are trying to really achieve, what their aspirations are. Unlike APIs, when you're trying to use them, you have a lot of well-defined interfaces. You really know how to use them. When will they go right? When will they go wrong? How to use them, how not to use them, how to deploy them in the right places, to then go build the architecture. You have a lot of objective mechanisms around it. You're effectively doing the same kind of, you're solving a similar kind of a problem if you think about it. There is an architecture to organization as well. Who needs to play in what position? Who needs to do what you want to do so that everything comes together, just like how a bunch of functions, a bunch of classes come together to make a component. So in that sense, they are similar, except people don't have documentation. You have to really poke. You have to spend a good amount of time coaching, learning what they really want to do. So learning them and figuring out how we really come together as a team to then achieve our vision and mission is a different ballgame. So if you apply the same mentality and the same thinking that you do when you are coding and building things technically, and I've seen managers do this quite often. I myself have done this and I failed at it. Yeah, that is really what I meant to say.
CLAIRE: 00:09:29
Okay, because sometimes I think about management as well, I don't know how old your kids are and you don't have to tell the world on the podcast but when you have teenagers a lot of times you you can't address an issue head-on, you kind of have to come at them sideways you know you have to understand like you said what are their motivations what are they trying to do and it's just different. Influencing people is hard.
SHIREESH: 00:09:54
Absolutely.
CLAIRE: 00:09:59
Hmm, you also started to talk about the organizational structure too, so there's managing people and all those challenges and then there's managing a larger organization and thinking about that hierarchy and that's probably, well that you probably didn't have to deal with that in your first management job, right?
SHIREESH: 00:10:17
Not, yeah, not then. It definitely took a while for me to get to that point to then having organizations, manager of managers, and now where I have a really large organization. So that's the second level of transition. And I wouldn't think of that as really, it's not a promotion, really. It's almost like a transformation where you are really looking at things in a bigger lens and you have to zoom out. You really have to think about how to shape the environment and the bigger mission so that there is a scale aspect that can thrive in that environment. And that is truly the key piece. And often people don't think about up and down. They may either think about up, meaning trying to align well with the mission of the broader organization, and then forget about how to cascade it down. Sometimes people do the opposite, which is that they basically go focus quite a bit in terms of making sure that their organization thrives, but they fail at connecting to the broader mission that their company or their organization on top has. So you really need to play this game in three pieces. One is, of course, managing up and aligning well. The second is to make sure that your team is set up to achieve those functions that your broader organization has. There's also a third piece where you have to laterally manage your engagement with your other teams. Now, this is, in some sense, connected to the first piece, which is going up, but it is an equally important piece of the puzzle. And that takes a while in terms of really trying to figure out how do you go from, you know, a small boat to a medium sized ship to a really big ship.
CLAIRE: 00:12:01
Yeah, and that managing, or networking, staying in touch, and in sync, and aligned with your peers which is what I think of when you talk about managing your engagement laterally, that's what you mean, right? [Exactly.] Other leaders of teams next to you. It's, I just feel like that's not documented well. Like a lot of people miss that in the beginning. And the thing is, I don't know why you think it's important to laterally manage other teams. So I should ask you that. But one of the things I've observed is that if you have a relationship with someone and maybe there's some trust or some background or some familiarity, then when there's a conflict, it's so much easier to resolve it versus if you haven't talked to them in nine months and you only see them in staff meetings and you don't really know each other then I think it's harder to resolve a conflict.
SHIREESH: 00:12:53
It's a super important part, Claire, and I'm really glad you brought this up. This is really what I call a social capital. You really can't succeed in the tech without social capital. And it comes across in multiple ways. And one of the reasons why I encourage people to have a little bit of a face time, we are, of course, a hybrid company at Microsoft, and I really love that, but once in a while, sort of getting that social capital is important because it gets burnt really fast. And it is really important to understand people. It need not be just face-to-face, but even otherwise. Again, as I said, people, unlike APIs, are not documented strictly. So you really have to go and poke and have to figure that out. And that's the only way to unblock most of the tougher, harder situations. And they come up every day.
CLAIRE: 00:13:43
How do you feel about, I know you talked about face time, right? And we are hybrid and I love that we're hybrid. I'm recording this from my home office today. I appreciate that about Microsoft tremendously, but how do you feel about the importance of like turning on video when you are having conversations with people and you're not in the same location? Is that something you do or does it not matter? Or do you have a philosophy on that?
SHIREESH: 00:14:12
So personally, I do that in every meeting that I am in. I rarely go off camera. I believe that it benefits me a lot because I sort of really want to express my emotions and how I'm thinking more viscerally, and so people can see me and understand what's happening and the body language does play a bigger role. So I definitely do that and I know that a lot of my managers and the people that I collaborate with do that as well and I really respect that. Having said that, we live in a very hybrid, very diverse world and so I understand absolutely that there are cases and situations where you really can't. We have to manage a lot of things in our personal lives. I know many of my reports who have to drop their kids sometimes when they're taking calls, and it's not convenient. I totally get that. So I'm very supportive of those situations. Just broadly speaking, though, I would love to sort of do more often. You don't have to do it every case. We need to have that flexibility. But I encourage people to really go, come on video, because there's a lot that you would say without speaking a single word, and it can't show up, right? When you are living in a hybrid world, I think that's important. So I, especially when we are talking to customers, I really encourage my team members to go and do that. I do that myself. I know my manager does that. Yeah, so I'm in the, you know, try and keep the camera as much as possible on. I'm in that camp.
CLAIRE: 00:15:50
I'm in that camp too, philosophically, but I'm not a morning person, and so for my 8:00, 8:30, even sometimes my 9:00 calls, I'm just not ready to be on camera. Anything after 10:00, my time, I'm on camera, no problem. But yeah, earlier in the morning, I just can't do it. So, but yeah, and then people are across time zones. So what's 10:00 for me might be 8:00 in the evening for somebody else. So that's always a complication. Okay, for anybody who's listening and maybe somebody who's a developer, has been a developer for years, but is trying to figure out their future career path and is wondering if management is a job that they would be good at or that would appeal to them. I'm curious if there are any other failures or surprises or big challenges that you had on that transition from being a developer to being a manager that are worth, I don't know, warning people about or sharing, sharing with people.
SHIREESH: 00:16:53
Yeah, I think the number one thing, as I said, is that when you are transitioning from an IC to being a manager, You don't want to manage people like how you manage code. That's really a huge warning sign, I would say. The second thing I would say is that a lot of times, one of the best ICs on the team tends to become the manager for that team. And when that happens, they basically inadvertently, without any intent really, compete with the people that they're managing. And that's just a really big red flag. You're really not there to compete with them. You're no more trying to shine against the people. You're really enabling the people. You have to be secure enough to be a manager, to know that your win is rooted in their win. And that thinking and that emotional mindset is extremely important. And you have to think about it every day when you're a manager. You're really here to make sure that you enable them. You make space for other people to shine. And ultimately, the goal is for the team to win. And we are not playing a single person sport. We are absolutely not playing tennis. We are playing soccer. So that imagination, that thinking, needs to be there when you're a manager. I would also say and warn people that if you really don't enjoy meetings and trying to really go from topic to topic, then it can get a little harder. Because when you're a manager, you don't necessarily sit in front of the terminal often and you don't have, you're typically in back-to-back meetings with no compile button, right? There's no compilation. There's no build going on here. So you need to ensure that you're comfortable with that. You also need to ensure or be comfortable with the fact that your job is not being the smartest person in the room. It is about learning from others. It's making sure that you really are amplifying with your judgment. You're unblocking. You have to focus on the transitions and the changes. But building people as a manager and then focusing on the vision to amplify and to sort of culturally navigate the teams, those are the job functionalities. And you are trying to take on a leadership role, a manager role. And you have to be comfortable with these things. And it's totally okay for somebody to say that I'm not going to enjoy this. I'm better off being an IC. And there most of the corporate companies, Microsoft for sure, enables these things today. And that's a great news. You can definitely go quite far being an IC. So yeah, these are a few topics that I would say people need to remember. Now, naturally, there's a lot of nuances, but these are a few things that I see many of the new managers need to take some time to reflect on.
CLAIRE: 00:19:50
Got it. Okay, so if we go back to the episode title, how I got started leading database teams, we've got the word database in there. And obviously, it looks like you've spent your entire career working on databases. You did not go into biotech, and so was there some aspect of databases or something that happened in that first Oracle internship or your first Microsoft internship? Was there a trigger for why you stayed in this space?
SHIREESH: 00:20:22
Yeah, so I was absolutely lucky to have gotten these opportunities to intern at some of the best places in terms of learning databases. When I was at SQL Server interning, and I obviously had the opportunity to talk to some of the stellar leaders who have made incredible contributions to SQL Server and to databases industry all up. What I've learned over the course of my time there, and obviously it kept building on me, was that databases are the microcosm of everything that's happening in computer science and just generally our technical industry. The reason why they're microcosm is because when you look at the stack for databases, you have to basically touch on every aspect of it. You have to start by looking into silicon. In fact, in our own databases organization, we look at what are all different possibilities to engage with hardware vendors, Intel, AMD, ARM vendors, etc., to look at what we can do to make sure that our databases run really well on the silicon. So you start there, and then you go up and look into algorithms, query engines, query optimizations, system engineering. You have to figure out how do you work well with the operating system constructs. There's a lot of runtime aspects to it. Algorithms, of course. There's a lot of database theory that you touch on. And then on and on, networking, of course, because we are building a lot of distributed systems. And so there's quite a lot of scale-out aspects in there. And then you can go all the way up to full stack. You have to really go build great developer experiences with drivers. You have to make sure that the best drivers, best way of managing your databases, is available. So when you look at the entire stack of databases, they really touch on everything that's there in the technical industry, most everything. And now with AI, of course, there's a lot of infusion of AI in databases in lots of different ways. We are thinking about how to do vector indexing. We are thinking about how to bring the best way to semantically interpret query results. You do see a lot of that in Postgres and across other databases as well. But I was lucky enough to get that insight and feel like this is the place where it would be a complete experience, a really consummate sort of understanding of our tech. And so I stuck with it and I kept loving it more and more. Yeah.
CLAIRE: 00:22:53
I think I mentioned this before that I was going to ask you this, and I don't know that you would remember, but when my kids were young, oftentimes you fill out these kind of templates that say, my favorite color is blue, and my favorite food is whatever it is, and my favorite thing to do is this. And there's usually a question, when I grow up, I want to be..., and I'm curious if you remember what your "when I grow up, I want to be" answer was?
SHIREESH: 00:23:25
That's a great question. I do remember. I think when I was, very early on, I wanted to be a bus driver because I thought steering a giant vehicle with the honks, etc., it looked like absolute power. And obviously, every kid, you know, obviously, probably this was one of the popular choices being a kid, sitting in front of the front seat and pulling the horn. That was the dream, I guess. And then later on, as I probably grew up a little bit, I started loving math. And so I knew that I was going to be an engineer or I wanted to be an engineer. What kind of an engineer? I wasn't sure about that part. But yeah, that was really how we got started. But pretty early on, I loved math. And so I knew of some of the folks who became engineers in and around me. And that appealed to me quite a bit. I did not touch my first computer until I was in my seventh grade, high school, I think. So it came very late. I learned BASIC first, and then I choose computer science thinking that this is really the... I loved it, of course. Early on in high school, when I started playing with simple programs, it just gave me the absolute power that I was dreaming, that I couldn't get sitting in front of the front seat in the bus. But I could get that sitting in front of the computer. It just transforms you into a different world, and I really loved every bit of it.
CLAIRE: 00:24:57
I mean, the metaphor of a bus driver almost works for your current job. [I guess, yes.] You're trying to make sure people get to where they're going, and there's all sorts of different kinds of people on the bus. I don't know. It sort of works. I don't know about the absolute power part of it, but you are steering a giant vehicle. [Thank you.] Okay. So, obviously, I know this but people listening might not know this, at Microsoft you are VP of engineering and product team responsible for all of our Azure database managed services, and some of the other database work that's going on as well, you know, Microsoft SQL Server is used on-prem, correct?
SHIREESH: 00:25:48
Yes, yes.
CLAIRE: 00:25:49
Okay, so it's not all and not only about Azure and cloud database services, but you have to work with lots of these different databases. Now, I have the luxury of getting to work with just one, which I think is pretty awesome for me. But I'm really curious what it's like to have that breadth and to span so many different technology stacks.
SHIREESH: 00:26:21
I'm grateful. I enjoy it. I'm very excited about having this opportunity every day. The breadth is definitely pretty big, but the themes are similar. Now, every database is different. Ultimately, yes, many of the applications could go and be ported into one other database, from one database to the other database. But I am a firm believer that there's no one database that can answer all the questions, and it's the best fit for every problem that you got. Generally, it doesn't happen that way. So these databases are tuned and perfected in certain different ways. So if you look at, you know, some are, obviously there are bigger level differences in terms of relational and non-relational, and we do have a flagship non-relational database in Cosmos DB. Outside of that, everything else is a relational database. Amongst the relational databases, we have both, you know, on-prem databases as well as cloud versions, managed services in cloud. Most of our databases are managed databases. SQL [Server] is the only one that we offer on-prem. And it's a very classic, it's a extremely successful battle-tested database for several decades. So they're all very different. And Postgres, of course, it's one of the most important open source databases that we got here. And I love having the opportunity to work across. And they all shine in different ways. If you think about Cosmos DB, it's designed to offer you low latency at global scale with a superior elasticity, single-digit millisecond guarantees for reads and writes worldwide. And it has some of the most amazing distributed systems characteristics. If you look at SQL Server, it brings deep, deep, deep enterprise features and rock-solid security characteristics with amazing performance characteristics. It's been there for several decades, and it continues to grow, and we are investing deeply into SQL Server. And it's the same engine that powers both on-prem as well as in the cloud. Postgres is phenomenal. Now, I've come to appreciate and love Postgres quite a bit in the past few years. It is open source at its best. I joke with everyone that it's the Linux of databases, and it's amazing to have such a community who's very principled and forward-looking, marry the best of relational algebra, and then sort of really attract the vast majority of the developer ecosystem as well as the enterprise community. So it's really a Swiss knife, I would say, Swiss Army knife of databases. So, yeah, and then MySQL as well. There's still quite a lot of MySQL community out there in terms of really running the commercial databases, web apps. It's really a privilege for me to have the breadth and being involved in all these different databases.
CLAIRE: 00:29:17
Yeah, but you've got to have to do some pretty dramatic context switching during the day. Although, maybe if you know, you're so familiar with all the different stacks and all the different people, maybe the context switching isn't hard. Is it hard?
SHIREESH: 00:29:35
It's hard and easy, in cases where, you know, so obviously relational algebra is same no matter where you go. All the databases have the same kind of challenges in some sense. But they're optimized in different ways. So, yes, it's similar. So I know the stack, and I'm not really switching too much across the board. Non-relational database, Cosmos DB is a little different, but I know I've had the opportunity to build it from the day one. So I know Cosmos DB quite a bit, so that helps me. It is often the organizational architecture, the business challenges, how do we incorporate different pieces, how do we go to market with all these different offerings, and how do we enable customers, provide them the right choice. Those are the places where it gets tricky. So yeah, it becomes harder in those places. But we have a very good suite of database offerings where we enable the choice for the customer. So it's a win-win.
CLAIRE: 00:30:35
Okay. So Affan Dar, who works for you and was a previous guest on this podcast, we'll try to include the link to his episode in the show notes, he wanted me to be sure to ask you, what is your favorite database and why?
SHIREESH: 00:30:54
So I don't know if it's Affan, apparently the guest from the previous episode also wanted to be a bus driver. So I don't know if it was Affan, but I love Affan, so great question. And like any responsible parent, I would... I know the answer, but I wouldn't say it publicly, so...
CLAIRE: 00:31:17
Wait, you're not allowed to have favorites, you love all your children equally, is that the deal?
SHIREESH: 00:31:21
Yeah, absolutely. Yeah. You know, I have to keep it that way, unfortunately. But, you know, having said that, as I said, every one of these databases is just amazing. They have different strengths. We believe that there is a need to have this choice. You don't want to have 24 different databases, but there are a few databases in terms of how they're optimized. There are special cases where some databases are designed in a different way. Cosmos DB is built to have scale and high availability in its core DNA, right? And so it is going to be great when you want to have a distributed system challenges. SQL is designed to have that great hybrid characteristics both on premises as well as in the cloud. It is rooted in being a very strong general purpose database, there are a lot of SMP workloads, classic OLTP workloads, very security rich offerings in SQL, so if you're looking for that kind of a database for tier zeros, yes, SQL is a great choice. And Postgres, one of the greatest things about Postgres is that it's good across the spectrum, both on the developer front as well as on the enterprise front. And as you know, and as everybody knows, the ecosystem, the developer ecosystem, is rooted around Postgres significantly. As AI applications continue to mushroom, I think this is going to be one of the most amazing things for Postgres. So it's just designed for the AI era, in my opinion. And the amount of extensibility that Postgres brings, that's just going to be a huge advantage. So, yeah, I mean, I would say the same thing, that different databases are great at different things. I love all my children, and it's a privilege to have this opportunity.
CLAIRE: 00:33:13
Okay, you know, Affan is going to give you a hard time. And you know that I really wanted you to say that Postgres is your favorite database.
SHIREESH: 00:33:19
I will buy him ice cream.
CLAIRE: 00:33:25
Okay. All right, so there's a really good question on the chat from Tristan Partin about, whether, what your perspective is on whether Postgres can learn things from other database projects you've been involved in.
SHIREESH: 00:33:40
That's a really good question. So I think one of the most amazing things about Postgres is that it is extensible. It's super extensible and there's lots of contributions across the board. So naturally, that's just going to play to its strengths. I would also say that that sometimes becomes one of the challenges for Postgres. Just in terms of the pace at which you want to make big architectural choices and to get it done. And, you know, this is not a critique or any such thing against the way that the community works. I love it. Absolutely love it. Just zero doubts. There's no ifs and buts there. It is truly the strength, but if you want to really look into how to make some big architectural changes, that end-to-end thinking and how do we bring all pieces together really quickly, make bigger changes faster, is an area that's going to, it's a natural sort of like a balance problem that we need to get better at. I think this is going to be an evolution. Not a concern, but it is one of those things where I think as Postgres evolves and it's continuing to become one of the most sought after relational databases in the history of our tech, that is one area where it needs to learn how to get good at that, trying to take on bigger challenges.
CLAIRE: 00:35:00
So I want to make sure I understood what you said. Did you basically, I'll try to paraphrase you, did you basically just say that the extensibility of Postgres, which is a big plus, you know, in many ways, also creates complexity that can make it hard to make big architectural changes? Is that what you said?
SHIREESH: 00:35:20
Correct. Yeah, a few weeks ago, Marco Slot, from Snowflake now, wrote this blog about the complexity of extensibilities. And I was looking at it, and it really spoke to the challenges that I was thinking that Postgres has to deal with it. It's the same thing that is such a great thing about Postgres can also become a challenge. And that is the part that I think we need to navigate as a community in terms of how do we make sure that, you know, we continue to keep the good things but not let it create a huge amount of complexity. I would also add, in addition to that, just the challenge of building bigger changes. Obviously, the community has been debating about things such as moving to threads for connections. Those are the kind of changes that Postgres community has to figure out how do we really rally and make changes like that faster. Obviously, the AI era is going to create a significant amount of demand for Postgres. which is awesome. It is certainly really designed for the AI era. But these changes are going to be, these challenges need to be confronted.
CLAIRE: 00:36:38
The Marco Slot post that you're talking about, [Yes.] was that based on the paper that just got published? I think Abigale Kim from UW–Madison was the lead author and Andy Pavlo was a co-author as well, and David Anderson, and Marco. And it was called something like Anarchy in the Database: A Survey and Evaluation of Database Management System Extensibility. Is it that?
SHIREESH: 00:37:05
I think this is at the datacon. Is it at the datacon? [Oh.] The new... yeah, there was a conversation, that was a Bay Area datacon, I think. I'll find out the link and send it. It was basically talking about the do's and the don'ts of extensibilities and the challenges that come with it.
CLAIRE: 00:37:23
Okay, I'll dig that one up and add it to the show notes then. Cool. Thank you.
SHIREESH: 00:37:25
Yeah. But the paper that you're referring to is a good one too. It's a good one about the Anarchy in the Databases.
CLAIRE: 00:37:33
Well, and also about extensibility and the challenges with them, so I just thought that was the connection.
SHIREESH: 00:37:40
Right. I'm pretty sure there's a lot of cross references there.
CLAIRE: 00:37:42
Okay. Got it, yeah because he'd already worked on the paper by the time he put together that datacon talk. [That must have been the case. Yes.] Okay, all right, so we talked a little bit about your your work leading all these databases and obviously Microsoft SQL Server is on-prem, many of them are managed cloud services, you know, like the Azure Cosmos DB, Azure Database for PostgreSQL, etc. But one of the things that I really want everybody who listens to the show to know is that, at Microsoft, we have a team of people whose primary job is to contribute to the Postgres open source project. And some people don't realize that team exists. And so I always like to kind of shine a light on them because I think they're doing really important work. And I think it's important that Microsoft be, I mean, we have our managed service, but our managed service builds on top of Postgres open source. So it's kind of, to be a good citizen, I think we need to be contributing to the upstream open source project. And the good news is we are, which is cool. This is a very long question, I know. But I'm curious to hear from your perspective, like why do you fund this team? Why does this team exist? And why does this work matter?
SHIREESH: 00:39:04
So, absolutely. You know, a lot of people are indeed surprised when they find out that Microsoft has a team of engineers to contribute directly to the Postgres open source project. I think increasingly people are learning and hopefully it's not a surprise anymore. It is not a side gig. These are folks who are core committers. They do the real deal. They're participating in community. They're writing code patches, extensions, and it's a full whole nine yards. Why do we do it? It's simple because Postgres matters. It's not just to us, but to the entire developer ecosystem. We have the vision of basically going to offer a world-class managed Postgres experience in Azure. And so we just can't be consumers. We have to be contributors when you have such a vision. And so we've created this dedicated team. They're not designed to basically assist us in just running our managed service. This is designed, the team is designed, to significantly improve, just push the whole core idea of Postgres forward independent of what it means to Microsoft alone. This is purely to help the project and to make sure that the whole community benefits from it. And every vendor gets benefited and we collaborate with every other vendor as well. Whoever wants to participate in the community, we are trying to make sure that we offer the best that we have to push this awesome project. And when you run a cloud service at scale like Azure Database for PostgreSQL, you do, of course, inevitably hit edge cases, performance tuning scenarios, and features that need to push the limit. Our goal is to not just duct tape around them, but we want to give it back, make changes and give it back upstream. I think that that's the only sustainable way to improve the core of Postgres, which then benefits us and everyone else. That's kind of the mind shift here. If you think about Microsoft in general, it's true that we did not operate in this way always. But today, thanks to our new operating structure, our cultural transformation, et cetera, we are one of the biggest contributors to open source, just broadly speaking, not just Postgres. But this Postgres team, it's a reflection of that transformation and is perhaps a really good project, a really good example, and demonstrates the new Microsoft, I would say. And, you know, again, this is really what makes Microsoft great. We adapt and we are here to play our part in the open source community in the right way. And we love the Postgres community. So this team is designed specifically to really push that vision forward. And that's it. That's really it. It's simple.
CLAIRE: 00:42:08
One of the statements that I sometimes make is that if we want, we at Microsoft want, Postgres to continue to be technically relevant and commercially relevant in the future, then it means we need to do our part to contribute to the open source project. And then, you know when, I talk to a lot of people about this because I find it interesting, and it also is tangentially related to my job, right? And some people will be like, well, but if Microsoft walked away, everybody else would still be contributing and it wouldn't, it would be okay, right? Like, I get that question. And maybe it's from people who like to play devil's advocate or just people who like to debate, you know, or be provocative. And I don't think anybody can just assume that a successful project today will be successful in five years. I think you have to keep putting in the work. And there is a lot of work involved in every single new release of Postgres, and all those quarterly patch releases, and a ton of work behind the scenes as well, beyond the code itself, right, to make the project run. So I'm really glad we're doing this, I guess.
SHIREESH: 00:43:23
I completely agree. You really said it well. Absolutely.
CLAIRE: 00:43:27
Okay, so let's pivot for a second. I imagine that you meet with lots of customers. And for developers who work on Postgres, are there any insights, things that you hear from customers all the time in the context of Postgres, for example, or even databases more generally? Are there things that you think developers should keep in mind?
SHIREESH: 00:43:54
So, it's a great question. And developers and customers just across the board, they all have, they have a lot of clarity in terms of what they want from databases. So I always tell my team and I strongly believe that databases are really the stars that basically enable applications to shine. We are very happy to sort of like stay out of the limelight, but enable the applications to shine, and the app developers to really win. Ultimate goal for databases is to make sure that the developers can forget about databases. They need not really even think about them. Of course, that's an extreme statement. But my point is that the database app developers should be able to get what they need in their frameworks, tool chains. And then databases are always up. They're always available. And they're giving the performance guarantees in the way that the app needs. Making sure that there's cost efficiency as well. There are all these different tensions that you need to get. Performance, availability, cost governance. You think of these three as like the tensions that go against each other in some sense, but that is the trick. And so when you really talk to the customers, it depends on the flavor of the application that they are dealing with. There are a lot of mission-critical applications who are not as cost-sensitive, but they are certainly, they want to make sure that they can run the Postgres database, or any database in this case. They don't want surprises during upgrades. They want to have fewer knobs. They want to have better observability. And critically, the uptime is pretty high, and they can trust that their workloads won't break when we are scaling or when we are really doing any maintenance work, et cetera, on Postgres. So these are a few things that they care a lot more than features, right? So you really have to remember that it is one of those ironic things when we may be chasing quite a lot of features, but customers are thinking about foundational pieces, resiliency, security, foremost than anything else. So those are really some of the things that I run into whenever I talk to customers. And Postgres, I hear when I talk to Postgres customers that they love Postgres, but they wish that they didn't have to be a Postgres expert to use it well. And that's the challenge, and the opportunity, right? So if you can make Postgres powerful by design, and simple by default, then you unlock a whole new generation of developers who can bear with it, not fearing it, and then take it to enterprise scale. We are certainly seeing the uprise of Postgres going from the mid-market to sort of enterprises and then slowly making it into tier zero kind of applications. And along this curve, we're going to have to deal with these kinds of tensions. And that is kind of really the trick here, the customers. And it's also interesting when you move from on-premises to cloud, because it takes away a lot of their pain. But you need to do it in a way that it doesn't look like a black box. They need to have observability, they need to make sure that there is predictability without having to break their bank. So that empathy for the operator, the developer, the workload architect, that is what they are seeking. And it comes up loud and clear whenever I talk to these customers. Yeah, so I think I probably covered quite a lot of ground here, but these are a few things that come to my mind when I think about talking to customers.
CLAIRE: 00:47:32
You did cover a lot of ground and I love your answer. And there's like five different directions I could pivot from. The one thing, and this is just kind of random, but I want to point out that you use the phrase "it depends." [Right.] because when you were talking about those mission critical customers, right, and the fact that some people care more about cost governance and other people care more about availability for example, and anyway, I just think it's, amusing is the wrong word to describe the fact that the phrase "it depends" shows up so much in conversations about databases, and trade-offs... [It's a very good point.]
SHIREESH: 00:48:13
It's a very good point because that's, any complex system, anything that basically deals with various aspects of state, it has to behave this way and it It has to be, it depends, because unfortunately, there's no one architecture, one answer, one set of choices that is universally applicable for all applications. And hence, it depends.
CLAIRE: 00:48:43
And maybe that's part of why, you know, at Microsoft, you're responsible for several different databases, right? Because, in fact, as much as we, those of us who work with Postgres, there's this phrase called "just use Postgres" that suggests that you can use Postgres for pretty much any situation. But in fact, right, there is room for in the world for multiple different databases. [100%.] And we're not the only ones.
SHIREESH: 00:49:08
100%. But the one great thing about Postgres, though, which I definitely acknowledge and love to give the credit where it's due, is, again, going back to the extensibility aspect of it and really the flavor of the communities coming together, adding so many pieces without having to really make it as a matrix of things. Most of the database architectures are generally matrix where you touch something, it kind of connects into something else. And that sort of is a challenge because you really can't scale that way. But Postgres has mechanisms where you could create your own sort of chain of extensibilities without having to connect to every other piece, and that's quite powerful.
CLAIRE: 00:49:55
So, there is a, well I was going to say a question, but it's really more of a comment, on the chat about the new VS Code extension for Postgres. So first of all, I'm thrilled that somebody brought it up. And this is not a plant. Tristan Partin is the one who brought it up, and he specifically said that he would love to see the new Postgres VS Code extension be open sourced. And so I'm curious if you have any thoughts on that.
SHIREESH: 00:50:23
Yeah, so firstly, I really love the fact that the VS Code extension is one of those things that kind of took off really well. We put in a lot of effort here, so kudos to the team who worked on this. It came out really well, and I'm really thrilled that it helps not just Microsoft developers, but all the developers, anyone who wants to use Postgres, because VS Code is kind of really the dominant IDE. So this extension should really be very helpful for all the app developers, anyone who is a Postgres developer. So thrilled to hear that. And then on the interest about really open sourcing this, I know the team is evaluating it. They're looking into it. Our intent is to make sure that the community really contributes here, loves it, et cetera. So we certainly are thinking in that direction. Affan and Charles, who run the engineering and the product, they are thinking through it. So you'll hear a lot more about it in the coming few weeks and months about this. So I don't have a specific answer to give right now. But we are certainly thinking in that direction.
CLAIRE: 00:51:27
The other comment on the chat that I really like is that VS Code needed a good, or a great, Postgres extension. And I couldn't agree more. It felt like a neglected space. And so I'm really excited about this thing too.
SHIREESH: 00:51:43
I totally, totally agree and love the comments for sure. And really, yeah, it's heartwarming to see the adoption.
CLAIRE: 00:51:52
Yeah, and for anyone who's listening, just to point out, this VS Code extension is not limited to Azure. It is about everything. It can be used with Postgres open source, it can be used on-prem, it's useful for all instances of Postgres. I think even any cloud, is that correct?
SHIREESH: 00:52:15
Correct. Yeah, and absolutely. And we will keep it that way for sure. And we certainly really don't want it to be limited at all. We want all developers across the board to enjoy the benefits.
CLAIRE: 00:52:27
And Docker locally, I'm told. [That too.] Okay, so I have a random question for you. Once upon a time, one of our Postgres committers, David Rowley, was on the show, and we learned about how he got started as a developer and in Postgres and it had to do with a forklift and a cheese factory. And then people started coming to the show and saying, you know, I worked for a cheese company, or I did an internship that relates to Postgres and cheese. And so we started getting all these random cheese stories. I'm curious, does cheese have anything to do with your database journey?
SHIREESH: 00:53:05
No, I don't... I mean, I have to go back and think about it, but I don't think there's any database and cheese story. I love the metaphor for change from the Who Moved My Cheese book, and I guess I could connect it back to databases because that kind of changed my life. So there is a little bit of Who Moved My Cheese story in my journey of databases, but not really directly, I would say. I'm a cheddar guy.
CLAIRE: 00:53:32
I just had to ask. People get on my case when I don't ask. It's like an expectation now at the end of each episode. All right, I want to thank you so much, Shireesh, for joining us today. I've really enjoyed learning more about your background, all the way from when you were six years old and you wanted to be a bus driver, to the work that you do today. And also just thank you for supporting the Postgres open source community work that my team gets to do. I feel privileged to be able to do things like this podcast, or create POSETTE, or support all the Postgres community conferences with sponsorships and, you know, sending people there as speakers. There's a lot of stuff we do that wouldn't happen if you weren't so committed to the open source project. So thank you.
SHIREESH: 00:54:22
So, firstly, Claire, thank you so very much. And I want to thank each and everyone who's listening to this. I really appreciate your time, obviously love it, and thank you so very much. Just, again, I would repeat what I said about Postgres. It's one of those amazing, amazing databases, amazing community. We really love this community, and we are 100% committed to making sure that there is a great, agnostic, community for the sake, provisioning what we can, offering what we can, working closely with all the vendors, and that's the intent here to really take Postgres and make sure that it realizes its full potential. So I'm thrilled to be a part of this journey, in a small way.
CLAIRE: 00:55:12
Well thank you. Thank you to Shireesh Thota for joining us. And if you liked today's episode and you want to hear more of these Talking Postgres episodes, you should subscribe on Apple, or Spotify, or YouTube, or wherever you get your podcasts. And please tell your friends. And if you leave a review, that helps even more people discover the show. You can always get to past episodes and get links to subscribe on the different platforms at TalkingPostgres.com, and transcripts are included on the episode pages on TalkingPostgres.com too. And a big thank you to everybody who joined the live recording and participated in the live text chat on Discord. Thank you.
Welcome to Talking Postgres, a monthly podcast for developers who love this database. I'm your host, Claire Giordano, and in this podcast, we explore the human side of Postgres databases in open source, which means we delve into why do people who work with Postgres do what they do and how did they get there? Thank you to the team at Microsoft for sponsoring this community conversation. Today's guest, and I'm so excited, this is episode 29, is Shireesh Thota. Shireesh is the CVP for all the Azure databases at Microsoft. He's responsible for leading engineering and product management for databases, including Azure Cosmos DB, Azure SQL DB, and Microsoft SQL Server, MySQL, and of course, my favorite, my absolute favorite, Postgres. Shireesh has been working on databases either as a developer or a product leader or engineering leader since 2006. And in addition to working at Microsoft, Shireesh spent the better part of a year in like the 2022-2023 timeframe as SVP of engineering at SingleStore, working on a database that used to be, some of you might remember it as MemSQL. Welcome Shireesh.
SHIREESH: 00:01:23
Thank you, Claire. Really excited to be here today.
CLAIRE: 00:01:26
I am too. We started talking about this months and months ago. So I'm glad that we're here. Today's topic is titled How I Got Started Leading Database Teams. But the I is not Claire, the I is Shireesh in this case. And I think before we get focused on the leadership part, right? How you got started leading database teams. I'm really curious how you got started in tech at all. Can we go in the Wayback Machine and talk about that?
SHIREESH: 00:02:00
I'm happy to. So I've done my engineering in computer science. So I started right there. And then right after my computer science engineering, I did a brief internship at Oracle. So my database roots go all the way back to Oracle. And then it was just a quick few months. And then I started as a high availability engineer at Motorola. For those who don't know Motorola, this used to be a company and was acquired by Google. Motorola was a really big company that was basically into the embedded systems and it was trying to do wireless carrier software. So I started there, built a bunch of real-time operating systems code to do embedded packages for wireless carriers like Sprint, Verizon, etc. That was for one and a half years. Then I came to the United States to do my master's, again, in computer science. That was also... but it was mostly rooted in string algorithms, and I thought I was going to go into biotech. But I landed an internship at Microsoft, and then I spent almost 20 years at Microsoft ever since.
CLAIRE: 00:03:16
Wow. And what about then the transition from being an engineer to being a manager? How did that come about?
SHIREESH: 00:03:27
Yeah, you know, maybe I'll take a few minutes to talk about my journey at Microsoft, and then I'll touch upon your question, Claire, if that's okay.
CLAIRE: 00:03:32
Okay. Absolutely.
SHIREESH: 00:03:37
Yeah, so when I started at Microsoft, my first foray into Microsoft was basically being an intern in SQL Server. So I started working on Management Studio in SQL Server. It was very fascinating because what I was touching was impacting millions of developers, and it was touching so many important customers across the world. So it was super fascinating. I managed to build a tool that would compare two large databases. This was back in 2006.
CLAIRE: 00:04:08
Okay.
SHIREESH: 00:04:08
And then I loved the experience so much that I collapsed all my courses into one semester. I basically graduated in three semesters for my master's and came back and joined Microsoft full-time employee in the same team that I started. This was in SQL Server. So I spent around five years in SQL Server, contributed to major releases, 2008, 2008 R2, then a bunch of releases. And then I was the developer number one, effectively, for Cosmos DB. So I was there right from day one. Spent a lot of time in Cosmos DB, built various pieces, query engine indexing, elasticity, lots of things. And then I took over the entirety of engineering for Cosmos DB. And then ever since, I've been a manager. So to then answer your question about my transition, I definitely did not wake up one morning thinking that it would be fun to do one-on-ones, performance reviews, budget management, et cetera. It definitely was not the case.
CLAIRE: 00:05:07
T&E approvals, how about that?
SHIREESH: 00:05:12
I became the manager in the old-fashioned way. My manager at that time tapped me on the shoulder and said, hey, I think you are good with people. We need to scale. We were just five engineers on Cosmos DB back in 2012. We started in '11, and for the first one, two years, for two years, I think we were just five people. Around that time, he said, "We need to scale, we're going to hire a bunch of people. I need you to help me." I said yes, without fully reading the spec. Then there's a big contrast between the life as a developer and life as a manager. As a developer, it's binary. You have bugs, you have architectures that you need to go build, you have to fix bugs, you have to really design things. Success was measurable in commits, PRs, and just the amount of usage that you're seeing, et cetera. When you become a manager, you have to really understand that the job role, of course, changes significantly. It is not just about really going and fixing things anymore, but it is really about unblocking, aligning, and amplifying. My role changed massively in terms of that transition to not just be the problem solver myself, but to really make space for others to shine and to enable them to first and foremost build a great team. And those things did not come easily, of course. It takes time. And one of the most important things to remember, and at least the mistake that I have done, was that early on as I was transitioning into being a manager, I managed like how I coded, right? And that doesn't work. People are not functions. They're different, of course. They're all human beings with different aspirations. So you really need to connect the vision that we have with their aspirations. It takes time. And then...
CLAIRE: 00:07:14
Wait, can we pause on that for a second? [Yeah, yes, of course.] I managed like how I coded. Can you peel that onion and tell me more about what that means?
SHIREESH: 00:07:24
Yeah. So when you're coding, you basically think of a lot of pieces in an objective way. You basically think that these are the input metrics, these are the output metrics. You want to basically achieve a few things in terms of being quick, being precise. You want to think about resiliency, security, and you're acting as though the pieces are all obviously objective functions and without any emotions attached to it. And so you don't want to treat your people in that way. And that is a common mistake when most of the engineers who become managers the first time. There's no documentation on the people. You have to go poke them, understand what they are trying to really achieve, what their aspirations are. Unlike APIs, when you're trying to use them, you have a lot of well-defined interfaces. You really know how to use them. When will they go right? When will they go wrong? How to use them, how not to use them, how to deploy them in the right places, to then go build the architecture. You have a lot of objective mechanisms around it. You're effectively doing the same kind of, you're solving a similar kind of a problem if you think about it. There is an architecture to organization as well. Who needs to play in what position? Who needs to do what you want to do so that everything comes together, just like how a bunch of functions, a bunch of classes come together to make a component. So in that sense, they are similar, except people don't have documentation. You have to really poke. You have to spend a good amount of time coaching, learning what they really want to do. So learning them and figuring out how we really come together as a team to then achieve our vision and mission is a different ballgame. So if you apply the same mentality and the same thinking that you do when you are coding and building things technically, and I've seen managers do this quite often. I myself have done this and I failed at it. Yeah, that is really what I meant to say.
CLAIRE: 00:09:29
Okay, because sometimes I think about management as well, I don't know how old your kids are and you don't have to tell the world on the podcast but when you have teenagers a lot of times you you can't address an issue head-on, you kind of have to come at them sideways you know you have to understand like you said what are their motivations what are they trying to do and it's just different. Influencing people is hard.
SHIREESH: 00:09:54
Absolutely.
CLAIRE: 00:09:59
Hmm, you also started to talk about the organizational structure too, so there's managing people and all those challenges and then there's managing a larger organization and thinking about that hierarchy and that's probably, well that you probably didn't have to deal with that in your first management job, right?
SHIREESH: 00:10:17
Not, yeah, not then. It definitely took a while for me to get to that point to then having organizations, manager of managers, and now where I have a really large organization. So that's the second level of transition. And I wouldn't think of that as really, it's not a promotion, really. It's almost like a transformation where you are really looking at things in a bigger lens and you have to zoom out. You really have to think about how to shape the environment and the bigger mission so that there is a scale aspect that can thrive in that environment. And that is truly the key piece. And often people don't think about up and down. They may either think about up, meaning trying to align well with the mission of the broader organization, and then forget about how to cascade it down. Sometimes people do the opposite, which is that they basically go focus quite a bit in terms of making sure that their organization thrives, but they fail at connecting to the broader mission that their company or their organization on top has. So you really need to play this game in three pieces. One is, of course, managing up and aligning well. The second is to make sure that your team is set up to achieve those functions that your broader organization has. There's also a third piece where you have to laterally manage your engagement with your other teams. Now, this is, in some sense, connected to the first piece, which is going up, but it is an equally important piece of the puzzle. And that takes a while in terms of really trying to figure out how do you go from, you know, a small boat to a medium sized ship to a really big ship.
CLAIRE: 00:12:01
Yeah, and that managing, or networking, staying in touch, and in sync, and aligned with your peers which is what I think of when you talk about managing your engagement laterally, that's what you mean, right? [Exactly.] Other leaders of teams next to you. It's, I just feel like that's not documented well. Like a lot of people miss that in the beginning. And the thing is, I don't know why you think it's important to laterally manage other teams. So I should ask you that. But one of the things I've observed is that if you have a relationship with someone and maybe there's some trust or some background or some familiarity, then when there's a conflict, it's so much easier to resolve it versus if you haven't talked to them in nine months and you only see them in staff meetings and you don't really know each other then I think it's harder to resolve a conflict.
SHIREESH: 00:12:53
It's a super important part, Claire, and I'm really glad you brought this up. This is really what I call a social capital. You really can't succeed in the tech without social capital. And it comes across in multiple ways. And one of the reasons why I encourage people to have a little bit of a face time, we are, of course, a hybrid company at Microsoft, and I really love that, but once in a while, sort of getting that social capital is important because it gets burnt really fast. And it is really important to understand people. It need not be just face-to-face, but even otherwise. Again, as I said, people, unlike APIs, are not documented strictly. So you really have to go and poke and have to figure that out. And that's the only way to unblock most of the tougher, harder situations. And they come up every day.
CLAIRE: 00:13:43
How do you feel about, I know you talked about face time, right? And we are hybrid and I love that we're hybrid. I'm recording this from my home office today. I appreciate that about Microsoft tremendously, but how do you feel about the importance of like turning on video when you are having conversations with people and you're not in the same location? Is that something you do or does it not matter? Or do you have a philosophy on that?
SHIREESH: 00:14:12
So personally, I do that in every meeting that I am in. I rarely go off camera. I believe that it benefits me a lot because I sort of really want to express my emotions and how I'm thinking more viscerally, and so people can see me and understand what's happening and the body language does play a bigger role. So I definitely do that and I know that a lot of my managers and the people that I collaborate with do that as well and I really respect that. Having said that, we live in a very hybrid, very diverse world and so I understand absolutely that there are cases and situations where you really can't. We have to manage a lot of things in our personal lives. I know many of my reports who have to drop their kids sometimes when they're taking calls, and it's not convenient. I totally get that. So I'm very supportive of those situations. Just broadly speaking, though, I would love to sort of do more often. You don't have to do it every case. We need to have that flexibility. But I encourage people to really go, come on video, because there's a lot that you would say without speaking a single word, and it can't show up, right? When you are living in a hybrid world, I think that's important. So I, especially when we are talking to customers, I really encourage my team members to go and do that. I do that myself. I know my manager does that. Yeah, so I'm in the, you know, try and keep the camera as much as possible on. I'm in that camp.
CLAIRE: 00:15:50
I'm in that camp too, philosophically, but I'm not a morning person, and so for my 8:00, 8:30, even sometimes my 9:00 calls, I'm just not ready to be on camera. Anything after 10:00, my time, I'm on camera, no problem. But yeah, earlier in the morning, I just can't do it. So, but yeah, and then people are across time zones. So what's 10:00 for me might be 8:00 in the evening for somebody else. So that's always a complication. Okay, for anybody who's listening and maybe somebody who's a developer, has been a developer for years, but is trying to figure out their future career path and is wondering if management is a job that they would be good at or that would appeal to them. I'm curious if there are any other failures or surprises or big challenges that you had on that transition from being a developer to being a manager that are worth, I don't know, warning people about or sharing, sharing with people.
SHIREESH: 00:16:53
Yeah, I think the number one thing, as I said, is that when you are transitioning from an IC to being a manager, You don't want to manage people like how you manage code. That's really a huge warning sign, I would say. The second thing I would say is that a lot of times, one of the best ICs on the team tends to become the manager for that team. And when that happens, they basically inadvertently, without any intent really, compete with the people that they're managing. And that's just a really big red flag. You're really not there to compete with them. You're no more trying to shine against the people. You're really enabling the people. You have to be secure enough to be a manager, to know that your win is rooted in their win. And that thinking and that emotional mindset is extremely important. And you have to think about it every day when you're a manager. You're really here to make sure that you enable them. You make space for other people to shine. And ultimately, the goal is for the team to win. And we are not playing a single person sport. We are absolutely not playing tennis. We are playing soccer. So that imagination, that thinking, needs to be there when you're a manager. I would also say and warn people that if you really don't enjoy meetings and trying to really go from topic to topic, then it can get a little harder. Because when you're a manager, you don't necessarily sit in front of the terminal often and you don't have, you're typically in back-to-back meetings with no compile button, right? There's no compilation. There's no build going on here. So you need to ensure that you're comfortable with that. You also need to ensure or be comfortable with the fact that your job is not being the smartest person in the room. It is about learning from others. It's making sure that you really are amplifying with your judgment. You're unblocking. You have to focus on the transitions and the changes. But building people as a manager and then focusing on the vision to amplify and to sort of culturally navigate the teams, those are the job functionalities. And you are trying to take on a leadership role, a manager role. And you have to be comfortable with these things. And it's totally okay for somebody to say that I'm not going to enjoy this. I'm better off being an IC. And there most of the corporate companies, Microsoft for sure, enables these things today. And that's a great news. You can definitely go quite far being an IC. So yeah, these are a few topics that I would say people need to remember. Now, naturally, there's a lot of nuances, but these are a few things that I see many of the new managers need to take some time to reflect on.
CLAIRE: 00:19:50
Got it. Okay, so if we go back to the episode title, how I got started leading database teams, we've got the word database in there. And obviously, it looks like you've spent your entire career working on databases. You did not go into biotech, and so was there some aspect of databases or something that happened in that first Oracle internship or your first Microsoft internship? Was there a trigger for why you stayed in this space?
SHIREESH: 00:20:22
Yeah, so I was absolutely lucky to have gotten these opportunities to intern at some of the best places in terms of learning databases. When I was at SQL Server interning, and I obviously had the opportunity to talk to some of the stellar leaders who have made incredible contributions to SQL Server and to databases industry all up. What I've learned over the course of my time there, and obviously it kept building on me, was that databases are the microcosm of everything that's happening in computer science and just generally our technical industry. The reason why they're microcosm is because when you look at the stack for databases, you have to basically touch on every aspect of it. You have to start by looking into silicon. In fact, in our own databases organization, we look at what are all different possibilities to engage with hardware vendors, Intel, AMD, ARM vendors, etc., to look at what we can do to make sure that our databases run really well on the silicon. So you start there, and then you go up and look into algorithms, query engines, query optimizations, system engineering. You have to figure out how do you work well with the operating system constructs. There's a lot of runtime aspects to it. Algorithms, of course. There's a lot of database theory that you touch on. And then on and on, networking, of course, because we are building a lot of distributed systems. And so there's quite a lot of scale-out aspects in there. And then you can go all the way up to full stack. You have to really go build great developer experiences with drivers. You have to make sure that the best drivers, best way of managing your databases, is available. So when you look at the entire stack of databases, they really touch on everything that's there in the technical industry, most everything. And now with AI, of course, there's a lot of infusion of AI in databases in lots of different ways. We are thinking about how to do vector indexing. We are thinking about how to bring the best way to semantically interpret query results. You do see a lot of that in Postgres and across other databases as well. But I was lucky enough to get that insight and feel like this is the place where it would be a complete experience, a really consummate sort of understanding of our tech. And so I stuck with it and I kept loving it more and more. Yeah.
CLAIRE: 00:22:53
I think I mentioned this before that I was going to ask you this, and I don't know that you would remember, but when my kids were young, oftentimes you fill out these kind of templates that say, my favorite color is blue, and my favorite food is whatever it is, and my favorite thing to do is this. And there's usually a question, when I grow up, I want to be..., and I'm curious if you remember what your "when I grow up, I want to be" answer was?
SHIREESH: 00:23:25
That's a great question. I do remember. I think when I was, very early on, I wanted to be a bus driver because I thought steering a giant vehicle with the honks, etc., it looked like absolute power. And obviously, every kid, you know, obviously, probably this was one of the popular choices being a kid, sitting in front of the front seat and pulling the horn. That was the dream, I guess. And then later on, as I probably grew up a little bit, I started loving math. And so I knew that I was going to be an engineer or I wanted to be an engineer. What kind of an engineer? I wasn't sure about that part. But yeah, that was really how we got started. But pretty early on, I loved math. And so I knew of some of the folks who became engineers in and around me. And that appealed to me quite a bit. I did not touch my first computer until I was in my seventh grade, high school, I think. So it came very late. I learned BASIC first, and then I choose computer science thinking that this is really the... I loved it, of course. Early on in high school, when I started playing with simple programs, it just gave me the absolute power that I was dreaming, that I couldn't get sitting in front of the front seat in the bus. But I could get that sitting in front of the computer. It just transforms you into a different world, and I really loved every bit of it.
CLAIRE: 00:24:57
I mean, the metaphor of a bus driver almost works for your current job. [I guess, yes.] You're trying to make sure people get to where they're going, and there's all sorts of different kinds of people on the bus. I don't know. It sort of works. I don't know about the absolute power part of it, but you are steering a giant vehicle. [Thank you.] Okay. So, obviously, I know this but people listening might not know this, at Microsoft you are VP of engineering and product team responsible for all of our Azure database managed services, and some of the other database work that's going on as well, you know, Microsoft SQL Server is used on-prem, correct?
SHIREESH: 00:25:48
Yes, yes.
CLAIRE: 00:25:49
Okay, so it's not all and not only about Azure and cloud database services, but you have to work with lots of these different databases. Now, I have the luxury of getting to work with just one, which I think is pretty awesome for me. But I'm really curious what it's like to have that breadth and to span so many different technology stacks.
SHIREESH: 00:26:21
I'm grateful. I enjoy it. I'm very excited about having this opportunity every day. The breadth is definitely pretty big, but the themes are similar. Now, every database is different. Ultimately, yes, many of the applications could go and be ported into one other database, from one database to the other database. But I am a firm believer that there's no one database that can answer all the questions, and it's the best fit for every problem that you got. Generally, it doesn't happen that way. So these databases are tuned and perfected in certain different ways. So if you look at, you know, some are, obviously there are bigger level differences in terms of relational and non-relational, and we do have a flagship non-relational database in Cosmos DB. Outside of that, everything else is a relational database. Amongst the relational databases, we have both, you know, on-prem databases as well as cloud versions, managed services in cloud. Most of our databases are managed databases. SQL [Server] is the only one that we offer on-prem. And it's a very classic, it's a extremely successful battle-tested database for several decades. So they're all very different. And Postgres, of course, it's one of the most important open source databases that we got here. And I love having the opportunity to work across. And they all shine in different ways. If you think about Cosmos DB, it's designed to offer you low latency at global scale with a superior elasticity, single-digit millisecond guarantees for reads and writes worldwide. And it has some of the most amazing distributed systems characteristics. If you look at SQL Server, it brings deep, deep, deep enterprise features and rock-solid security characteristics with amazing performance characteristics. It's been there for several decades, and it continues to grow, and we are investing deeply into SQL Server. And it's the same engine that powers both on-prem as well as in the cloud. Postgres is phenomenal. Now, I've come to appreciate and love Postgres quite a bit in the past few years. It is open source at its best. I joke with everyone that it's the Linux of databases, and it's amazing to have such a community who's very principled and forward-looking, marry the best of relational algebra, and then sort of really attract the vast majority of the developer ecosystem as well as the enterprise community. So it's really a Swiss knife, I would say, Swiss Army knife of databases. So, yeah, and then MySQL as well. There's still quite a lot of MySQL community out there in terms of really running the commercial databases, web apps. It's really a privilege for me to have the breadth and being involved in all these different databases.
CLAIRE: 00:29:17
Yeah, but you've got to have to do some pretty dramatic context switching during the day. Although, maybe if you know, you're so familiar with all the different stacks and all the different people, maybe the context switching isn't hard. Is it hard?
SHIREESH: 00:29:35
It's hard and easy, in cases where, you know, so obviously relational algebra is same no matter where you go. All the databases have the same kind of challenges in some sense. But they're optimized in different ways. So, yes, it's similar. So I know the stack, and I'm not really switching too much across the board. Non-relational database, Cosmos DB is a little different, but I know I've had the opportunity to build it from the day one. So I know Cosmos DB quite a bit, so that helps me. It is often the organizational architecture, the business challenges, how do we incorporate different pieces, how do we go to market with all these different offerings, and how do we enable customers, provide them the right choice. Those are the places where it gets tricky. So yeah, it becomes harder in those places. But we have a very good suite of database offerings where we enable the choice for the customer. So it's a win-win.
CLAIRE: 00:30:35
Okay. So Affan Dar, who works for you and was a previous guest on this podcast, we'll try to include the link to his episode in the show notes, he wanted me to be sure to ask you, what is your favorite database and why?
SHIREESH: 00:30:54
So I don't know if it's Affan, apparently the guest from the previous episode also wanted to be a bus driver. So I don't know if it was Affan, but I love Affan, so great question. And like any responsible parent, I would... I know the answer, but I wouldn't say it publicly, so...
CLAIRE: 00:31:17
Wait, you're not allowed to have favorites, you love all your children equally, is that the deal?
SHIREESH: 00:31:21
Yeah, absolutely. Yeah. You know, I have to keep it that way, unfortunately. But, you know, having said that, as I said, every one of these databases is just amazing. They have different strengths. We believe that there is a need to have this choice. You don't want to have 24 different databases, but there are a few databases in terms of how they're optimized. There are special cases where some databases are designed in a different way. Cosmos DB is built to have scale and high availability in its core DNA, right? And so it is going to be great when you want to have a distributed system challenges. SQL is designed to have that great hybrid characteristics both on premises as well as in the cloud. It is rooted in being a very strong general purpose database, there are a lot of SMP workloads, classic OLTP workloads, very security rich offerings in SQL, so if you're looking for that kind of a database for tier zeros, yes, SQL is a great choice. And Postgres, one of the greatest things about Postgres is that it's good across the spectrum, both on the developer front as well as on the enterprise front. And as you know, and as everybody knows, the ecosystem, the developer ecosystem, is rooted around Postgres significantly. As AI applications continue to mushroom, I think this is going to be one of the most amazing things for Postgres. So it's just designed for the AI era, in my opinion. And the amount of extensibility that Postgres brings, that's just going to be a huge advantage. So, yeah, I mean, I would say the same thing, that different databases are great at different things. I love all my children, and it's a privilege to have this opportunity.
CLAIRE: 00:33:13
Okay, you know, Affan is going to give you a hard time. And you know that I really wanted you to say that Postgres is your favorite database.
SHIREESH: 00:33:19
I will buy him ice cream.
CLAIRE: 00:33:25
Okay. All right, so there's a really good question on the chat from Tristan Partin about, whether, what your perspective is on whether Postgres can learn things from other database projects you've been involved in.
SHIREESH: 00:33:40
That's a really good question. So I think one of the most amazing things about Postgres is that it is extensible. It's super extensible and there's lots of contributions across the board. So naturally, that's just going to play to its strengths. I would also say that that sometimes becomes one of the challenges for Postgres. Just in terms of the pace at which you want to make big architectural choices and to get it done. And, you know, this is not a critique or any such thing against the way that the community works. I love it. Absolutely love it. Just zero doubts. There's no ifs and buts there. It is truly the strength, but if you want to really look into how to make some big architectural changes, that end-to-end thinking and how do we bring all pieces together really quickly, make bigger changes faster, is an area that's going to, it's a natural sort of like a balance problem that we need to get better at. I think this is going to be an evolution. Not a concern, but it is one of those things where I think as Postgres evolves and it's continuing to become one of the most sought after relational databases in the history of our tech, that is one area where it needs to learn how to get good at that, trying to take on bigger challenges.
CLAIRE: 00:35:00
So I want to make sure I understood what you said. Did you basically, I'll try to paraphrase you, did you basically just say that the extensibility of Postgres, which is a big plus, you know, in many ways, also creates complexity that can make it hard to make big architectural changes? Is that what you said?
SHIREESH: 00:35:20
Correct. Yeah, a few weeks ago, Marco Slot, from Snowflake now, wrote this blog about the complexity of extensibilities. And I was looking at it, and it really spoke to the challenges that I was thinking that Postgres has to deal with it. It's the same thing that is such a great thing about Postgres can also become a challenge. And that is the part that I think we need to navigate as a community in terms of how do we make sure that, you know, we continue to keep the good things but not let it create a huge amount of complexity. I would also add, in addition to that, just the challenge of building bigger changes. Obviously, the community has been debating about things such as moving to threads for connections. Those are the kind of changes that Postgres community has to figure out how do we really rally and make changes like that faster. Obviously, the AI era is going to create a significant amount of demand for Postgres. which is awesome. It is certainly really designed for the AI era. But these changes are going to be, these challenges need to be confronted.
CLAIRE: 00:36:38
The Marco Slot post that you're talking about, [Yes.] was that based on the paper that just got published? I think Abigale Kim from UW–Madison was the lead author and Andy Pavlo was a co-author as well, and David Anderson, and Marco. And it was called something like Anarchy in the Database: A Survey and Evaluation of Database Management System Extensibility. Is it that?
SHIREESH: 00:37:05
I think this is at the datacon. Is it at the datacon? [Oh.] The new... yeah, there was a conversation, that was a Bay Area datacon, I think. I'll find out the link and send it. It was basically talking about the do's and the don'ts of extensibilities and the challenges that come with it.
CLAIRE: 00:37:23
Okay, I'll dig that one up and add it to the show notes then. Cool. Thank you.
SHIREESH: 00:37:25
Yeah. But the paper that you're referring to is a good one too. It's a good one about the Anarchy in the Databases.
CLAIRE: 00:37:33
Well, and also about extensibility and the challenges with them, so I just thought that was the connection.
SHIREESH: 00:37:40
Right. I'm pretty sure there's a lot of cross references there.
CLAIRE: 00:37:42
Okay. Got it, yeah because he'd already worked on the paper by the time he put together that datacon talk. [That must have been the case. Yes.] Okay, all right, so we talked a little bit about your your work leading all these databases and obviously Microsoft SQL Server is on-prem, many of them are managed cloud services, you know, like the Azure Cosmos DB, Azure Database for PostgreSQL, etc. But one of the things that I really want everybody who listens to the show to know is that, at Microsoft, we have a team of people whose primary job is to contribute to the Postgres open source project. And some people don't realize that team exists. And so I always like to kind of shine a light on them because I think they're doing really important work. And I think it's important that Microsoft be, I mean, we have our managed service, but our managed service builds on top of Postgres open source. So it's kind of, to be a good citizen, I think we need to be contributing to the upstream open source project. And the good news is we are, which is cool. This is a very long question, I know. But I'm curious to hear from your perspective, like why do you fund this team? Why does this team exist? And why does this work matter?
SHIREESH: 00:39:04
So, absolutely. You know, a lot of people are indeed surprised when they find out that Microsoft has a team of engineers to contribute directly to the Postgres open source project. I think increasingly people are learning and hopefully it's not a surprise anymore. It is not a side gig. These are folks who are core committers. They do the real deal. They're participating in community. They're writing code patches, extensions, and it's a full whole nine yards. Why do we do it? It's simple because Postgres matters. It's not just to us, but to the entire developer ecosystem. We have the vision of basically going to offer a world-class managed Postgres experience in Azure. And so we just can't be consumers. We have to be contributors when you have such a vision. And so we've created this dedicated team. They're not designed to basically assist us in just running our managed service. This is designed, the team is designed, to significantly improve, just push the whole core idea of Postgres forward independent of what it means to Microsoft alone. This is purely to help the project and to make sure that the whole community benefits from it. And every vendor gets benefited and we collaborate with every other vendor as well. Whoever wants to participate in the community, we are trying to make sure that we offer the best that we have to push this awesome project. And when you run a cloud service at scale like Azure Database for PostgreSQL, you do, of course, inevitably hit edge cases, performance tuning scenarios, and features that need to push the limit. Our goal is to not just duct tape around them, but we want to give it back, make changes and give it back upstream. I think that that's the only sustainable way to improve the core of Postgres, which then benefits us and everyone else. That's kind of the mind shift here. If you think about Microsoft in general, it's true that we did not operate in this way always. But today, thanks to our new operating structure, our cultural transformation, et cetera, we are one of the biggest contributors to open source, just broadly speaking, not just Postgres. But this Postgres team, it's a reflection of that transformation and is perhaps a really good project, a really good example, and demonstrates the new Microsoft, I would say. And, you know, again, this is really what makes Microsoft great. We adapt and we are here to play our part in the open source community in the right way. And we love the Postgres community. So this team is designed specifically to really push that vision forward. And that's it. That's really it. It's simple.
CLAIRE: 00:42:08
One of the statements that I sometimes make is that if we want, we at Microsoft want, Postgres to continue to be technically relevant and commercially relevant in the future, then it means we need to do our part to contribute to the open source project. And then, you know when, I talk to a lot of people about this because I find it interesting, and it also is tangentially related to my job, right? And some people will be like, well, but if Microsoft walked away, everybody else would still be contributing and it wouldn't, it would be okay, right? Like, I get that question. And maybe it's from people who like to play devil's advocate or just people who like to debate, you know, or be provocative. And I don't think anybody can just assume that a successful project today will be successful in five years. I think you have to keep putting in the work. And there is a lot of work involved in every single new release of Postgres, and all those quarterly patch releases, and a ton of work behind the scenes as well, beyond the code itself, right, to make the project run. So I'm really glad we're doing this, I guess.
SHIREESH: 00:43:23
I completely agree. You really said it well. Absolutely.
CLAIRE: 00:43:27
Okay, so let's pivot for a second. I imagine that you meet with lots of customers. And for developers who work on Postgres, are there any insights, things that you hear from customers all the time in the context of Postgres, for example, or even databases more generally? Are there things that you think developers should keep in mind?
SHIREESH: 00:43:54
So, it's a great question. And developers and customers just across the board, they all have, they have a lot of clarity in terms of what they want from databases. So I always tell my team and I strongly believe that databases are really the stars that basically enable applications to shine. We are very happy to sort of like stay out of the limelight, but enable the applications to shine, and the app developers to really win. Ultimate goal for databases is to make sure that the developers can forget about databases. They need not really even think about them. Of course, that's an extreme statement. But my point is that the database app developers should be able to get what they need in their frameworks, tool chains. And then databases are always up. They're always available. And they're giving the performance guarantees in the way that the app needs. Making sure that there's cost efficiency as well. There are all these different tensions that you need to get. Performance, availability, cost governance. You think of these three as like the tensions that go against each other in some sense, but that is the trick. And so when you really talk to the customers, it depends on the flavor of the application that they are dealing with. There are a lot of mission-critical applications who are not as cost-sensitive, but they are certainly, they want to make sure that they can run the Postgres database, or any database in this case. They don't want surprises during upgrades. They want to have fewer knobs. They want to have better observability. And critically, the uptime is pretty high, and they can trust that their workloads won't break when we are scaling or when we are really doing any maintenance work, et cetera, on Postgres. So these are a few things that they care a lot more than features, right? So you really have to remember that it is one of those ironic things when we may be chasing quite a lot of features, but customers are thinking about foundational pieces, resiliency, security, foremost than anything else. So those are really some of the things that I run into whenever I talk to customers. And Postgres, I hear when I talk to Postgres customers that they love Postgres, but they wish that they didn't have to be a Postgres expert to use it well. And that's the challenge, and the opportunity, right? So if you can make Postgres powerful by design, and simple by default, then you unlock a whole new generation of developers who can bear with it, not fearing it, and then take it to enterprise scale. We are certainly seeing the uprise of Postgres going from the mid-market to sort of enterprises and then slowly making it into tier zero kind of applications. And along this curve, we're going to have to deal with these kinds of tensions. And that is kind of really the trick here, the customers. And it's also interesting when you move from on-premises to cloud, because it takes away a lot of their pain. But you need to do it in a way that it doesn't look like a black box. They need to have observability, they need to make sure that there is predictability without having to break their bank. So that empathy for the operator, the developer, the workload architect, that is what they are seeking. And it comes up loud and clear whenever I talk to these customers. Yeah, so I think I probably covered quite a lot of ground here, but these are a few things that come to my mind when I think about talking to customers.
CLAIRE: 00:47:32
You did cover a lot of ground and I love your answer. And there's like five different directions I could pivot from. The one thing, and this is just kind of random, but I want to point out that you use the phrase "it depends." [Right.] because when you were talking about those mission critical customers, right, and the fact that some people care more about cost governance and other people care more about availability for example, and anyway, I just think it's, amusing is the wrong word to describe the fact that the phrase "it depends" shows up so much in conversations about databases, and trade-offs... [It's a very good point.]
SHIREESH: 00:48:13
It's a very good point because that's, any complex system, anything that basically deals with various aspects of state, it has to behave this way and it It has to be, it depends, because unfortunately, there's no one architecture, one answer, one set of choices that is universally applicable for all applications. And hence, it depends.
CLAIRE: 00:48:43
And maybe that's part of why, you know, at Microsoft, you're responsible for several different databases, right? Because, in fact, as much as we, those of us who work with Postgres, there's this phrase called "just use Postgres" that suggests that you can use Postgres for pretty much any situation. But in fact, right, there is room for in the world for multiple different databases. [100%.] And we're not the only ones.
SHIREESH: 00:49:08
100%. But the one great thing about Postgres, though, which I definitely acknowledge and love to give the credit where it's due, is, again, going back to the extensibility aspect of it and really the flavor of the communities coming together, adding so many pieces without having to really make it as a matrix of things. Most of the database architectures are generally matrix where you touch something, it kind of connects into something else. And that sort of is a challenge because you really can't scale that way. But Postgres has mechanisms where you could create your own sort of chain of extensibilities without having to connect to every other piece, and that's quite powerful.
CLAIRE: 00:49:55
So, there is a, well I was going to say a question, but it's really more of a comment, on the chat about the new VS Code extension for Postgres. So first of all, I'm thrilled that somebody brought it up. And this is not a plant. Tristan Partin is the one who brought it up, and he specifically said that he would love to see the new Postgres VS Code extension be open sourced. And so I'm curious if you have any thoughts on that.
SHIREESH: 00:50:23
Yeah, so firstly, I really love the fact that the VS Code extension is one of those things that kind of took off really well. We put in a lot of effort here, so kudos to the team who worked on this. It came out really well, and I'm really thrilled that it helps not just Microsoft developers, but all the developers, anyone who wants to use Postgres, because VS Code is kind of really the dominant IDE. So this extension should really be very helpful for all the app developers, anyone who is a Postgres developer. So thrilled to hear that. And then on the interest about really open sourcing this, I know the team is evaluating it. They're looking into it. Our intent is to make sure that the community really contributes here, loves it, et cetera. So we certainly are thinking in that direction. Affan and Charles, who run the engineering and the product, they are thinking through it. So you'll hear a lot more about it in the coming few weeks and months about this. So I don't have a specific answer to give right now. But we are certainly thinking in that direction.
CLAIRE: 00:51:27
The other comment on the chat that I really like is that VS Code needed a good, or a great, Postgres extension. And I couldn't agree more. It felt like a neglected space. And so I'm really excited about this thing too.
SHIREESH: 00:51:43
I totally, totally agree and love the comments for sure. And really, yeah, it's heartwarming to see the adoption.
CLAIRE: 00:51:52
Yeah, and for anyone who's listening, just to point out, this VS Code extension is not limited to Azure. It is about everything. It can be used with Postgres open source, it can be used on-prem, it's useful for all instances of Postgres. I think even any cloud, is that correct?
SHIREESH: 00:52:15
Correct. Yeah, and absolutely. And we will keep it that way for sure. And we certainly really don't want it to be limited at all. We want all developers across the board to enjoy the benefits.
CLAIRE: 00:52:27
And Docker locally, I'm told. [That too.] Okay, so I have a random question for you. Once upon a time, one of our Postgres committers, David Rowley, was on the show, and we learned about how he got started as a developer and in Postgres and it had to do with a forklift and a cheese factory. And then people started coming to the show and saying, you know, I worked for a cheese company, or I did an internship that relates to Postgres and cheese. And so we started getting all these random cheese stories. I'm curious, does cheese have anything to do with your database journey?
SHIREESH: 00:53:05
No, I don't... I mean, I have to go back and think about it, but I don't think there's any database and cheese story. I love the metaphor for change from the Who Moved My Cheese book, and I guess I could connect it back to databases because that kind of changed my life. So there is a little bit of Who Moved My Cheese story in my journey of databases, but not really directly, I would say. I'm a cheddar guy.
CLAIRE: 00:53:32
I just had to ask. People get on my case when I don't ask. It's like an expectation now at the end of each episode. All right, I want to thank you so much, Shireesh, for joining us today. I've really enjoyed learning more about your background, all the way from when you were six years old and you wanted to be a bus driver, to the work that you do today. And also just thank you for supporting the Postgres open source community work that my team gets to do. I feel privileged to be able to do things like this podcast, or create POSETTE, or support all the Postgres community conferences with sponsorships and, you know, sending people there as speakers. There's a lot of stuff we do that wouldn't happen if you weren't so committed to the open source project. So thank you.
SHIREESH: 00:54:22
So, firstly, Claire, thank you so very much. And I want to thank each and everyone who's listening to this. I really appreciate your time, obviously love it, and thank you so very much. Just, again, I would repeat what I said about Postgres. It's one of those amazing, amazing databases, amazing community. We really love this community, and we are 100% committed to making sure that there is a great, agnostic, community for the sake, provisioning what we can, offering what we can, working closely with all the vendors, and that's the intent here to really take Postgres and make sure that it realizes its full potential. So I'm thrilled to be a part of this journey, in a small way.
CLAIRE: 00:55:12
Well thank you. Thank you to Shireesh Thota for joining us. And if you liked today's episode and you want to hear more of these Talking Postgres episodes, you should subscribe on Apple, or Spotify, or YouTube, or wherever you get your podcasts. And please tell your friends. And if you leave a review, that helps even more people discover the show. You can always get to past episodes and get links to subscribe on the different platforms at TalkingPostgres.com, and transcripts are included on the episode pages on TalkingPostgres.com too. And a big thank you to everybody who joined the live recording and participated in the live text chat on Discord. Thank you.
