1 00:00:00,001 --> 00:00:02,000 [CLAIRE] Welcome to Talking Postgres. 2 00:00:02,000 --> 00:00:04,720 In this podcast, we explore the human side of Postgres, 3 00:00:04,720 --> 00:00:08,520 databases, and open source, for the target audience 4 00:00:08,520 --> 00:00:13,120 of developers who want to hear from other Postgres community 5 00:00:13,120 --> 00:00:13,800 members. 6 00:00:13,800 --> 00:00:16,120 I want to say thank you to the team at Microsoft 7 00:00:16,120 --> 00:00:18,760 for sponsoring the community conversation about Postgres. 8 00:00:18,760 --> 00:00:23,360 And I am so pleased to be your host, Claire Giordano. 9 00:00:23,360 --> 00:00:27,040 I would like to introduce Affan Dar, who is our guest today. 10 00:00:27,040 --> 00:00:31,440 Affan started his career as an embedded software engineer. 11 00:00:31,440 --> 00:00:34,440 After studying computer science, he worked at Microsoft, 12 00:00:34,440 --> 00:00:38,200 at Zynga, at Meta, and now he's back at Microsoft again. 13 00:00:38,200 --> 00:00:40,760 He has worked as both an individual contributor 14 00:00:40,760 --> 00:00:44,000 and technical lead, as well as an engineering manager. 15 00:00:44,000 --> 00:00:46,720 And he switched back and forth between these roles 16 00:00:46,720 --> 00:00:48,640 a few times during his career. 17 00:00:48,640 --> 00:00:50,600 Currently, Affan is Vice President 18 00:00:50,600 --> 00:00:53,160 of the Postgres team, the Postgres engineering 19 00:00:53,160 --> 00:00:55,600 team, at Microsoft. 20 00:00:55,600 --> 00:00:57,400 Welcome, Affan. 21 00:00:57,400 --> 00:00:58,680 [AFFAN] Hey, good morning, Claire, 22 00:00:58,680 --> 00:01:01,120 and thanks for having me on the podcast. 23 00:01:01,120 --> 00:01:03,960 [CLAIRE] I am so glad that you're here to join us. 24 00:01:03,960 --> 00:01:04,440 All right. 25 00:01:04,440 --> 00:01:05,200 So let's dive in. 26 00:01:05,200 --> 00:01:07,840 Today's topic, the title of the episode, 27 00:01:07,840 --> 00:01:11,640 is Leading Engineering for Postgres on Azure. 28 00:01:11,640 --> 00:01:15,480 And I guess maybe a good place to start is today, 29 00:01:15,480 --> 00:01:18,200 and before we go back in time, and forwards in time. 30 00:01:18,200 --> 00:01:21,480 But let's just talk about what's the scope of your job 31 00:01:21,480 --> 00:01:25,400 as VP of Postgres engineering at Microsoft? 32 00:01:25,400 --> 00:01:26,560 [AFFAN] Right, yeah. 33 00:01:26,560 --> 00:01:29,720 Well, I mean, in this role, I manage 34 00:01:29,720 --> 00:01:34,320 three distinct but very related engineering teams. 35 00:01:34,320 --> 00:01:37,960 Firstly, there's a team that builds and runs the Azure 36 00:01:37,960 --> 00:01:39,960 Postgres services that we offer. 37 00:01:39,960 --> 00:01:42,320 It's a Flexible Server, Postgres, 38 00:01:42,320 --> 00:01:43,720 and then the single server Postgres, 39 00:01:43,720 --> 00:01:45,800 which we're deprecating. 40 00:01:45,800 --> 00:01:47,600 Secondly, there's a team that continues 41 00:01:47,600 --> 00:01:51,160 to work on open source projects that 42 00:01:51,160 --> 00:01:57,120 include Citus and PgBouncer and Patroni and so on and so forth. 43 00:01:57,120 --> 00:01:59,560 And then there's a third team that makes contributions 44 00:01:59,560 --> 00:02:00,840 to upstream Postgres. 45 00:02:00,840 --> 00:02:05,720 So this team has a group of committers and contributors. 46 00:02:05,720 --> 00:02:09,280 So in terms of scope of my specific role, 47 00:02:09,280 --> 00:02:11,920 these are all pretty smart engineers and product managers. 48 00:02:11,920 --> 00:02:14,960 So my main goal is to just make sure, 49 00:02:14,960 --> 00:02:17,440 my and my product management counterpart peer, 50 00:02:17,440 --> 00:02:23,440 our goal is to make sure that they have clear vision, strategy, 51 00:02:23,440 --> 00:02:26,680 and they're set up for success, and then just to mainly stay 52 00:02:26,680 --> 00:02:33,320 out of the way of these very smart people. 53 00:02:33,320 --> 00:02:37,240 [CLAIRE] And just to get people listening who might be unfamiliar, 54 00:02:37,240 --> 00:02:38,840 when you talk about flexible server, 55 00:02:38,840 --> 00:02:41,400 you're talking about the Azure Database for PostgreSQL managed 56 00:02:41,400 --> 00:02:42,920 service, right? 57 00:02:42,920 --> 00:02:44,360 [AFFAN] Correct, yes, exactly. 58 00:02:44,440 --> 00:02:48,560 Yes, Azure Database for PostgreSQL - Flexible Server. 59 00:02:48,560 --> 00:02:52,520 [CLAIRE] OK, so the managed service, the extensions 60 00:02:52,520 --> 00:02:54,440 and other open source projects, as well as 61 00:02:54,440 --> 00:02:57,640 the upstream Postgres open source work [That is correct]. 62 00:02:57,640 --> 00:03:01,680 And I put the kind of work that my team does, 63 00:03:01,680 --> 00:03:07,080 where we focus on open source contributions, but not code, 64 00:03:07,080 --> 00:03:11,520 we focus on things like this podcast or the POSETTE event 65 00:03:11,520 --> 00:03:13,600 in that third bucket too. 66 00:03:13,600 --> 00:03:17,040 Even though I don't technically report into your org, 67 00:03:17,040 --> 00:03:21,280 that's kind of, I don't know, where my connections are. 68 00:03:21,280 --> 00:03:24,160 [AFFAN] Yeah, it's definitely a very, very critical function 69 00:03:24,160 --> 00:03:26,320 that we have, definitely. 70 00:03:26,320 --> 00:03:32,720 I think generally our stance on Postgres open source 71 00:03:32,720 --> 00:03:37,720 is that we want to make Postgres a successful database, which 72 00:03:37,720 --> 00:03:39,920 includes many different things we need to do. 73 00:03:39,920 --> 00:03:42,400 Number one is contributing to the open source 74 00:03:42,400 --> 00:03:45,440 aspects of Postgres, but also contributing 75 00:03:45,440 --> 00:03:48,880 to the open source extensions that build 76 00:03:48,880 --> 00:03:50,520 the ecosystem of Postgres. 77 00:03:50,520 --> 00:03:52,960 But also the things that you're just mentioning, 78 00:03:52,960 --> 00:03:56,920 the role that you and your team play in our groups, 79 00:03:56,920 --> 00:03:59,440 which is basically promoting Postgres, 80 00:03:59,440 --> 00:04:03,520 supporting all the activities, 81 00:04:03,520 --> 00:04:06,600 building all of the content that you build out. 82 00:04:06,600 --> 00:04:08,180 So I think that's a very important part 83 00:04:08,180 --> 00:04:12,580 of what our collective team does as well at Microsoft. 84 00:04:12,580 --> 00:04:14,860 [CLAIRE] So do you ever meet people or run 85 00:04:14,860 --> 00:04:16,740 into people who are surprised that there's 86 00:04:16,740 --> 00:04:20,740 a Postgres team at Microsoft? 87 00:04:20,740 --> 00:04:22,540 [AFFAN] Well, yes. 88 00:04:22,540 --> 00:04:25,300 There's always an elephant in the room, which 89 00:04:25,300 --> 00:04:28,620 is that Microsoft does have, 90 00:04:28,620 --> 00:04:31,220 we do have, our own proprietary database called SQL Server, 91 00:04:31,220 --> 00:04:33,860 which people would obviously know about, 92 00:04:33,860 --> 00:04:36,420 which is incredibly successful also. 93 00:04:36,420 --> 00:04:40,380 So oftentimes, we do get, actually 94 00:04:40,380 --> 00:04:43,940 we used to get this a lot more in the last, 95 00:04:43,940 --> 00:04:47,540 about a few years ago, lately in the last couple of years, 96 00:04:47,540 --> 00:04:50,380 since we started actually making good contributions 97 00:04:50,380 --> 00:04:50,980 to Postgres. 98 00:04:50,980 --> 00:04:53,260 And again, the great work that your team has done also, 99 00:04:53,260 --> 00:04:56,700 Claire, this has become less and less of a discussion point. 100 00:04:56,700 --> 00:04:58,780 Everybody kind of now assumes that Microsoft 101 00:04:58,780 --> 00:05:01,940 does do Postgres as well. 102 00:05:01,940 --> 00:05:09,020 But yeah, certainly, there has been some kind of, 103 00:05:09,020 --> 00:05:10,860 not struggle, but some kind of effort 104 00:05:10,860 --> 00:05:13,660 that we had to make to kind of make sure 105 00:05:13,660 --> 00:05:15,020 that people understand that, 106 00:05:15,020 --> 00:05:17,340 customers understand that, we are very, very serious 107 00:05:17,340 --> 00:05:21,020 about Postgres in that. 108 00:05:21,020 --> 00:05:23,580 [CLAIRE] So what does it mean to be serious about Postgres? 109 00:05:23,580 --> 00:05:28,460 So why, I suppose I know why I care about Postgres, 110 00:05:28,460 --> 00:05:30,900 but why does Microsoft care about Postgres? 111 00:05:30,900 --> 00:05:33,700 What is the strategy and that vision 112 00:05:33,700 --> 00:05:36,220 that guides you and your team? 113 00:05:36,220 --> 00:05:39,060 [AFFAN] Right, yeah, I think there are a couple of things here. 114 00:05:39,060 --> 00:05:42,820 Number one is that, obviously we, again, as I mentioned, 115 00:05:42,820 --> 00:05:46,620 we do have SQL Server, which is doing very well. 116 00:05:46,620 --> 00:05:50,180 But we have had a lot of demand signal from customers 117 00:05:50,180 --> 00:05:52,820 on supporting open source databases, 118 00:05:52,820 --> 00:05:54,060 like MySQL and Postgres. 119 00:05:54,060 --> 00:05:56,060 And this happened quite a few years ago, 120 00:05:56,060 --> 00:05:58,340 and which is why... Microsoft is a platform, 121 00:05:58,340 --> 00:06:02,260 we build products at multiple layers. 122 00:06:02,260 --> 00:06:05,060 We have Azure infrastructure. 123 00:06:05,060 --> 00:06:06,660 We build IaaS. 124 00:06:06,660 --> 00:06:09,500 We supply IaaS services to our customers. 125 00:06:09,500 --> 00:06:12,220 We supply PaaS services to our customers also. 126 00:06:12,220 --> 00:06:13,940 We build databases. 127 00:06:13,940 --> 00:06:15,340 We also run databases. 128 00:06:15,340 --> 00:06:18,540 So basically, Microsoft's goal, or Azure's goal as a whole, 129 00:06:18,540 --> 00:06:21,940 is to be the computer for the world. 130 00:06:21,940 --> 00:06:25,980 It's the world's computer, is what Satya kind of called us. 131 00:06:25,980 --> 00:06:27,660 And part of being the world's computer 132 00:06:27,660 --> 00:06:29,260 is to be able to run every application, 133 00:06:29,260 --> 00:06:32,460 whether it be a very top to bottom proprietary, 134 00:06:32,460 --> 00:06:36,060 hey, Microsoft built everything from soup to nuts, 135 00:06:36,060 --> 00:06:39,260 or it is an open source database like Postgres and MySQL 136 00:06:39,260 --> 00:06:42,660 that we pull in and kind of run as a managed service. 137 00:06:42,660 --> 00:06:43,940 So it is important. 138 00:06:43,940 --> 00:06:46,740 It is important for the completeness of the platform. 139 00:06:46,740 --> 00:06:51,700 And also, customers actually have asked us for supporting this. 140 00:06:51,700 --> 00:06:53,220 And customers have their own reasons. 141 00:06:53,220 --> 00:06:59,700 Sometimes they want, vendor lockin has been a big concern, 142 00:06:59,700 --> 00:07:03,180 which is why I think this has become a thing. 143 00:07:03,180 --> 00:07:07,100 So I think, getting back to your question specifically, 144 00:07:07,100 --> 00:07:09,980 I think it is the completeness of the platform and the offering. 145 00:07:09,980 --> 00:07:10,940 We have demand here. 146 00:07:10,940 --> 00:07:14,420 We will support it. 147 00:07:14,420 --> 00:07:15,540 [CLAIRE] OK. 148 00:07:15,540 --> 00:07:20,660 So you joined this team, 149 00:07:20,660 --> 00:07:22,500 I don't know, I want to go back in time now 150 00:07:22,500 --> 00:07:26,340 and talk about how did you get into engineering management. 151 00:07:26,340 --> 00:07:29,180 You started life as an embedded systems engineer. 152 00:07:29,180 --> 00:07:30,340 Is that right? 153 00:07:30,340 --> 00:07:30,980 [AFFAN] Yes. 154 00:07:30,980 --> 00:07:31,780 Yes, that's correct. 155 00:07:31,780 --> 00:07:34,700 It's a long time ago, Claire. 156 00:07:34,700 --> 00:07:37,940 [CLAIRE] Why embedded systems? 157 00:07:37,940 --> 00:07:43,500 [AFFAN] So I was an electrical engineering major from college. 158 00:07:43,500 --> 00:07:48,260 So I think that was a wrong career for me. 159 00:07:48,260 --> 00:07:51,860 So I did not see myself as an electrical engineer. 160 00:07:51,860 --> 00:07:56,060 So I had more of an aptitude for computer science. 161 00:07:56,060 --> 00:08:00,340 So when I was looking around, and a role which 162 00:08:00,340 --> 00:08:02,540 kind of married the two, 163 00:08:02,540 --> 00:08:07,860 my professional ambitions plus my academic experience, 164 00:08:07,860 --> 00:08:09,780 embedded engineering, software engineering 165 00:08:09,780 --> 00:08:10,820 seemed to be a good fit. 166 00:08:10,820 --> 00:08:16,420 So I ended up writing a bunch of code for, 167 00:08:16,420 --> 00:08:18,820 gosh, it was so long ago, 168 00:08:18,820 --> 00:08:22,260 I think it was MPEG-1 encoders and decoders, 169 00:08:22,260 --> 00:08:28,700 H.263 encoders, decoders, for the Philips TriMedia processor, 170 00:08:28,700 --> 00:08:31,540 which was something that I don't think even exists 171 00:08:31,540 --> 00:08:33,940 on the internet now. 172 00:08:33,940 --> 00:08:35,300 So yeah, it was fun. 173 00:08:35,300 --> 00:08:35,860 It was fun. 174 00:08:35,860 --> 00:08:38,460 I think it was like, 175 00:08:38,460 --> 00:08:44,500 it got me to a very good start in computer science. 176 00:08:44,500 --> 00:08:48,620 So yeah, it was a long time ago. 177 00:08:48,620 --> 00:08:51,460 [CLAIRE] Was open source on your radar or something 178 00:08:51,460 --> 00:08:54,380 that you worked with, either in academia 179 00:08:54,380 --> 00:08:56,700 or when you were first getting started, 180 00:08:56,700 --> 00:08:58,340 in embedded systems engineering? 181 00:08:58,340 --> 00:09:00,420 Or did that come later? 182 00:09:00,420 --> 00:09:01,780 [AFFAN] Yeah, that came later. 183 00:09:01,780 --> 00:09:05,020 I think my experience with open source is interesting. 184 00:09:05,020 --> 00:09:07,500 So the first time I developed with open source 185 00:09:07,500 --> 00:09:12,900 was when I worked on this project called the Durable Task 186 00:09:12,900 --> 00:09:16,900 Framework, which is a workflow engine, basically, that we-- 187 00:09:16,900 --> 00:09:17,460 [CLAIRE] What was it? 188 00:09:17,460 --> 00:09:18,620 Can you say it again? 189 00:09:18,620 --> 00:09:22,700 [AFFAN] Durable Task Framework. [OK, got it] 190 00:09:22,700 --> 00:09:23,340 Yeah. 191 00:09:23,340 --> 00:09:28,140 So that actually was something we created in a hackathon, 192 00:09:28,140 --> 00:09:30,740 me and a friend of mine, a colleague of mine. 193 00:09:30,740 --> 00:09:33,060 And we were excited about it. 194 00:09:33,060 --> 00:09:38,460 So we open sourced it back in 2015, I would like to say. 195 00:09:38,460 --> 00:09:42,380 And we use it pretty regularly within our teams at Microsoft. 196 00:09:42,380 --> 00:09:47,380 And it turned out to be a pretty interesting piece of tech. 197 00:09:47,380 --> 00:09:51,380 That there were companies built on top of this, 198 00:09:51,380 --> 00:09:54,020 not on this specific framework, but companies 199 00:09:54,020 --> 00:09:57,460 built on top of the same idea later. 200 00:09:57,460 --> 00:10:01,420 So that was my first experience doing open source. 201 00:10:01,420 --> 00:10:05,180 But my second stint with open source 202 00:10:05,180 --> 00:10:07,460 was when I was working in Meta. 203 00:10:07,460 --> 00:10:12,220 And I was leading the team which built and ran 204 00:10:12,220 --> 00:10:16,260 the social graph database, which was all based on MySQL 205 00:10:16,260 --> 00:10:18,540 at Facebook. 206 00:10:18,540 --> 00:10:20,180 So yeah, that was MySQL. 207 00:10:20,180 --> 00:10:24,500 So I actually had a pretty interesting set of experiences 208 00:10:24,500 --> 00:10:26,100 in MySQL as well. 209 00:10:26,100 --> 00:10:27,420 Lasted about 3 and 1/2 years. 210 00:10:27,420 --> 00:10:30,740 And then I came back to Microsoft doing Postgres. 211 00:10:30,740 --> 00:10:32,180 So interesting experiences. 212 00:10:32,180 --> 00:10:35,300 I've built projects that went open source. 213 00:10:35,300 --> 00:10:40,580 And then I worked on MySQL and Postgres. 214 00:10:40,580 --> 00:10:42,980 [CLAIRE] And then I know as we were getting ready for the podcast, 215 00:10:42,980 --> 00:10:45,420 you told me that you had switched back and forth 216 00:10:45,420 --> 00:10:48,900 a few times between management positions 217 00:10:48,900 --> 00:10:51,180 and individual contributor positions. 218 00:10:51,180 --> 00:10:56,380 And I think that those decisions about whether to switch gears 219 00:10:56,380 --> 00:10:58,300 and solve different kinds of problems, 220 00:10:58,300 --> 00:11:00,300 you're still problem solving as a manager, 221 00:11:00,300 --> 00:11:04,740 but it's not the same as being a pure engineer. 222 00:11:04,740 --> 00:11:07,620 And so why did you make those switches? 223 00:11:07,620 --> 00:11:10,100 And how did you make those decisions too? 224 00:11:10,100 --> 00:11:11,620 Because that is something I've seen 225 00:11:11,620 --> 00:11:14,260 so many people struggle with. 226 00:11:14,260 --> 00:11:18,340 [AFFAN] Yeah, I think the first switch I made was from an IC 227 00:11:18,340 --> 00:11:22,100 to a manager was back in 2007 or 2008. 228 00:11:22,100 --> 00:11:26,260 And that was an untimely switch. 229 00:11:26,260 --> 00:11:30,860 I think in hindsight, this was not the right decision. 230 00:11:30,860 --> 00:11:31,740 I was not, 231 00:11:31,740 --> 00:11:35,380 I mean, my general recommendation 232 00:11:35,380 --> 00:11:39,500 to other engineers also who want to go the path of management 233 00:11:39,500 --> 00:11:44,620 is get some good set of experiences as an IC 234 00:11:44,620 --> 00:11:47,220 under your belt, because that's very 235 00:11:47,220 --> 00:11:50,540 important in being a very effective engineering manager. 236 00:11:50,540 --> 00:11:52,060 You need to know what's going on. 237 00:11:52,060 --> 00:11:55,500 So the first time I became a manager, I was not, 238 00:11:55,500 --> 00:11:58,580 I don't think I had done, 239 00:11:58,580 --> 00:12:02,540 I was not sufficiently technically grounded. 240 00:12:02,540 --> 00:12:04,620 And I'd not had the sort of experiences 241 00:12:04,620 --> 00:12:08,500 that you should have had when you become an EM. 242 00:12:08,500 --> 00:12:12,500 So that made me a bit uncomfortable as a manager. 243 00:12:12,500 --> 00:12:13,540 I wanted to know more. 244 00:12:13,540 --> 00:12:15,740 I wanted to kind of understand 245 00:12:15,740 --> 00:12:17,060 in depth what's going on. 246 00:12:17,060 --> 00:12:19,580 And it was just something that, 247 00:12:19,580 --> 00:12:21,540 actually, I just missed coding, basically. 248 00:12:21,540 --> 00:12:22,540 It was too early for me. 249 00:12:22,540 --> 00:12:23,540 So I went back. 250 00:12:23,540 --> 00:12:28,820 I went back into a IC role, coding, architecture, design, 251 00:12:28,820 --> 00:12:31,900 and technical leadership, and things like that. 252 00:12:31,900 --> 00:12:35,540 But at some point in your career also, 253 00:12:35,540 --> 00:12:42,180 it's that you just want to have an even more outsized impact. 254 00:12:42,180 --> 00:12:46,460 And at a certain point, I think the way to do that is also, 255 00:12:46,460 --> 00:12:48,820 I mean, obviously, as an IC, you can 256 00:12:48,820 --> 00:12:52,980 become a technical lead for a very large project as well. 257 00:12:52,980 --> 00:12:56,700 But for me, the path was more management, more coaching, 258 00:12:56,700 --> 00:12:57,220 mentoring. 259 00:12:57,220 --> 00:12:59,180 So the second time I became a manager 260 00:12:59,180 --> 00:13:03,660 was when I figured that to make more impact, 261 00:13:03,660 --> 00:13:07,300 I had to kind of drive a group of people 262 00:13:07,300 --> 00:13:09,340 instead of just myself. 263 00:13:09,340 --> 00:13:11,620 So that was my second stint. 264 00:13:11,620 --> 00:13:13,980 Again, people have different paths. 265 00:13:13,980 --> 00:13:18,620 Some ICs are incredibly good at leading very large projects. 266 00:13:18,620 --> 00:13:20,860 So that's, if that's the path, then that's the path. 267 00:13:20,860 --> 00:13:23,260 But for me, the path was management. 268 00:13:23,260 --> 00:13:28,140 So yeah, and it was not easy. 269 00:13:28,140 --> 00:13:30,420 Becoming a manager, I think, requires a mindset 270 00:13:30,420 --> 00:13:34,860 that you have to let go of things that you hold near 271 00:13:34,860 --> 00:13:36,980 and dear to your heart, like what's 272 00:13:36,980 --> 00:13:38,460 happening in this component, what's 273 00:13:38,460 --> 00:13:40,500 happening in this line of code, things like that. 274 00:13:40,500 --> 00:13:45,620 But I think that was the key for me, letting go and treating 275 00:13:45,620 --> 00:13:49,420 the team not as an extension of my own coding, 276 00:13:49,420 --> 00:13:55,580 but as a disaggregated, decentralized group of people 277 00:13:55,580 --> 00:13:58,940 who can take up a task and then fully deliver on it 278 00:13:58,940 --> 00:14:01,340 and without me having to know everything 279 00:14:01,340 --> 00:14:04,460 about that particular thing. 280 00:14:04,460 --> 00:14:07,860 [CLAIRE] And oftentimes, come up with solutions that surprise you, 281 00:14:07,860 --> 00:14:09,020 I would expect. 282 00:14:09,020 --> 00:14:11,100 Like, that's the cool thing about letting go. 283 00:14:11,100 --> 00:14:12,420 And I know it's hard to let go. 284 00:14:12,420 --> 00:14:14,340 I still struggle with that sometimes. 285 00:14:14,340 --> 00:14:21,140 But when you do, people do amazing things. [Exactly] 286 00:14:21,140 --> 00:14:24,020 That I think, oh, I wouldn't have thought of that. 287 00:14:24,020 --> 00:14:24,540 [AFFAN] Yeah. 288 00:14:24,540 --> 00:14:31,700 I think, again, the realization that I think I also got 289 00:14:31,700 --> 00:14:33,980 was interesting. 290 00:14:33,980 --> 00:14:37,060 Like, it was a very eye-opening event in my career 291 00:14:37,060 --> 00:14:40,260 where I went to, 292 00:14:40,260 --> 00:14:41,980 somebody was explaining to me something. 293 00:14:41,980 --> 00:14:45,340 This very, very super, super good IC engineer 294 00:14:45,340 --> 00:14:47,820 who was going over, like, there was some issue 295 00:14:47,820 --> 00:14:50,140 and he was explaining to me that, "hey, this, this, this, 296 00:14:50,140 --> 00:14:50,780 this, this." 297 00:14:50,780 --> 00:14:52,900 And I told him that, oh, I didn't know that. 298 00:14:52,900 --> 00:14:55,940 And he said, "Affan, there's a lot of things you don't know." 299 00:14:55,940 --> 00:14:58,100 And that, I mean, he was joking. 300 00:14:58,100 --> 00:15:00,940 But that really stuck to me, like, oh, my god, 301 00:15:00,940 --> 00:15:02,380 this guy is so correct. 302 00:15:02,380 --> 00:15:03,820 There's so many things I don't know 303 00:15:03,820 --> 00:15:05,460 and so many things I don't have to know 304 00:15:05,460 --> 00:15:08,580 because there's so many smart people around us that, 305 00:15:08,580 --> 00:15:10,900 who are smarter than you as well. 306 00:15:10,900 --> 00:15:15,180 And so you just need to figure out 307 00:15:15,180 --> 00:15:19,220 how to get into a situation where you can trust them 308 00:15:19,220 --> 00:15:20,380 and then just do, 309 00:15:20,380 --> 00:15:22,580 just checkpoint. 310 00:15:22,580 --> 00:15:26,460 But that was, I think, the key opening, the eye opener for me. 311 00:15:26,460 --> 00:15:29,140 "Affan, there's a lot of things you don't know." 312 00:15:29,140 --> 00:15:31,420 [CLAIRE] Well, I think trust is a really interesting thing 313 00:15:31,420 --> 00:15:34,460 because I feel like people, 314 00:15:34,460 --> 00:15:36,900 and this isn't true of everybody, of course, 315 00:15:36,900 --> 00:15:39,220 I have to be careful not to stereotype. 316 00:15:39,220 --> 00:15:41,940 But I feel like people do some of their best work 317 00:15:41,940 --> 00:15:44,820 when they're feeling trusted, when 318 00:15:44,820 --> 00:15:46,660 they feel like their boss has their back, 319 00:15:46,660 --> 00:15:48,380 when their boss understands them. 320 00:15:48,380 --> 00:15:51,780 And so I'm just curious if you have any, 321 00:15:51,780 --> 00:15:54,940 I don't know, perspectives on how do you make 322 00:15:54,940 --> 00:15:56,700 your team feel trusted? 323 00:15:56,700 --> 00:16:00,580 [AFFAN] Yeah, I think my mental model, again, it's not 324 00:16:00,580 --> 00:16:01,980 like I'm doing it perfectly, 325 00:16:01,980 --> 00:16:06,260 but my mental model is just to assume that my manager does 326 00:16:06,260 --> 00:16:07,900 the same thing to me. 327 00:16:07,900 --> 00:16:09,860 He has the same conversation with me. 328 00:16:09,860 --> 00:16:11,580 How would I feel? 329 00:16:11,580 --> 00:16:15,460 And that has helped me make some decisions very easily. 330 00:16:15,460 --> 00:16:18,940 For example, if there's a project that is not 331 00:16:18,940 --> 00:16:22,380 doing super well, or there's some issues there, 332 00:16:22,380 --> 00:16:25,900 then should I come in and start micromanaging it? 333 00:16:25,900 --> 00:16:27,060 Should I do something else? 334 00:16:27,060 --> 00:16:28,460 Should I do coaching and what not? 335 00:16:28,460 --> 00:16:30,540 And then I just put myself in, 336 00:16:30,540 --> 00:16:32,180 I just assume that I'm the person 337 00:16:32,180 --> 00:16:35,180 and my manager is talking to me. 338 00:16:35,180 --> 00:16:38,460 And that really helps ground me. 339 00:16:38,460 --> 00:16:40,620 All these things I don't want my manager to say. 340 00:16:40,620 --> 00:16:45,620 And so I think that has been very useful on that. 341 00:16:45,620 --> 00:16:48,340 But generally, I think trusting people 342 00:16:48,340 --> 00:16:50,660 and just having a good frequency of checkpointing them 343 00:16:50,660 --> 00:16:54,100 and actually coaching them, I think, always goes a long way. 344 00:16:54,100 --> 00:16:55,620 People, when they feel empowered, 345 00:16:55,620 --> 00:16:57,900 again, no surprise, people, when they feel empowered, 346 00:16:57,900 --> 00:16:59,380 they do their best work. 347 00:16:59,380 --> 00:17:02,620 Micromanaging or not empowering people 348 00:17:02,620 --> 00:17:06,340 actually is very stressful for the manager as well as 349 00:17:06,340 --> 00:17:07,700 the person, obviously. 350 00:17:07,700 --> 00:17:09,580 And also, the system does not work. 351 00:17:09,580 --> 00:17:12,100 The system, you cannot scale out like that. 352 00:17:12,100 --> 00:17:15,500 So if you are interested in growing your scope as a manager 353 00:17:15,500 --> 00:17:17,300 or as a leader, not even a manager, 354 00:17:17,300 --> 00:17:20,660 even as a technical leader, it's very important 355 00:17:20,660 --> 00:17:24,700 to figure out, have the right people in the right spots, 356 00:17:24,700 --> 00:17:28,980 and then empower them and just let them be. 357 00:17:28,980 --> 00:17:30,300 [CLAIRE] Makes sense. 358 00:17:30,300 --> 00:17:34,340 OK, let's switch gears back to your current job 359 00:17:34,340 --> 00:17:38,460 at Microsoft, head of Postgres engineering. 360 00:17:38,460 --> 00:17:41,780 What keeps you up at night? 361 00:17:41,780 --> 00:17:43,020 Is it too soon to ask that? 362 00:17:43,020 --> 00:17:46,580 Do I need to wait till later in the conversation? 363 00:17:46,580 --> 00:17:48,020 [AFFAN] No, not many things. 364 00:17:48,020 --> 00:17:51,060 I sleep like a baby most of the time. 365 00:17:51,060 --> 00:17:52,740 [CLAIRE] Oh, that's good. 366 00:17:52,740 --> 00:17:54,140 [AFFAN] But you have to do that. 367 00:17:54,140 --> 00:17:57,740 I mean, you've got to have a little bit of a thick skin 368 00:17:57,740 --> 00:18:03,380 for high-stress jobs, like what we do in databases. 369 00:18:03,380 --> 00:18:05,620 But if I were to pick something, it's 370 00:18:05,620 --> 00:18:11,580 probably that Azure Postgres is running 371 00:18:11,580 --> 00:18:14,220 a lot of mission-critical workloads for customers 372 00:18:14,220 --> 00:18:16,420 and just want to make sure they're behaving properly. 373 00:18:16,420 --> 00:18:21,020 So I would be lying if I said that I don't sometimes wake up 374 00:18:21,020 --> 00:18:22,980 and look at a few health dashboards here and there 375 00:18:22,980 --> 00:18:24,220 and just make sure things are working, 376 00:18:24,220 --> 00:18:26,060 look at the live site and incidents. 377 00:18:26,060 --> 00:18:27,780 [CLAIRE] In the middle of the night. 378 00:18:27,780 --> 00:18:30,140 [AFFAN] Yeah, I mean, yeah. 379 00:18:30,140 --> 00:18:33,900 It's a good, yeah, again, I said I would be lying if I said 380 00:18:33,900 --> 00:18:34,700 I don't do that. 381 00:18:34,700 --> 00:18:36,380 But mostly it's good. 382 00:18:36,380 --> 00:18:40,020 Again, the team is great. 383 00:18:40,020 --> 00:18:41,180 Postgres is awesome. 384 00:18:41,180 --> 00:18:42,460 So things just work out. 385 00:18:42,460 --> 00:18:45,860 But it's definitely a little bit stressful, 386 00:18:45,860 --> 00:18:51,260 just understanding the impact of what Postgres has on, 387 00:18:51,260 --> 00:18:54,380 I think everybody would relate to that. 388 00:18:54,380 --> 00:18:56,660 Postgres needs to be rock solid. 389 00:18:56,660 --> 00:19:00,380 A lot of things will not work properly if Postgres did not. 390 00:19:00,380 --> 00:19:05,020 So I think that's what, I guess, keeps me up at night sometimes. 391 00:19:05,020 --> 00:19:06,940 [CLAIRE] Boriss Mejías in the chat is commenting 392 00:19:06,940 --> 00:19:08,980 that the expression "sleep like a baby" just 393 00:19:08,980 --> 00:19:10,300 doesn't make sense. 394 00:19:10,300 --> 00:19:12,460 So many babies wake up so many times 395 00:19:12,460 --> 00:19:14,300 in the middle of the night. [100%] 396 00:19:14,300 --> 00:19:17,900 But I think you meant that you sleep really, really well. 397 00:19:17,900 --> 00:19:19,500 [AFFAN] I sleep like a log, how's that? 398 00:19:19,500 --> 00:19:20,300 [CLAIRE] OK, that's better. 399 00:19:20,300 --> 00:19:21,220 I like that one. 400 00:19:21,220 --> 00:19:22,220 OK. 401 00:19:22,220 --> 00:19:23,660 Well, it's interesting that you say 402 00:19:23,660 --> 00:19:26,140 that when you do wake up in the middle of the night, which 403 00:19:26,140 --> 00:19:28,860 I understand is rare, that you might occasionally 404 00:19:28,860 --> 00:19:31,140 look at the health dashboards. 405 00:19:31,140 --> 00:19:33,540 And that just reinforces how important 406 00:19:33,540 --> 00:19:40,180 it is for Postgres to have good monitoring and notifications, 407 00:19:40,180 --> 00:19:43,740 alerts, metrics, observability, all of the above. 408 00:19:43,740 --> 00:19:44,820 [AFFAN] Exactly. 409 00:19:44,820 --> 00:19:47,260 I think there's a lot of interesting things 410 00:19:47,260 --> 00:19:49,420 that have come up from that. 411 00:19:49,420 --> 00:19:53,820 Like, again, manageability, monitoring, self-healing, 412 00:19:53,820 --> 00:19:56,340 ability to diagnose, enough tooling for customers 413 00:19:56,340 --> 00:19:59,140 to be able to diagnose problems if they run into them, 414 00:19:59,140 --> 00:20:02,180 workload problems, specifically, if they run into them 415 00:20:02,180 --> 00:20:06,980 themselves, making people more reliant on their own skills. 416 00:20:06,980 --> 00:20:10,340 I think that has been super important. 417 00:20:10,340 --> 00:20:13,460 I think these are challenges every big cloud 418 00:20:13,460 --> 00:20:17,740 vendor would have in this. 419 00:20:17,740 --> 00:20:20,220 [CLAIRE] Well, so that leads into, are there 420 00:20:20,220 --> 00:20:22,260 database challenges with Postgres, 421 00:20:22,260 --> 00:20:24,500 or I suppose other relational databases, 422 00:20:24,500 --> 00:20:27,260 that are unique to hyperscalers? 423 00:20:27,260 --> 00:20:30,820 Running all of these workloads for all of these customers, 424 00:20:30,820 --> 00:20:32,740 obviously, we're not the only big hyperscaler. 425 00:20:32,740 --> 00:20:34,820 But are there things that we have to think 426 00:20:34,820 --> 00:20:40,340 about within the Azure team? 427 00:20:40,340 --> 00:20:45,980 [AFFAN] I think it's probably going to be mostly around manageability 428 00:20:45,980 --> 00:20:48,180 at scale, I would say. 429 00:20:48,180 --> 00:20:52,700 With the fleet sizes that these large cloud vendors have, 430 00:20:52,700 --> 00:20:55,380 I think it is important to be able to run or manage 431 00:20:55,380 --> 00:20:57,140 these servers efficiently. 432 00:20:57,140 --> 00:21:00,380 But it has to be done with the right controls for security 433 00:21:00,380 --> 00:21:02,220 and privacy in mind. 434 00:21:02,220 --> 00:21:03,940 We can't peek inside the workload. 435 00:21:03,940 --> 00:21:06,620 We can't mess with anything that the customers are, 436 00:21:06,620 --> 00:21:07,780 with the customer workload. 437 00:21:07,780 --> 00:21:11,180 So how do we manage systems efficiently and make sure 438 00:21:11,180 --> 00:21:13,740 that they're running as effectively as possible 439 00:21:13,740 --> 00:21:15,020 with all these constraints? 440 00:21:15,020 --> 00:21:17,420 So basically, a lot of this comes down 441 00:21:17,420 --> 00:21:20,660 to what I was saying just before this, 442 00:21:20,660 --> 00:21:23,460 that they have to have all the diagnostics and tooling 443 00:21:23,460 --> 00:21:27,180 to figure out solutions by themselves. 444 00:21:27,180 --> 00:21:30,380 The other interesting point is that some of these databases, 445 00:21:30,380 --> 00:21:32,500 and I have experience with MySQL also on this one, 446 00:21:32,500 --> 00:21:34,620 some of these databases are not really 447 00:21:34,620 --> 00:21:38,100 built with cloud scale in mind, which is fine. 448 00:21:38,100 --> 00:21:40,220 I think which is what the nature of this beast is. 449 00:21:40,220 --> 00:21:46,900 But it oftentimes makes it hard for us to run this at scale 450 00:21:46,900 --> 00:21:47,580 efficiently. 451 00:21:47,580 --> 00:21:51,020 So the key thing with these large vendors like us, 452 00:21:51,020 --> 00:21:53,620 like Azure, is that we want to be 453 00:21:53,620 --> 00:21:55,660 able to leverage economy at scale. 454 00:21:55,660 --> 00:21:58,660 And we want to pass on the cost savings to the customers. 455 00:21:58,660 --> 00:22:01,420 So how do we securely and performantly 456 00:22:01,420 --> 00:22:05,260 leverage common infrastructure for running these servers? 457 00:22:05,260 --> 00:22:06,700 So for example, many cloud vendors 458 00:22:06,700 --> 00:22:08,980 have disaggregated the storage and compute. 459 00:22:08,980 --> 00:22:11,300 And they have gone for a shared storage model 460 00:22:11,300 --> 00:22:15,100 and potentially, in some cases, shared compute also. 461 00:22:15,100 --> 00:22:19,340 Does the database support disaggregating storage 462 00:22:19,340 --> 00:22:23,100 and compute and all of these things easily? 463 00:22:23,100 --> 00:22:27,100 Or is it an uphill battle for the database? 464 00:22:27,100 --> 00:22:28,940 And Postgres is a fantastic database, 465 00:22:28,940 --> 00:22:31,100 as evidenced by its success. 466 00:22:31,100 --> 00:22:33,340 But there's certainly some room for improvement in all 467 00:22:33,340 --> 00:22:34,860 of these aspects, I believe. 468 00:22:34,860 --> 00:22:38,140 I don't know. 469 00:22:38,140 --> 00:22:40,980 Better interfaces for storage, improvements 470 00:22:40,980 --> 00:22:44,500 to the security model potentially. 471 00:22:44,500 --> 00:22:48,340 So really, for example, 472 00:22:48,340 --> 00:22:50,540 we're a service operator. 473 00:22:50,540 --> 00:22:54,940 So we'd love to have some notion of a service operator, 474 00:22:54,940 --> 00:22:57,820 some security model improvements that can help us build a service 475 00:22:57,820 --> 00:22:59,540 operator kind of role so we can securely 476 00:22:59,540 --> 00:23:03,140 manage the databases without, again, getting more access 477 00:23:03,140 --> 00:23:04,340 to the data itself. 478 00:23:04,340 --> 00:23:06,220 So some thinking could be done there. 479 00:23:06,220 --> 00:23:08,940 So a bunch of these challenges are thought upfront 480 00:23:08,940 --> 00:23:11,740 when you have a cloud-first database. 481 00:23:11,740 --> 00:23:14,620 But these things, I think, kind of lag in some 482 00:23:14,620 --> 00:23:17,500 of these open source databases. 483 00:23:17,500 --> 00:23:19,460 So yeah. 484 00:23:19,460 --> 00:23:21,020 And there might be a few more things. 485 00:23:21,020 --> 00:23:27,260 But this is what I think our challenge has been so far. 486 00:23:27,260 --> 00:23:28,540 [CLAIRE] OK. 487 00:23:28,540 --> 00:23:31,620 One of the questions on the chat from Adam Wølk 488 00:23:31,620 --> 00:23:35,860 is whether working on a managed service that's 489 00:23:35,860 --> 00:23:39,140 based on an open source project, do you ever 490 00:23:39,140 --> 00:23:43,740 feel constrained as a leader where the upstream open source 491 00:23:43,740 --> 00:23:49,300 project might decide to not accept changes or patches 492 00:23:49,300 --> 00:23:52,420 and where that could be an issue or an impact 493 00:23:52,420 --> 00:23:55,020 or could hold back the managed service? 494 00:23:55,020 --> 00:23:58,060 Is that something that's on your mind ever? 495 00:23:58,060 --> 00:24:01,940 [AFFAN] Yeah, I think it's a balance. 496 00:24:01,940 --> 00:24:03,620 I think at the end of the day, it's 497 00:24:03,620 --> 00:24:06,700 all like we're all solving customer problems. 498 00:24:06,700 --> 00:24:12,140 If a customer has a problem x and if the upstream Postgres 499 00:24:12,140 --> 00:24:16,700 doesn't have enough controls for solving the problem x, 500 00:24:16,700 --> 00:24:18,020 then we have a few options. 501 00:24:18,020 --> 00:24:20,740 Number one is that we could, 502 00:24:20,740 --> 00:24:23,780 obviously, we can build the control plane around it. 503 00:24:23,780 --> 00:24:27,020 We can use the database in a way where it solves that problem. 504 00:24:27,020 --> 00:24:30,180 Or number two is that we could lean into and see 505 00:24:30,180 --> 00:24:32,700 if there's an extension that could solve that problem, which 506 00:24:32,700 --> 00:24:33,780 is a great thing about Postgres. 507 00:24:33,780 --> 00:24:35,100 Postgres is good at extensions. 508 00:24:35,100 --> 00:24:37,260 So I think that's a great thing. 509 00:24:37,260 --> 00:24:38,540 The extension is not available? 510 00:24:38,540 --> 00:24:41,060 Can we build an extension that can solve that problem? 511 00:24:41,060 --> 00:24:45,140 That's another interesting aspect. 512 00:24:45,140 --> 00:24:48,540 If even that is not possible, then can we, 513 00:24:48,540 --> 00:24:53,540 then is there something that is applicable to upstream as well? 514 00:24:53,540 --> 00:24:56,700 Would it help everyone in the community and industry 515 00:24:56,700 --> 00:24:57,980 to solve that problem? 516 00:24:57,980 --> 00:25:02,740 If the answer is yes, then definitely we do push on that. 517 00:25:02,740 --> 00:25:08,100 But in cases where the priorities do not align 518 00:25:08,100 --> 00:25:09,700 and we still have to solve the problem, 519 00:25:09,700 --> 00:25:12,500 then we obviously have the option 520 00:25:12,500 --> 00:25:17,540 of creating a fork with the intention of figuring out 521 00:25:17,540 --> 00:25:23,700 over time how to contribute this back to the community as well. 522 00:25:23,700 --> 00:25:25,900 But we always try to keep that as a minimum, 523 00:25:25,900 --> 00:25:30,860 because I think our goal is to be as true to Postgres 524 00:25:30,860 --> 00:25:32,340 upstream as possible. 525 00:25:32,340 --> 00:25:34,580 It has all kinds of benefits. 526 00:25:34,580 --> 00:25:38,420 The benefits of vendor lock-in that customers do not want, 527 00:25:38,420 --> 00:25:39,940 I think-- 528 00:25:39,940 --> 00:25:44,580 [CLAIRE] The benefits of vendor lock-in, that's like an oxymoron. 529 00:25:44,580 --> 00:25:46,660 [AFFAN] The benefits of not having vendor lock-in, 530 00:25:46,660 --> 00:25:49,380 the benefits of not having vendor lock-in is only, 531 00:25:49,380 --> 00:25:51,820 maybe the triple negative that I'm trying to pull off here, 532 00:25:51,820 --> 00:25:54,060 Claire. 533 00:25:54,060 --> 00:25:56,700 Yeah, so that, and then also the fact 534 00:25:56,700 --> 00:25:59,460 that if we have any changes that are not upstream, 535 00:25:59,460 --> 00:26:02,420 then our rebase time, our time to snap 536 00:26:02,420 --> 00:26:04,580 to the latest and greatest version of Postgres minor 537 00:26:04,580 --> 00:26:06,540 and major versions is higher. 538 00:26:06,540 --> 00:26:10,500 So it's in our interest to have it upstream. 539 00:26:10,500 --> 00:26:14,860 If all else fails, then we investigate things. 540 00:26:14,860 --> 00:26:17,220 For example, maybe we can, 541 00:26:17,220 --> 00:26:18,700 maybe its extensibility point. 542 00:26:18,700 --> 00:26:22,020 Can we still do an extension with the minor addition 543 00:26:22,020 --> 00:26:23,700 to the extensibility of Postgres? 544 00:26:23,700 --> 00:26:26,860 How can we minimize the amount of work 545 00:26:26,860 --> 00:26:29,820 that needs to be done in that one? 546 00:26:29,820 --> 00:26:33,460 So it's not like, oh, it's not going to be taken, 547 00:26:33,460 --> 00:26:34,660 so let's not do it. 548 00:26:34,660 --> 00:26:35,980 I think it's a whole gradient. 549 00:26:35,980 --> 00:26:39,940 It's a whole spectrum of all the way from extensions, 550 00:26:39,940 --> 00:26:42,580 to control plane, to a bunch of other controls that we have. 551 00:26:42,580 --> 00:26:45,980 But our main thrust is always that we 552 00:26:45,980 --> 00:26:49,500 want to upstream any and all interesting changes that 553 00:26:49,500 --> 00:26:51,100 will benefit everyone. 554 00:26:51,100 --> 00:26:54,900 Postgres is a huge pie. 555 00:26:54,900 --> 00:26:58,540 We love to contribute to open source as it 556 00:26:58,540 --> 00:27:02,300 goes, hopefully, in our commitments and our 557 00:27:02,300 --> 00:27:05,580 contribution over the last few releases. 558 00:27:05,580 --> 00:27:07,460 [CLAIRE] So anybody who's a regular listener 559 00:27:07,460 --> 00:27:10,300 knows that I got my start in Postgres 560 00:27:10,300 --> 00:27:12,500 when I joined Citus Data. 561 00:27:12,500 --> 00:27:15,460 And I worked on the Citus open source extension. 562 00:27:15,460 --> 00:27:17,460 But as I learned more and more about Postgres, 563 00:27:17,460 --> 00:27:20,020 I remain convinced, and I'm not the only person who 564 00:27:20,020 --> 00:27:23,580 thinks this, that part of the health and vibrancy 565 00:27:23,580 --> 00:27:25,660 of the whole Postgres ecosystem is 566 00:27:25,660 --> 00:27:28,500 enabled by this ability to create these runtime 567 00:27:28,500 --> 00:27:34,980 extensions and that ability to, "Hey, I need this feature. 568 00:27:34,980 --> 00:27:37,140 It can be a small thing, right?" 569 00:27:37,140 --> 00:27:38,540 I need this capability. 570 00:27:38,540 --> 00:27:40,940 It's not in Postgres today. 571 00:27:40,940 --> 00:27:44,860 But that ability to add that shim and tack that on 572 00:27:44,860 --> 00:27:49,220 and create that new thing, whether it's pg_cron, 573 00:27:49,220 --> 00:27:52,140 or whatever it is, is so powerful. 574 00:27:52,140 --> 00:27:56,220 And I think it's led to a lot of innovation and problem solving 575 00:27:56,220 --> 00:28:00,460 and has made Postgres better and better. 576 00:28:00,460 --> 00:28:01,820 So that's my bias. 577 00:28:01,820 --> 00:28:03,780 [AFFAN] And Claire, I think to your point also, 578 00:28:03,780 --> 00:28:05,980 just to add to that, for example, pgvector, 579 00:28:05,980 --> 00:28:07,980 great example. 580 00:28:07,980 --> 00:28:11,620 I think Postgres led all of the other relational databases 581 00:28:11,620 --> 00:28:13,940 in terms of vector support because there 582 00:28:13,940 --> 00:28:15,820 happened to be a pgvector extension that 583 00:28:15,820 --> 00:28:17,300 was already there. 584 00:28:17,300 --> 00:28:23,300 And would pgvector have made it in the open source 585 00:28:23,300 --> 00:28:26,660 if it was not an extensibility point that was available? 586 00:28:26,660 --> 00:28:27,380 I don't know. 587 00:28:27,380 --> 00:28:29,100 I don't, maybe, I don't think so. 588 00:28:29,100 --> 00:28:31,860 Maybe I don't know what list of priorities 589 00:28:31,860 --> 00:28:37,220 would the core team have for a vector data type support. 590 00:28:37,220 --> 00:28:39,940 But the extensibility mechanism is pretty rich, 591 00:28:39,940 --> 00:28:41,860 and it enables these kinds of things. 592 00:28:41,860 --> 00:28:44,460 So definitely, I think it has one of the strengths, 593 00:28:44,460 --> 00:28:46,780 as you said, exactly, the extensibility. 594 00:28:46,780 --> 00:28:48,460 Also, it's a double-edged sword, though. 595 00:28:48,460 --> 00:28:50,740 I think it comes with the, 596 00:28:50,740 --> 00:28:53,420 so all the cloud vendors are, 597 00:28:53,420 --> 00:28:57,500 so I think the quality, the QA, the quality control 598 00:28:57,500 --> 00:28:59,580 for extensions, I think, is an interesting topic. 599 00:28:59,580 --> 00:29:02,020 So how do we maintain, 600 00:29:02,020 --> 00:29:04,500 how do we know which extension versions are good, 601 00:29:04,500 --> 00:29:05,340 which are not good? 602 00:29:05,340 --> 00:29:06,940 A lot of testing overhead goes with it, 603 00:29:06,940 --> 00:29:10,740 which is why I think there is only 604 00:29:10,740 --> 00:29:13,780 a limited set of extensions that all the cloud vendors support 605 00:29:13,780 --> 00:29:15,820 and the ones that we test and validate. 606 00:29:15,820 --> 00:29:18,900 So another area, actually, would be 607 00:29:18,900 --> 00:29:22,660 interesting to experiment with or have some good ideas on 608 00:29:22,660 --> 00:29:24,140 is that how can we, 609 00:29:24,140 --> 00:29:25,300 how do we do QA? 610 00:29:25,300 --> 00:29:28,380 How do we, is it always going to be crowdsourced? 611 00:29:28,380 --> 00:29:32,180 Is there a better model here possible for this? 612 00:29:32,180 --> 00:29:34,660 I think we can do, [QA for extensions, you mean?] 613 00:29:34,660 --> 00:29:36,060 Extensions, yes. 614 00:29:36,060 --> 00:29:39,980 How do we do quality control for extensions? 615 00:29:39,980 --> 00:29:41,420 All the version mismatches. 616 00:29:41,420 --> 00:29:42,740 Does this extension work? 617 00:29:42,740 --> 00:29:43,620 Does extension A work with 618 00:29:43,620 --> 00:29:44,940 extension B? Sometimes 619 00:29:44,940 --> 00:29:46,940 we have seen those problems also. 620 00:29:46,940 --> 00:29:49,420 But I think the benefits of extensions 621 00:29:49,420 --> 00:29:54,620 far outweigh any of these additional work that 622 00:29:54,620 --> 00:29:55,580 needs to be done there. 623 00:29:55,580 --> 00:29:57,940 I think it has helped Postgres move faster 624 00:29:57,940 --> 00:30:02,500 as a database, which has been very critical to its success. 625 00:30:02,500 --> 00:30:04,300 [CLAIRE] There's a talk I've given a couple of times 626 00:30:04,300 --> 00:30:08,340 at Postgres conferences called the Map of Amazing Postgres 627 00:30:08,340 --> 00:30:10,460 Extensions You Might Not Know About. 628 00:30:10,460 --> 00:30:15,060 And I gave it recently in Seattle at the PASS Summit. 629 00:30:15,060 --> 00:30:16,860 And what's interesting is a lot of times, 630 00:30:16,860 --> 00:30:19,380 the people who attend this talk are 631 00:30:19,380 --> 00:30:22,540 people who are experienced database practitioners, 632 00:30:22,540 --> 00:30:25,100 but maybe in the process of migrating over 633 00:30:25,100 --> 00:30:28,180 from some other database like Oracle, 634 00:30:28,180 --> 00:30:30,380 or even sometimes SQL Server. 635 00:30:30,380 --> 00:30:33,940 And maybe they're starting up a new project or new workloads, 636 00:30:33,940 --> 00:30:36,540 but their skills are not necessarily in Postgres. 637 00:30:36,540 --> 00:30:38,780 So they're not familiar yet, 638 00:30:38,780 --> 00:30:41,780 growth mindset there, with all of the various extensions 639 00:30:41,780 --> 00:30:43,180 and how to choose between them. 640 00:30:43,180 --> 00:30:45,540 And so the question I will often get asked 641 00:30:45,540 --> 00:30:49,700 is, well, how do I know which extensions I can rely on? 642 00:30:49,700 --> 00:30:53,220 How do I know, and sometimes these people 643 00:30:53,220 --> 00:30:57,500 are in on-prem scenarios, 644 00:30:57,500 --> 00:31:01,780 so they're not looking to run their app in a managed service 645 00:31:01,780 --> 00:31:02,300 yet. 646 00:31:02,300 --> 00:31:05,140 They're focused on doing the migration on-prem. 647 00:31:05,140 --> 00:31:07,300 And it's hard to answer that question. 648 00:31:07,300 --> 00:31:10,620 And my answer will often be, well, I give a little cheat. 649 00:31:10,620 --> 00:31:12,260 I say, there's a hack you can use. 650 00:31:12,260 --> 00:31:13,780 You can go look at the hyperscalers. 651 00:31:13,780 --> 00:31:15,980 Go look at Azure Database for PostgreSQL. 652 00:31:15,980 --> 00:31:19,180 See what extensions the managed service providers are 653 00:31:19,180 --> 00:31:20,220 supporting. 654 00:31:20,220 --> 00:31:25,020 And that gives you a clue as to maybe what's well-maintained 655 00:31:25,020 --> 00:31:33,460 and what can be QA'd and is deemed high quality. 656 00:31:33,460 --> 00:31:35,380 And then I'll also tell them, obviously, 657 00:31:35,380 --> 00:31:38,460 go look at the GitHub repo for that project. 658 00:31:38,460 --> 00:31:40,460 See how frequently it's being updated. 659 00:31:40,460 --> 00:31:43,460 See how active the team is, how responsive 660 00:31:43,460 --> 00:31:45,620 they are to issues that get filed, things like that. 661 00:31:45,620 --> 00:31:48,220 Because when you're relying on an extension, what you're 662 00:31:48,220 --> 00:31:50,180 really relying on are the people who 663 00:31:50,180 --> 00:31:52,060 are working on the extension. 664 00:31:52,060 --> 00:31:53,420 And that's who you're trusting. 665 00:31:53,420 --> 00:31:54,420 So who are they? 666 00:31:54,420 --> 00:31:56,340 Go find out. 667 00:31:56,340 --> 00:31:58,580 Anyway, those are the two answers I give. 668 00:31:58,580 --> 00:32:00,620 If you have better suggestions, tell me, 669 00:32:00,620 --> 00:32:04,060 because I know I'll get that question again in the future. 670 00:32:04,060 --> 00:32:07,740 [AFFAN] Claire, I just look at your talk and then answer this question. 671 00:32:07,740 --> 00:32:08,860 I mean, 672 00:32:08,860 --> 00:32:11,740 in my opinion, you've hit the nail on the head. 673 00:32:11,740 --> 00:32:14,980 I think there's only a heuristics-based approach 674 00:32:14,980 --> 00:32:16,980 to figuring out what's a good extension or not, 675 00:32:16,980 --> 00:32:18,540 at least in my opinion. 676 00:32:18,540 --> 00:32:22,300 But to your point, all of these clouds, 677 00:32:22,300 --> 00:32:25,420 the hyperscalers, if something is running in Azure Postgres, 678 00:32:25,420 --> 00:32:28,220 then it probably means that we have done some amount of testing 679 00:32:28,220 --> 00:32:29,220 and all of these things. 680 00:32:29,220 --> 00:32:33,180 So we are confident about the quality of this extension. 681 00:32:33,180 --> 00:32:36,980 And if push comes to shove, we will fix things also. 682 00:32:36,980 --> 00:32:39,500 We'll commit, we'll make changes to extension 683 00:32:39,500 --> 00:32:40,620 also to make it work. 684 00:32:40,620 --> 00:32:44,100 So that's always a good cheat sheet. 685 00:32:44,100 --> 00:32:46,100 But I guess the question is that beyond these, 686 00:32:46,100 --> 00:32:48,820 if you have an on-prem setup and you just 687 00:32:48,820 --> 00:32:51,220 want to run an extension, then all the points you mentioned 688 00:32:51,220 --> 00:32:51,980 are very valid. 689 00:32:51,980 --> 00:32:54,700 It's more crowdsourced. 690 00:32:54,700 --> 00:32:55,780 Look at the popularity. 691 00:32:55,780 --> 00:32:57,260 Look at the bug reports. 692 00:32:57,260 --> 00:33:00,940 Look at the activity on the repos, things like that. 693 00:33:00,940 --> 00:33:03,420 But again, it's not a science. 694 00:33:03,420 --> 00:33:05,580 It's an art right now. 695 00:33:05,580 --> 00:33:09,500 I hope at some point it becomes a science also. 696 00:33:09,500 --> 00:33:10,260 [CLAIRE] OK. 697 00:33:10,260 --> 00:33:12,460 So I still want to talk a lot more about your management 698 00:33:12,460 --> 00:33:15,020 philosophy and more about your learnings 699 00:33:15,020 --> 00:33:18,100 from customers who run their applications 700 00:33:18,100 --> 00:33:19,500 and their workloads in the cloud. 701 00:33:19,500 --> 00:33:23,580 But while we're on the topic of extensions, 702 00:33:23,580 --> 00:33:28,140 I know that Citus was acquired by Microsoft. 703 00:33:28,140 --> 00:33:33,420 And Citus has had a few lives within the Azure ecosystem. 704 00:33:33,420 --> 00:33:36,500 Originally, there was this deployment option 705 00:33:36,500 --> 00:33:39,660 to Azure Database for PostgreSQL called Hyperscale (Citus). 706 00:33:39,660 --> 00:33:42,260 And then we rebranded and basically moved 707 00:33:42,260 --> 00:33:47,460 that deployment option over into Azure Cosmos DB for PostgreSQL. 708 00:33:47,460 --> 00:33:48,980 And that was a couple of years later. 709 00:33:48,980 --> 00:33:51,620 And most recently, there was an announcement like two weeks 710 00:33:51,620 --> 00:33:54,220 ago. [Right. Yes.] 711 00:33:54,220 --> 00:33:54,740 OK. 712 00:33:54,740 --> 00:33:59,180 And so now the Citus capability, the Citus extension, 713 00:33:59,180 --> 00:34:02,740 is available in Azure Database for PostgreSQL 714 00:34:02,740 --> 00:34:06,940 again as a feature called "Elastic clusters". 715 00:34:06,940 --> 00:34:08,260 Did I get that right? [Yes, that's correct.] 716 00:34:09,900 --> 00:34:10,740 OK. 717 00:34:10,740 --> 00:34:11,820 So talk to me. 718 00:34:11,820 --> 00:34:13,780 How do you think about that? 719 00:34:13,780 --> 00:34:15,980 Why did we do that? 720 00:34:15,980 --> 00:34:18,100 Not why did we do what we did before, 721 00:34:18,100 --> 00:34:20,860 but why did we do this here now this year? 722 00:34:20,860 --> 00:34:21,380 [AFFAN] Yeah. 723 00:34:21,380 --> 00:34:24,500 I think we have a class of workloads. 724 00:34:24,500 --> 00:34:28,380 And again, this is completely based on customer demand, 725 00:34:28,380 --> 00:34:29,700 like a demand signal. 726 00:34:29,700 --> 00:34:31,820 We have a class of workloads that are more like, 727 00:34:31,820 --> 00:34:37,100 think of them as maybe multi-tenant or consumer-facing 728 00:34:37,100 --> 00:34:40,020 workloads, internet class workloads, 729 00:34:40,020 --> 00:34:43,780 internet scale workloads, which are easily shardable. 730 00:34:43,780 --> 00:34:47,700 So I think we got a lot of demand from customers 731 00:34:47,700 --> 00:34:53,380 that they want the distributed nature or the sharding 732 00:34:53,380 --> 00:34:59,540 capability that Citus gives within the infrastructure 733 00:34:59,540 --> 00:35:02,620 or server that they're already used to managing 734 00:35:02,620 --> 00:35:07,140 and kind of keeping healthy and all of those, 735 00:35:07,140 --> 00:35:08,980 monitoring all of those things, which 736 00:35:08,980 --> 00:35:10,300 happened to be Flexible Server. 737 00:35:10,300 --> 00:35:15,140 Flexible Server, a widely popular database for Postgres. 738 00:35:15,140 --> 00:35:16,340 A lot of our customers use it. 739 00:35:16,340 --> 00:35:18,900 And they wanted, a bunch of these customers wanted, 740 00:35:18,900 --> 00:35:22,420 a lot of these customers wanted this capability within Flex, 741 00:35:22,420 --> 00:35:23,740 not as a separate service. 742 00:35:23,740 --> 00:35:27,220 So I think we just responded to that demand. 743 00:35:27,220 --> 00:35:28,540 And Citus is a great tech. 744 00:35:28,540 --> 00:35:31,260 It's a great foundational tech. 745 00:35:31,260 --> 00:35:33,540 As people on this forum would already 746 00:35:33,540 --> 00:35:36,660 know that you can use it to scale horizontally. 747 00:35:36,660 --> 00:35:40,420 You can use it to run distributed SQL queries. 748 00:35:40,420 --> 00:35:44,660 And you can, if the data model is done a bit carefully, 749 00:35:44,660 --> 00:35:47,860 then it can pretty much scale linearly. 750 00:35:47,860 --> 00:35:49,660 As you add nodes, you can keep adding nodes. 751 00:35:49,660 --> 00:35:50,940 It will rebalance your cluster. 752 00:35:50,940 --> 00:35:53,060 It will rebalance your shards across this cluster 753 00:35:53,060 --> 00:35:54,740 and all of that. 754 00:35:54,740 --> 00:35:57,420 So it was basically a demand signal 755 00:35:57,420 --> 00:36:00,100 from customers on this one. 756 00:36:00,100 --> 00:36:02,460 So I think that's the main thing. 757 00:36:02,460 --> 00:36:07,780 I think of Citus as an enabling technology, which 758 00:36:07,780 --> 00:36:11,900 is currently being shipped in multiple Postgres offerings 759 00:36:11,900 --> 00:36:12,860 within Microsoft. 760 00:36:12,860 --> 00:36:16,980 At some point, I think we'll have more capabilities showing 761 00:36:16,980 --> 00:36:18,140 up in Citus also. 762 00:36:18,140 --> 00:36:23,060 There's a roadmap for Citus that will, 763 00:36:23,060 --> 00:36:24,940 I think will, either it's published already 764 00:36:24,940 --> 00:36:27,500 or it will be published that we plan to do. 765 00:36:27,500 --> 00:36:30,900 And those will benefit all the services that are supporting 766 00:36:30,900 --> 00:36:33,500 Citus at this point. 767 00:36:33,500 --> 00:36:35,940 Did that answer your question? 768 00:36:35,940 --> 00:36:39,300 [CLAIRE] Yeah, absolutely. 769 00:36:39,300 --> 00:36:44,180 I mean, it's interesting for me, having been with Citus 770 00:36:44,180 --> 00:36:47,660 for so long, the project. I obviously 771 00:36:47,660 --> 00:36:51,580 used to spend, I'd say, 100% of my time focused on Citus. 772 00:36:51,580 --> 00:36:54,940 Nowadays, more of my focus is on the Postgres open source 773 00:36:54,940 --> 00:36:57,380 project more generally, right? 774 00:36:57,380 --> 00:37:01,940 So Citus is a smaller piece of what I focus on. 775 00:37:01,940 --> 00:37:06,900 But it's been interesting to see us try to figure out 776 00:37:06,900 --> 00:37:10,180 at Microsoft, where's the right place for it to land? 777 00:37:10,180 --> 00:37:14,140 Where do customers need this as an enabling technology? 778 00:37:14,140 --> 00:37:18,060 And given the growth in Flexible Server on Azure Database 779 00:37:18,060 --> 00:37:21,460 for PostgreSQL, I'm really glad to see Citus kind of come back 780 00:37:21,460 --> 00:37:22,980 into that platform. 781 00:37:22,980 --> 00:37:27,580 And I'm not... Is it push button easy yet 782 00:37:27,580 --> 00:37:30,380 to go from a single-node Flexible Server 783 00:37:30,380 --> 00:37:32,300 to adopt elastic clusters? 784 00:37:32,300 --> 00:37:34,180 Or is that something that comes later, where it 785 00:37:34,180 --> 00:37:36,700 gets to be push button easy? 786 00:37:36,700 --> 00:37:37,980 [AFFAN] That comes later. 787 00:37:37,980 --> 00:37:39,260 And that's part of our plan. 788 00:37:39,260 --> 00:37:42,340 I think as we evolve, right now, it is in public preview. 789 00:37:42,340 --> 00:37:45,420 As we evolve towards GA, we plan to have 790 00:37:45,420 --> 00:37:48,820 a lot of interesting options whereby you could easily 791 00:37:48,820 --> 00:37:50,660 convert your single-node workloads 792 00:37:50,660 --> 00:37:52,740 into your multi-node workloads. 793 00:37:52,740 --> 00:37:54,340 But it's a bit tricky, though, Claire. 794 00:37:54,340 --> 00:37:57,140 I think there is one thing that we, I think, 795 00:37:57,140 --> 00:38:01,100 have to be pretty, 796 00:38:01,100 --> 00:38:03,740 play around, is that there's a data model that 797 00:38:03,740 --> 00:38:07,460 works very well for sharded database architectures. 798 00:38:07,460 --> 00:38:09,740 And there's a data model that does not. 799 00:38:09,740 --> 00:38:11,220 So it depends, really. 800 00:38:11,220 --> 00:38:15,140 I mean, if you have a shardable, 801 00:38:15,140 --> 00:38:19,140 and this is the same constraint, I guess, 802 00:38:19,140 --> 00:38:21,580 as every other distributed database has. 803 00:38:21,580 --> 00:38:24,740 If you are able to provide some information to the system 804 00:38:24,740 --> 00:38:28,420 on how to manage your shards, then we work very well. 805 00:38:28,420 --> 00:38:29,980 If there's no information, then we 806 00:38:29,980 --> 00:38:33,540 try to work as well as we could. 807 00:38:33,540 --> 00:38:36,660 But yeah, I think the trick between migrating 808 00:38:36,660 --> 00:38:39,820 from single-node workloads to a multi-node workload 809 00:38:39,820 --> 00:38:42,060 is going to be figuring out that thing. 810 00:38:42,060 --> 00:38:44,900 If the migration process or the update process 811 00:38:44,900 --> 00:38:47,820 can give us enough hints, then we can do a really good job. 812 00:38:47,820 --> 00:38:49,980 So I think it will come down to that. 813 00:38:49,980 --> 00:38:53,660 It's not as simple as 814 00:38:53,660 --> 00:38:55,620 you can imagine, it's not as simple as that, oh, 815 00:38:55,620 --> 00:38:56,540 just add another node. 816 00:38:56,540 --> 00:38:59,140 It will magically convert. 817 00:38:59,140 --> 00:39:00,340 [CLAIRE] Yeah, that makes sense. 818 00:39:00,340 --> 00:39:02,700 And that's always been the sticky point with Citus, 819 00:39:02,700 --> 00:39:03,900 right? 820 00:39:03,900 --> 00:39:06,740 And anybody who has the kind of data-intensive workload 821 00:39:06,740 --> 00:39:11,580 where they need that distributed database scale, 822 00:39:11,580 --> 00:39:15,460 they've been motivated to make sure their data model is going 823 00:39:15,460 --> 00:39:18,140 to distribute effectively, right? 824 00:39:18,140 --> 00:39:23,140 And anyone who doesn't need that sometimes 825 00:39:23,140 --> 00:39:24,660 creates a data model in the beginning 826 00:39:24,660 --> 00:39:28,820 that doesn't lend itself well to distributing. 827 00:39:28,820 --> 00:39:30,260 So yeah. 828 00:39:30,260 --> 00:39:30,900 [AFFAN] Exactly. 829 00:39:30,900 --> 00:39:35,020 I think a good fit for the Elastic clusters 830 00:39:35,020 --> 00:39:36,460 and some of these applications, 831 00:39:36,460 --> 00:39:39,380 or the flavor of Elastic clusters that I've shipped so far 832 00:39:39,380 --> 00:39:43,260 is newer apps, right? 833 00:39:43,260 --> 00:39:45,380 So one of the things that we observed 834 00:39:45,380 --> 00:39:50,220 in the previous release of Citus Postgres service 835 00:39:50,220 --> 00:39:52,580 was that the migration is actually, 836 00:39:52,580 --> 00:39:55,340 is an effort, right? 837 00:39:55,340 --> 00:39:59,780 So if you have a consumer-facing app 838 00:39:59,780 --> 00:40:03,860 or a multi-tenant app or an app that is, again, 839 00:40:03,860 --> 00:40:06,980 as will probably grow to the internet scale at some point 840 00:40:06,980 --> 00:40:08,980 or you expect it to grow, then it's 841 00:40:08,980 --> 00:40:13,860 a good idea to kind of review or look at 842 00:40:13,860 --> 00:40:17,500 how to build a good data model that 843 00:40:17,500 --> 00:40:21,420 can be sharded across any tech which supports sharding 844 00:40:21,420 --> 00:40:25,660 like Citus. 845 00:40:25,660 --> 00:40:28,940 [CLAIRE] OK, so you mentioned pgvector earlier. 846 00:40:28,940 --> 00:40:31,420 So we have to talk about AI and Postgres, 847 00:40:31,420 --> 00:40:34,580 because doesn't everybody talk about AI and Postgres? 848 00:40:34,580 --> 00:40:37,260 Like, doesn't that always come up? 849 00:40:37,260 --> 00:40:40,620 I'm on the talk selection team for 850 00:40:40,620 --> 00:40:41,900 POSETTE: An Event for Postgres. 851 00:40:41,900 --> 00:40:44,500 And I was on the talk selection team for PGDay Chicago 852 00:40:44,500 --> 00:40:45,820 last year as well. 853 00:40:45,820 --> 00:40:50,340 And there are a lot of talk proposals about the topic of AI, 854 00:40:50,340 --> 00:40:55,780 because it's everywhere, in terms of people trying it, 855 00:40:55,780 --> 00:40:59,540 adopting it, talking about it. 856 00:40:59,540 --> 00:41:02,660 So how do you see AI playing with Postgres? 857 00:41:02,660 --> 00:41:06,220 What's your perspective on this right now? 858 00:41:06,220 --> 00:41:09,820 [AFFAN] Yeah, I think the AI, 859 00:41:09,820 --> 00:41:11,540 so again, as I was mentioning, the AI, 860 00:41:11,540 --> 00:41:14,100 I think with the pgvector extension, 861 00:41:14,100 --> 00:41:16,860 Postgres happened to be in a leading position in terms 862 00:41:16,860 --> 00:41:24,700 of relational databases. 863 00:41:24,700 --> 00:41:27,780 I think it was a good spot for Postgres to be in. 864 00:41:27,780 --> 00:41:32,020 But I think the interesting thing here 865 00:41:32,020 --> 00:41:38,260 is that customers, when they come to thinking about the Gen 866 00:41:38,260 --> 00:41:40,300 AI applications, obviously, everybody 867 00:41:40,300 --> 00:41:43,860 needs to build Gen AI apps using data. 868 00:41:43,860 --> 00:41:45,660 They are conversing with data, or they 869 00:41:45,660 --> 00:41:49,100 are using data to converse with other types of data. 870 00:41:49,100 --> 00:41:51,540 And LLMs happen to be the intelligent agent 871 00:41:51,540 --> 00:41:54,140 in the middle somewhere who can make sense of this data 872 00:41:54,140 --> 00:41:57,260 and give reasonable answers on that. 873 00:41:57,260 --> 00:42:00,260 I think we've found a lot of cases, 874 00:42:00,260 --> 00:42:02,740 or generally, the cases are that customers 875 00:42:02,740 --> 00:42:07,900 who want to look at the data and provide the data to the LLM 876 00:42:07,900 --> 00:42:10,660 to get back answers, they don't want 877 00:42:10,660 --> 00:42:12,940 to move this data from the database 878 00:42:12,940 --> 00:42:14,860 to another system that does vector 879 00:42:14,860 --> 00:42:17,420 searching and similarity search and all of those things. 880 00:42:17,420 --> 00:42:20,100 They just want to do things in database. 881 00:42:20,100 --> 00:42:21,020 That's the key. 882 00:42:21,020 --> 00:42:24,780 Bring the function to the database, 883 00:42:24,780 --> 00:42:30,220 do not pull the data next to the logic itself. 884 00:42:30,220 --> 00:42:32,900 It's the same thing, along the same lines. 885 00:42:32,900 --> 00:42:38,980 So a lot of customers are leveraging Postgres AI, 886 00:42:38,980 --> 00:42:44,140 like Postgres vector features to do in-place similarity 887 00:42:44,140 --> 00:42:45,020 searches. 888 00:42:45,020 --> 00:42:48,700 And certainly, I see a lot of innovation 889 00:42:48,700 --> 00:42:51,060 happening on pgvector itself. 890 00:42:51,060 --> 00:42:53,820 The algorithms, the default algorithms, keep improving. 891 00:42:53,820 --> 00:42:56,140 HNSW keeps improving. 892 00:42:56,140 --> 00:42:58,220 The recall keeps getting better. 893 00:42:58,220 --> 00:43:03,220 We just announced this DiskANN at Ignite a couple of weeks 894 00:43:03,220 --> 00:43:06,020 ago, which is another algorithm which we feel 895 00:43:06,020 --> 00:43:08,820 is better in many respects with HNSW, 896 00:43:08,820 --> 00:43:11,620 and we'll keep working on that. 897 00:43:11,620 --> 00:43:15,740 So we'll keep seeing a lot of innovation within Postgres 898 00:43:15,740 --> 00:43:19,700 to support these Gen AI application app building 899 00:43:19,700 --> 00:43:21,980 efforts much more closely, much more efficiently. 900 00:43:21,980 --> 00:43:25,300 It will be in the form of faster searches on the data, 901 00:43:25,300 --> 00:43:27,340 more accurate searches on the data. 902 00:43:27,340 --> 00:43:30,980 And it will also go into deeper domains, 903 00:43:30,980 --> 00:43:32,660 like maybe doing semantic searches, 904 00:43:32,660 --> 00:43:38,740 maybe doing hybrid searches where we mix the results from, 905 00:43:38,740 --> 00:43:43,540 for example, text searches and vector search. 906 00:43:43,540 --> 00:43:47,460 And we do some kind of algorithm where 907 00:43:47,460 --> 00:43:50,140 we mix these results to come up with an even better recall, 908 00:43:50,140 --> 00:43:55,060 more relevant answers to your questions, and all this. 909 00:43:55,060 --> 00:43:57,420 So I see a lot of movement in this, 910 00:43:57,420 --> 00:43:59,260 and Postgres is in the right spot. 911 00:43:59,260 --> 00:44:01,500 It already has a lot of developer mindshare. 912 00:44:01,500 --> 00:44:03,580 It has the most developer mindshare. 913 00:44:03,580 --> 00:44:05,980 And most developers are right now experimenting 914 00:44:05,980 --> 00:44:07,060 with AI applications. 915 00:44:07,060 --> 00:44:09,380 So this is like putting two and two together 916 00:44:09,380 --> 00:44:10,860 to come up with a five. 917 00:44:10,860 --> 00:44:13,380 So I think the industry is going to keep 918 00:44:13,380 --> 00:44:17,220 pushing towards more interesting AI features in Postgres. 919 00:44:17,220 --> 00:44:23,580 [CLAIRE] When I look at friends in the industry, 920 00:44:23,580 --> 00:44:25,540 and I've been around a while, worked 921 00:44:25,540 --> 00:44:27,580 at a few different companies, started my career 922 00:44:27,580 --> 00:44:31,660 at Sun Microsystems, which doesn't even exist anymore, 923 00:44:31,660 --> 00:44:33,900 my friends are all over the place. 924 00:44:33,900 --> 00:44:40,540 And it's interesting to see who is embracing these LLMs 925 00:44:40,540 --> 00:44:44,020 and incorporating them into their day-to-day work life 926 00:44:44,020 --> 00:44:51,020 and who is resisting it, focused on the drawbacks, 927 00:44:51,020 --> 00:44:54,060 or the negatives, or the mistakes you can make, 928 00:44:54,060 --> 00:44:57,620 versus other teams that are hiring people 929 00:44:57,620 --> 00:45:01,620 to focus on figuring out how do we adopt this technology 930 00:45:01,620 --> 00:45:03,660 into our services or into our products, 931 00:45:03,660 --> 00:45:08,100 or even just small things, like who's using Copilot 932 00:45:08,100 --> 00:45:09,940 and who's not. 933 00:45:09,940 --> 00:45:13,420 Are developers becoming more productive 934 00:45:13,420 --> 00:45:15,620 by augmenting their skills? 935 00:45:15,620 --> 00:45:19,380 I've often joked that my daughter uses her iPhone 936 00:45:19,380 --> 00:45:22,900 to augment her already super capable brain. 937 00:45:22,900 --> 00:45:25,220 And she's got this $1,000 supercomputer 938 00:45:25,220 --> 00:45:30,860 in her pocket that kind of makes her scale. 939 00:45:30,860 --> 00:45:36,060 And so I feel like Copilot does that for a lot of people, too. 940 00:45:36,060 --> 00:45:38,180 I don't know if that's your perspective. 941 00:45:38,180 --> 00:45:41,180 [AFFAN] Yeah, I think the thing that we're observing, 942 00:45:41,180 --> 00:45:42,940 again talking to customers, 943 00:45:42,940 --> 00:45:45,140 and these are not just like Postgres customers, 944 00:45:45,140 --> 00:45:47,660 but generally like AI application developers 945 00:45:47,660 --> 00:45:48,940 and whatnot, 946 00:45:48,940 --> 00:45:52,220 is that the recall is actually very, very interesting. 947 00:45:52,220 --> 00:45:54,220 The accuracy is very interesting. 948 00:45:54,220 --> 00:45:58,980 So I think people are OK spending a bit more time, 949 00:45:58,980 --> 00:46:03,460 like having slightly lesser TPS, if they can get better results. 950 00:46:03,460 --> 00:46:04,380 So that's one thing. 951 00:46:04,380 --> 00:46:06,700 And the reason for that is clear. 952 00:46:06,700 --> 00:46:11,460 If you use a particular like chatbot or LLM 953 00:46:11,460 --> 00:46:13,740 and you do not get good results, you probably 954 00:46:13,740 --> 00:46:16,660 will not use it often again. 955 00:46:16,660 --> 00:46:19,460 I think it's very, 956 00:46:19,460 --> 00:46:23,860 you may want to wait for maybe like 50 more milliseconds, 957 00:46:23,860 --> 00:46:25,620 but you want to get a good result. 958 00:46:25,620 --> 00:46:31,580 So I think there's potentially some of the what 959 00:46:31,580 --> 00:46:34,700 you call resistors. 960 00:46:34,700 --> 00:46:36,500 Probably I think this is playing into that. 961 00:46:36,500 --> 00:46:38,340 I suspect it's going to play into that also. 962 00:46:38,340 --> 00:46:40,380 The recall becomes more interesting. 963 00:46:40,380 --> 00:46:42,260 The amount of AI applications that 964 00:46:42,260 --> 00:46:45,060 have been built over the last like one or two years 965 00:46:45,060 --> 00:46:50,540 is immense, which means that without having, 966 00:46:50,540 --> 00:46:52,300 I think the industry is still coming around 967 00:46:52,300 --> 00:46:55,340 to figuring out the right patterns and the right controls 968 00:46:55,340 --> 00:46:58,140 to manage the quality of responses 969 00:46:58,140 --> 00:46:59,780 and quality of the data. 970 00:46:59,780 --> 00:47:01,500 And I think it's going to keep happening. 971 00:47:01,500 --> 00:47:03,300 But what we have, the signal we've gotten 972 00:47:03,300 --> 00:47:05,940 is that if the quality is not there, 973 00:47:05,940 --> 00:47:07,500 then the customers will churn. 974 00:47:07,500 --> 00:47:09,580 And then that will impact. 975 00:47:09,580 --> 00:47:13,260 That will create a bad rep for the application. 976 00:47:13,260 --> 00:47:14,260 And it's also like, 977 00:47:14,260 --> 00:47:17,580 I mean, generally somebody using AI, 978 00:47:17,580 --> 00:47:19,500 if this is their AI experience, then they 979 00:47:19,500 --> 00:47:21,700 will definitely become, 980 00:47:21,700 --> 00:47:23,780 go into the resistors camp a bit more. 981 00:47:23,780 --> 00:47:28,860 So it's all about recall, in my opinion. 982 00:47:28,860 --> 00:47:29,940 [CLAIRE] All right. 983 00:47:29,940 --> 00:47:31,220 So let's switch gears for a sec. 984 00:47:31,220 --> 00:47:33,340 I want to talk a little bit more about the Postgres 985 00:47:33,340 --> 00:47:36,060 open source work that's being done at Microsoft 986 00:47:36,060 --> 00:47:39,820 and in your team and how you think about it. 987 00:47:39,820 --> 00:47:42,860 And I'll preface this with the fact that I'm biased. 988 00:47:42,860 --> 00:47:44,660 There are biases in any questions 989 00:47:44,660 --> 00:47:48,460 I ask you on this topic because this is what, 990 00:47:48,460 --> 00:47:50,260 I often talk about the toothbrush test. 991 00:47:50,260 --> 00:47:51,960 This is what motivates me in the morning 992 00:47:51,960 --> 00:47:53,620 when I'm brushing my teeth. 993 00:47:53,620 --> 00:47:55,980 I love the open source community that 994 00:47:55,980 --> 00:47:58,340 works on Postgres around the world 995 00:47:58,340 --> 00:48:01,220 across many different companies. 996 00:48:01,220 --> 00:48:04,340 I especially love the team that you've 997 00:48:04,340 --> 00:48:06,540 been building here at Microsoft. 998 00:48:06,540 --> 00:48:10,260 Some of my favorite people are on that team. 999 00:48:10,260 --> 00:48:14,220 But how do you think about that Postgres open source 1000 00:48:14,220 --> 00:48:16,420 contributor work? 1001 00:48:16,420 --> 00:48:17,380 [AFFAN] Right, yeah, yeah. 1002 00:48:17,380 --> 00:48:23,620 So I think there is two parts to our all up strategy 1003 00:48:23,620 --> 00:48:25,260 for Postgres at Microsoft. 1004 00:48:25,260 --> 00:48:30,220 So there is part one is making Postgres the best relational 1005 00:48:30,220 --> 00:48:34,220 database that it can be in the world. 1006 00:48:34,220 --> 00:48:36,940 And part number two is making Azure the best place 1007 00:48:36,940 --> 00:48:39,180 to run this Postgres database, the best Postgres 1008 00:48:39,180 --> 00:48:42,900 database, the best relational database in the world. 1009 00:48:42,900 --> 00:48:47,820 So I think both of these are very important aspects 1010 00:48:47,820 --> 00:48:50,740 to winning in Postgres. 1011 00:48:50,740 --> 00:48:53,100 And part one, the first part, is what 1012 00:48:53,100 --> 00:48:58,580 this very capable team of contributors and committers 1013 00:48:58,580 --> 00:48:59,700 does for us. 1014 00:48:59,700 --> 00:49:04,860 So we, I mean, this team is pretty fairly independent. 1015 00:49:04,860 --> 00:49:10,740 I think they have access to vast treasure of data 1016 00:49:10,740 --> 00:49:12,660 within, obviously, within privacy constraints. 1017 00:49:12,660 --> 00:49:13,900 They know how the fleet runs. 1018 00:49:13,900 --> 00:49:15,300 They know the typical issues. 1019 00:49:15,300 --> 00:49:16,460 They can look at the issues. 1020 00:49:16,460 --> 00:49:18,340 So they get a lot of data, which they 1021 00:49:18,340 --> 00:49:23,940 can use to identify patterns and problems and issues, which 1022 00:49:23,940 --> 00:49:25,260 they do. 1023 00:49:25,260 --> 00:49:28,540 And oftentimes, it's become something that is useful. 1024 00:49:28,540 --> 00:49:30,780 So in some sense, our fleet of databases 1025 00:49:30,780 --> 00:49:34,900 is helping, hopefully, it's helping the whole industry 1026 00:49:34,900 --> 00:49:36,300 to move forward faster. 1027 00:49:36,300 --> 00:49:39,260 So again, Postgres 17, a lot of interesting contributions. 1028 00:49:39,260 --> 00:49:42,180 There's async I/O work going on. 1029 00:49:42,180 --> 00:49:44,780 There was, I think, some performance improvements 1030 00:49:44,780 --> 00:49:47,340 in partitioning of tables, which is a big scenario coming 1031 00:49:47,340 --> 00:49:52,340 from Oracle migrated workloads, some optimizations, 1032 00:49:52,340 --> 00:49:55,220 and memory allocation performance improvements, 1033 00:49:55,220 --> 00:49:57,700 query planner improvement, a bunch of interesting things 1034 00:49:57,700 --> 00:50:03,140 went in to Postgres 17, which were all independently driven 1035 00:50:03,140 --> 00:50:06,020 by our group of contributors to open source. 1036 00:50:06,020 --> 00:50:08,700 So I think this is also important. 1037 00:50:08,700 --> 00:50:10,060 I mean, this team is independent. 1038 00:50:10,060 --> 00:50:12,140 I mean, they have access to data. 1039 00:50:12,140 --> 00:50:13,740 And then they make their own decision. 1040 00:50:13,740 --> 00:50:15,640 And they work with the community to figure out 1041 00:50:15,640 --> 00:50:18,300 what is the right model to work on there. 1042 00:50:18,300 --> 00:50:20,100 And I think it's worked very well. 1043 00:50:20,100 --> 00:50:27,100 I think as a large cloud vendor, and as an industry, 1044 00:50:27,100 --> 00:50:28,660 I think industry has a responsibility 1045 00:50:28,660 --> 00:50:30,700 here to support Postgres. 1046 00:50:30,700 --> 00:50:33,620 I think Postgres is doing well because the industry is 1047 00:50:33,620 --> 00:50:35,780 actually, the whole community industry is behind it. 1048 00:50:35,780 --> 00:50:40,700 So everybody is sharing and moving the boundary forward, 1049 00:50:40,700 --> 00:50:42,620 pushing forward the boundary. 1050 00:50:42,620 --> 00:50:46,180 And we try to do our part on this one. 1051 00:50:46,180 --> 00:50:49,780 And so far, it has worked well. 1052 00:50:49,780 --> 00:50:51,860 [CLAIRE] I think that's a really interesting phrase, 1053 00:50:51,860 --> 00:50:53,780 that industry has a responsibility 1054 00:50:53,780 --> 00:50:55,300 to support Postgres. 1055 00:50:55,300 --> 00:50:58,740 I think I've heard you use the term, 1056 00:50:58,740 --> 00:51:01,660 was it you that said that we need 1057 00:51:01,660 --> 00:51:05,300 to be good open source citizens? 1058 00:51:05,300 --> 00:51:07,580 That if we're going to build a managed service, 1059 00:51:07,580 --> 00:51:10,660 we also have to be contributing, giving back, leading. 1060 00:51:10,660 --> 00:51:14,220 [AFFAN] Exactly. 1061 00:51:14,220 --> 00:51:17,860 I think it's, again, 1062 00:51:17,860 --> 00:51:20,660 we look at it, the pie is very, very big. 1063 00:51:20,660 --> 00:51:23,340 We're solving the world's database problems. 1064 00:51:23,340 --> 00:51:26,260 The addressable market is huge. 1065 00:51:26,260 --> 00:51:28,660 Anything that we do, and customers, actually, 1066 00:51:28,660 --> 00:51:34,740 they want a database that can work across clouds. 1067 00:51:34,740 --> 00:51:39,140 They want the portability of their database workloads. 1068 00:51:39,140 --> 00:51:40,940 They want that freedom. 1069 00:51:40,940 --> 00:51:43,540 So if we, 1070 00:51:43,540 --> 00:51:46,700 I think which is why a very important aspect of the work 1071 00:51:46,700 --> 00:51:50,780 that we do is to not try to fork as much as we can. 1072 00:51:50,780 --> 00:51:52,940 Because the more forks, 1073 00:51:52,940 --> 00:51:55,660 I mean, if the behavior starts becoming different, 1074 00:51:55,660 --> 00:51:59,580 then it is harder to maintain that promise with customers 1075 00:51:59,580 --> 00:52:01,380 on this vendor portability. 1076 00:52:01,380 --> 00:52:04,420 So I think it's our promise to customers 1077 00:52:04,420 --> 00:52:07,420 who are coming to our clouds to run Postgres 1078 00:52:07,420 --> 00:52:10,260 is that there is going to be minimal vendor lock-in. 1079 00:52:10,260 --> 00:52:11,460 And we need to maintain that. 1080 00:52:11,460 --> 00:52:13,540 And the way to maintain that is to make improvements 1081 00:52:13,540 --> 00:52:15,460 and contribute to the open source upstream 1082 00:52:15,460 --> 00:52:16,540 version of Postgres. 1083 00:52:16,540 --> 00:52:20,460 I think that's very important to maintain customer promise. 1084 00:52:20,460 --> 00:52:23,540 [CLAIRE] So you mentioned how independent the open source contributor 1085 00:52:23,540 --> 00:52:24,100 team is. 1086 00:52:24,100 --> 00:52:26,140 And by the way, I say contributor, 1087 00:52:26,140 --> 00:52:28,180 even though a whole bunch of people in this team 1088 00:52:28,180 --> 00:52:29,540 are committers. 1089 00:52:29,540 --> 00:52:31,500 Because not everybody on this team is committers. 1090 00:52:31,500 --> 00:52:35,340 We also have people who are kind of growing 1091 00:52:35,340 --> 00:52:38,180 in their contributions and are kind of like tomorrow's 1092 00:52:38,180 --> 00:52:42,100 future committers, right? 1093 00:52:42,100 --> 00:52:46,140 So we have people at varying levels of experience and skill. 1094 00:52:46,140 --> 00:52:48,740 But you talked about their independence. 1095 00:52:48,740 --> 00:52:51,340 I was wondering, how much freedom do they really have? 1096 00:52:51,340 --> 00:52:55,340 Do they pick, bottoms up, what their projects are going to be? 1097 00:52:55,340 --> 00:52:59,140 I know that when people are doing planning for Postgres 18, 1098 00:52:59,140 --> 00:53:03,100 there's no top-down roadmap that anybody sets, not even 1099 00:53:03,100 --> 00:53:04,460 the core team, right? 1100 00:53:04,460 --> 00:53:07,660 It is a very bottoms-up system. 1101 00:53:07,660 --> 00:53:08,500 [AFFAN] Right, right, right. 1102 00:53:08,500 --> 00:53:11,780 So I think it's completely by design bottoms-up. 1103 00:53:11,780 --> 00:53:13,980 I think this is a community-driven effort. 1104 00:53:13,980 --> 00:53:15,940 Because I think these individuals 1105 00:53:15,940 --> 00:53:17,820 have to work with the community to kind of make 1106 00:53:17,820 --> 00:53:19,540 the case for whatever work they're doing. 1107 00:53:19,540 --> 00:53:23,660 So it's better driven completely by these individuals. 1108 00:53:23,660 --> 00:53:28,540 And as I said, the thing that we offer is the data sets. 1109 00:53:28,540 --> 00:53:31,540 The data sets, customer problems, 1110 00:53:31,540 --> 00:53:33,300 customer escalations even, right? 1111 00:53:33,300 --> 00:53:37,820 I mean, sometimes our top engineers in the contributors 1112 00:53:37,820 --> 00:53:40,700 team are involved in figuring out issues with customers. 1113 00:53:40,700 --> 00:53:44,980 And oftentimes, there are improvements in Postgres 1114 00:53:44,980 --> 00:53:49,100 that come out as a result of these as well. 1115 00:53:49,100 --> 00:53:53,100 So that's basically the, I think, interesting thing 1116 00:53:53,100 --> 00:54:00,100 that open source contributors kind of have access to. 1117 00:54:00,100 --> 00:54:01,580 But otherwise, completely independent. 1118 00:54:01,580 --> 00:54:08,260 There's no top-down, "hey, we've got to do this" kind of thing. 1119 00:54:08,260 --> 00:54:10,820 Because I think the system is working this way. 1120 00:54:10,820 --> 00:54:14,620 And there's no need to change that. 1121 00:54:14,620 --> 00:54:18,700 [CLAIRE] I know that within the Postgres world, 1122 00:54:18,700 --> 00:54:21,620 there's a number of different companies 1123 00:54:21,620 --> 00:54:26,260 that employ Postgres committers and Postgres contributors. 1124 00:54:26,260 --> 00:54:29,140 And sometimes people move around between employers. 1125 00:54:29,140 --> 00:54:30,380 I heard this phrase recently. 1126 00:54:30,380 --> 00:54:32,380 I don't know what your reaction is going to be. 1127 00:54:32,380 --> 00:54:35,180 But if I got the names right, I think 1128 00:54:35,180 --> 00:54:39,420 when Melanie Plageman moved from Greenplum to Microsoft, 1129 00:54:39,420 --> 00:54:42,220 somebody on the internet commented like, "oh, you 1130 00:54:42,220 --> 00:54:45,140 changed your paycheck provider." 1131 00:54:45,140 --> 00:54:48,780 Because there is this independence, if you will, 1132 00:54:48,780 --> 00:54:51,420 to engineers who work on Postgres. 1133 00:54:51,420 --> 00:54:53,420 So I don't know if you've ever heard that phrase, 1134 00:54:53,420 --> 00:54:54,700 paycheck provider. 1135 00:54:54,700 --> 00:54:56,020 [AFFAN] I have not. 1136 00:54:56,020 --> 00:54:58,060 But certainly, it's an interesting phrase. 1137 00:54:58,060 --> 00:54:59,900 [CLAIRE] Yeah, it is interesting. 1138 00:54:59,900 --> 00:55:02,940 But what I also think is interesting 1139 00:55:02,940 --> 00:55:06,740 is people who have joined this Postgres open source 1140 00:55:06,740 --> 00:55:11,060 team here at Microsoft, they're all still here. 1141 00:55:11,060 --> 00:55:12,620 Knock on wood. 1142 00:55:12,620 --> 00:55:14,660 I don't want to say that and have that change here. 1143 00:55:14,660 --> 00:55:16,500 I'm going to go knock on wood just a second. 1144 00:55:16,500 --> 00:55:21,620 The team has grown. 1145 00:55:21,620 --> 00:55:25,340 And it just keeps getting more amazing, which I think is cool. 1146 00:55:25,340 --> 00:55:26,820 So kudos to you. 1147 00:55:26,820 --> 00:55:28,740 You're doing something right. 1148 00:55:28,740 --> 00:55:30,060 [AFFAN] Yeah, hopefully. 1149 00:55:30,060 --> 00:55:31,420 [CLAIRE] You're doing more than something right. 1150 00:55:31,420 --> 00:55:33,260 You're doing several things right. 1151 00:55:33,260 --> 00:55:36,300 I mean, that's part of why I invited you on the show. 1152 00:55:36,300 --> 00:55:41,500 One of the things that I think is cool is 1153 00:55:41,500 --> 00:55:46,460 when a leader, when a manager, is accessible and approachable 1154 00:55:46,460 --> 00:55:50,460 and you feel like you can go to them as a sounding board 1155 00:55:50,460 --> 00:55:53,460 or to get advice or validation or whatever, 1156 00:55:53,460 --> 00:55:56,100 I just think that's so wonderful versus a VP 1157 00:55:56,100 --> 00:56:00,580 that people are annoyed with or don't want to talk to 1158 00:56:00,580 --> 00:56:03,340 or would rather avoid or you see their name on your phone 1159 00:56:03,340 --> 00:56:04,900 and you don't want to answer it. 1160 00:56:04,900 --> 00:56:06,340 Like, I see your name on my phone, 1161 00:56:06,340 --> 00:56:08,940 I want to answer the call. 1162 00:56:08,940 --> 00:56:11,300 So that's why you're here, because I do think 1163 00:56:11,300 --> 00:56:13,340 you're doing a bunch of things right. 1164 00:56:13,340 --> 00:56:13,980 [AFFAN] I appreciate it. 1165 00:56:13,980 --> 00:56:14,500 Yeah. 1166 00:56:14,500 --> 00:56:15,980 I mean, it's all the team, Claire. 1167 00:56:15,980 --> 00:56:18,780 I think, again, the Postgres team at Microsoft, 1168 00:56:18,780 --> 00:56:20,300 fantastic group of people. 1169 00:56:20,300 --> 00:56:22,140 Could not have asked for a better team. 1170 00:56:22,140 --> 00:56:25,260 I think it's just like standing on the shoulder of giants 1171 00:56:25,260 --> 00:56:26,340 kind of thing. 1172 00:56:26,340 --> 00:56:29,180 But yeah, absolutely. 1173 00:56:29,180 --> 00:56:30,060 [CLAIRE] All right. 1174 00:56:30,060 --> 00:56:36,220 So are there any more stories that you had in your pocket 1175 00:56:36,220 --> 00:56:42,220 that you wanted to share today about management philosophies 1176 00:56:42,220 --> 00:56:45,460 or approach to leading people? 1177 00:56:45,460 --> 00:56:50,060 I'm wondering if there are engineers or developers 1178 00:56:50,060 --> 00:56:53,820 listening to this episode who are thinking four, five, six 1179 00:56:53,820 --> 00:56:56,180 years ahead in their career about whether they want 1180 00:56:56,180 --> 00:57:00,100 to move into management, about what those challenges will be, 1181 00:57:00,100 --> 00:57:05,060 or I don't know, any seeds you want to plant. 1182 00:57:05,060 --> 00:57:05,580 [AFFAN] Yeah. 1183 00:57:05,580 --> 00:57:12,700 I mean, so I think in terms of just generally moving 1184 00:57:12,700 --> 00:57:15,380 to management, I think it's not, 1185 00:57:15,380 --> 00:57:20,820 so first off, I would not think of moving to management 1186 00:57:20,820 --> 00:57:21,940 as a promotion. 1187 00:57:21,940 --> 00:57:24,220 That's something that oftentimes people 1188 00:57:24,220 --> 00:57:25,740 make a mistake of assuming. 1189 00:57:25,740 --> 00:57:27,860 It's not, it's a different role. 1190 00:57:27,860 --> 00:57:33,500 It's not like, oh, this is something better or different. 1191 00:57:33,500 --> 00:57:34,900 It's just a different role. 1192 00:57:34,900 --> 00:57:38,180 And this role comes with its pros and cons. 1193 00:57:38,180 --> 00:57:40,380 The pros are that, yes, you can, 1194 00:57:40,380 --> 00:57:43,380 your impact can span, 1195 00:57:43,380 --> 00:57:46,660 you can do more impact through a group, right? 1196 00:57:46,660 --> 00:57:51,020 But the cons are that you get a little bit, 1197 00:57:51,020 --> 00:57:53,060 I mean, you don't get a little bit, 1198 00:57:53,060 --> 00:57:55,580 I mean, you can, you're still technical and all this, 1199 00:57:55,580 --> 00:57:59,020 but you're not as technical as you would want to be. 1200 00:57:59,020 --> 00:58:03,020 So if your passion is just writing code, 1201 00:58:03,020 --> 00:58:05,140 if you just want to go home at the end of the day 1202 00:58:05,140 --> 00:58:09,060 and then just feel happy about the PR 1203 00:58:09,060 --> 00:58:12,140 that you kind of merged or the check-in that you made 1204 00:58:12,140 --> 00:58:14,020 or the problem that you solved, the algorithm 1205 00:58:14,020 --> 00:58:16,700 that you came up with, or some issue 1206 00:58:16,700 --> 00:58:18,980 that you fixed in live site, right, then I 1207 00:58:18,980 --> 00:58:22,100 think it's a good sign that you enjoy that job 1208 00:58:22,100 --> 00:58:23,900 and then you would want to grow in that. 1209 00:58:23,900 --> 00:58:28,820 Technical leadership is a very viable career path as well. 1210 00:58:28,820 --> 00:58:30,900 But if you actually like talking to people, 1211 00:58:30,900 --> 00:58:32,500 if you like solving people problems, 1212 00:58:32,500 --> 00:58:36,140 if you like, for example, to coach and mentor people, 1213 00:58:36,140 --> 00:58:37,460 and this is not something that, 1214 00:58:37,460 --> 00:58:39,100 by the way, it's not like 1215 00:58:39,100 --> 00:58:40,620 I keep telling people in my team also 1216 00:58:40,620 --> 00:58:42,740 that coaching and mentoring is not a cliche. 1217 00:58:42,740 --> 00:58:43,820 It is actually a thing. 1218 00:58:43,820 --> 00:58:44,980 It has to happen. 1219 00:58:44,980 --> 00:58:46,140 You need to enjoy doing it. 1220 00:58:46,140 --> 00:58:49,380 You need to actually go out and seek opportunities 1221 00:58:49,380 --> 00:58:50,780 to coach people. 1222 00:58:50,780 --> 00:58:51,780 That's a litmus test. 1223 00:58:51,780 --> 00:58:54,660 If you actually go out and seek opportunities to coach people 1224 00:58:54,660 --> 00:58:56,860 and that makes you happy, then probably you 1225 00:58:56,860 --> 00:58:58,300 will enjoy your job as a manager. 1226 00:58:58,300 --> 00:59:01,980 So be very clear on what you want to, what you enjoy. 1227 00:59:01,980 --> 00:59:04,420 Because it's definitely something 1228 00:59:04,420 --> 00:59:07,420 that if you don't enjoy management, 1229 00:59:07,420 --> 00:59:09,220 if you don't enjoy technical leadership, 1230 00:59:09,220 --> 00:59:11,340 then obviously that would be a first thing. 1231 00:59:11,340 --> 00:59:13,580 Second thing is generally management 1232 00:59:13,580 --> 00:59:16,580 is a game of scale, how to scale out. 1233 00:59:16,580 --> 00:59:19,300 And it's just like an engineering project. 1234 00:59:19,300 --> 00:59:20,620 You need to be decentralized. 1235 00:59:20,620 --> 00:59:23,860 You need to be as distributed as possible to be successful. 1236 00:59:23,860 --> 00:59:25,500 So just a couple of things, Claire, 1237 00:59:25,500 --> 00:59:26,980 I think we're out of time as well, 1238 00:59:26,980 --> 00:59:32,500 but that's the thing that came to my mind. 1239 00:59:32,500 --> 00:59:34,940 [CLAIRE] Very cool. 1240 00:59:34,940 --> 00:59:37,460 Are you hiring? 1241 00:59:37,460 --> 00:59:40,820 [AFFAN] We're always hiring, 1242 00:59:40,820 --> 00:59:42,580 the quantity depends. 1243 00:59:42,580 --> 00:59:43,940 It varies time to time. 1244 00:59:43,940 --> 00:59:45,900 But we're always looking for good people with Postgres 1245 00:59:45,900 --> 00:59:47,140 experiences and knowledge. 1246 00:59:47,140 --> 00:59:49,460 And not just Postgres, actually, distributed systems. 1247 00:59:49,460 --> 00:59:50,940 Databases are good in that they are 1248 00:59:50,940 --> 00:59:55,300 a microcosm of all the CS topics, operating systems, 1249 00:59:55,300 --> 00:59:58,020 system engineers, compilers, everything. 1250 00:59:58,020 --> 01:00:00,420 So I think we're hiring all kinds of people. 1251 01:00:00,420 --> 01:00:02,700 Again, the quantity varies over time. 1252 01:00:02,700 --> 01:00:04,380 But always hiring. 1253 01:00:04,380 --> 01:00:06,100 [CLAIRE] Yeah, there's some seasonality I've 1254 01:00:06,100 --> 01:00:10,260 observed at Microsoft in terms of which quarters, 1255 01:00:10,260 --> 01:00:12,180 and it seems to be different year to year. 1256 01:00:12,180 --> 01:00:14,180 It's not always predictably the same. 1257 01:00:14,180 --> 01:00:17,340 But sometimes you're hiring like gangbusters, 1258 01:00:17,340 --> 01:00:19,020 and sometimes you're hiring more slowly, 1259 01:00:19,020 --> 01:00:21,420 but like you said, we're always hiring. [Exactly.] 1260 01:00:21,420 --> 01:00:24,100 Well, that's good to know. 1261 01:00:24,100 --> 01:00:24,620 All right. 1262 01:00:24,620 --> 01:00:29,260 Well, I want to thank you for joining us today. 1263 01:00:29,260 --> 01:00:30,820 I'm trying to make sure that I've 1264 01:00:30,820 --> 01:00:33,580 talked about all the important things, about what 1265 01:00:33,580 --> 01:00:36,900 it means to be leading Postgres engineering on Azure. 1266 01:00:36,900 --> 01:00:43,100 You mentioned Ignite a few weeks ago. 1267 01:00:43,100 --> 01:00:46,700 So that's like a very Microsoft event. 1268 01:00:46,700 --> 01:00:48,460 It's something that happens every year. 1269 01:00:48,460 --> 01:00:52,820 It spans all of the Azure technologies, 1270 01:00:52,820 --> 01:00:54,660 the whole ecosystem? 1271 01:00:54,660 --> 01:00:55,580 [AFFAN] That's correct. 1272 01:00:55,580 --> 01:00:57,220 [CLAIRE] And it happened in Chicago this year. 1273 01:00:57,220 --> 01:00:59,380 They've already announced the date for next year, 1274 01:00:59,380 --> 01:01:03,780 which will be in San Francisco, yay, in my backyard. 1275 01:01:03,780 --> 01:01:08,940 And I know that's where a lot of new features get announced. 1276 01:01:08,940 --> 01:01:12,420 A lot of customers come. 1277 01:01:12,420 --> 01:01:15,100 Charles Feddersen, who heads up 1278 01:01:15,100 --> 01:01:18,340 PM, he's your counterpart for Postgres at Microsoft. 1279 01:01:18,340 --> 01:01:21,340 He's head of the product team. 1280 01:01:21,340 --> 01:01:22,540 I know he was there. 1281 01:01:22,540 --> 01:01:25,300 I know that some of the people on his team 1282 01:01:25,300 --> 01:01:28,420 gave joint presentations with customers like UBS. 1283 01:01:28,420 --> 01:01:31,380 So it was a really big deal. 1284 01:01:31,380 --> 01:01:32,980 And I don't know if there's anything 1285 01:01:32,980 --> 01:01:34,220 we want to mention for that. 1286 01:01:34,220 --> 01:01:38,020 I mean, it's not something that the Postgres open source 1287 01:01:38,020 --> 01:01:42,180 community actively goes to, because historically, it's 1288 01:01:42,180 --> 01:01:44,140 been this, 1289 01:01:44,140 --> 01:01:46,860 I don't know, the focus is on parts of the ecosystem that 1290 01:01:46,860 --> 01:01:48,100 are not Postgres. 1291 01:01:48,100 --> 01:01:50,340 But what I thought was really cool this year 1292 01:01:50,340 --> 01:01:53,020 is there were more Postgres sessions than ever 1293 01:01:53,020 --> 01:01:55,780 in past Ignites. 1294 01:01:55,780 --> 01:02:01,660 And more people in the room, 10 times as many people in the room 1295 01:02:01,660 --> 01:02:03,100 as there had been in the past. 1296 01:02:03,100 --> 01:02:06,940 So I thought it was an interesting inflection point 1297 01:02:06,940 --> 01:02:09,980 for Postgres at Microsoft. 1298 01:02:09,980 --> 01:02:13,140 [AFFAN] I think it tracks our general adoption and growth 1299 01:02:13,140 --> 01:02:17,660 of Postgres in the industry, as well as in Azure. 1300 01:02:17,660 --> 01:02:19,180 I fully suspect we're going to start 1301 01:02:19,180 --> 01:02:20,860 seeing more and more participation 1302 01:02:20,860 --> 01:02:25,300 from customers and our partners in these forums. 1303 01:02:25,300 --> 01:02:29,380 So yeah, I think the interesting thing, what you just mentioned, 1304 01:02:29,380 --> 01:02:31,260 the most interesting thing, at least for me, 1305 01:02:31,260 --> 01:02:33,700 was besides all the great work that the team did, 1306 01:02:33,700 --> 01:02:36,700 which was released, was the customer case study. 1307 01:02:36,700 --> 01:02:39,740 UBS came over, and then they presented 1308 01:02:39,740 --> 01:02:44,340 how they're building a Gen AI platform using Postgres. 1309 01:02:44,340 --> 01:02:47,940 And that's a good presentation to see, 1310 01:02:47,940 --> 01:02:50,020 even if you're not Azure Postgres customer, 1311 01:02:50,020 --> 01:02:52,660 or you're not Microsoft Postgres. 1312 01:02:52,660 --> 01:02:55,700 It's a good insight into how customers use Postgres 1313 01:02:55,700 --> 01:02:59,220 to do AI applications. 1314 01:02:59,220 --> 01:03:01,300 [CLAIRE] There should be a video recording of that. 1315 01:03:01,300 --> 01:03:04,380 I'll try to dig it up and include it in the show notes. 1316 01:03:04,380 --> 01:03:06,220 [AFFAN] Yeah. 1317 01:03:06,220 --> 01:03:08,860 So that was a good one. 1318 01:03:08,860 --> 01:03:12,740 And then we announced a lot of interesting things. 1319 01:03:12,740 --> 01:03:14,820 Elastic clusters was announced. 1320 01:03:14,820 --> 01:03:18,260 We announced automatic indexing and tuning, 1321 01:03:18,260 --> 01:03:20,300 server parameter tuning. 1322 01:03:20,300 --> 01:03:23,620 We, gosh, I think there's a long list of things. 1323 01:03:23,620 --> 01:03:25,620 A DiskANN, we announced a DiskANN, 1324 01:03:25,620 --> 01:03:28,180 supporting pgvector, among a bunch. 1325 01:03:28,180 --> 01:03:29,940 I'm sure I'm missing a few other things. 1326 01:03:29,940 --> 01:03:32,180 So yeah, I may not be able to do justice, 1327 01:03:32,180 --> 01:03:34,980 but there's a lot of interesting things going on at Ignite. 1328 01:03:34,980 --> 01:03:37,380 [CLAIRE] I've been writing this blog post twice a year. 1329 01:03:37,380 --> 01:03:39,220 I think I've done it, 1330 01:03:39,220 --> 01:03:41,220 have I done it two or three times so far? 1331 01:03:41,220 --> 01:03:43,380 Anyway, I'm working on the next version right now, 1332 01:03:43,380 --> 01:03:46,500 and it's called "What's New with Postgres at Microsoft" 1333 01:03:46,500 --> 01:03:50,740 And it tries to span kind of the whole area that you own, 1334 01:03:50,740 --> 01:03:55,940 so the Azure database for Postgres, investments, 1335 01:03:55,940 --> 01:03:58,180 new features, capabilities, et cetera, 1336 01:03:58,180 --> 01:04:00,500 and then our open source contributions, 1337 01:04:00,500 --> 01:04:02,820 and then our community contributions, 1338 01:04:02,820 --> 01:04:06,740 and any of the work we've done on extensions or things 1339 01:04:06,740 --> 01:04:08,500 like Patroni. 1340 01:04:08,500 --> 01:04:10,020 So I've got these different buckets, 1341 01:04:10,020 --> 01:04:11,340 and there's a whole infographic. 1342 01:04:11,340 --> 01:04:14,100 And oh my gosh, it's so much work 1343 01:04:14,100 --> 01:04:17,460 to try to pull it all together into one place. 1344 01:04:17,460 --> 01:04:20,340 [AFFAN] Yeah, it's a great team delivering like clockwork, 1345 01:04:20,340 --> 01:04:23,140 I think, again, as I've got a great set of engineers 1346 01:04:23,140 --> 01:04:24,700 and product managers working on this. 1347 01:04:24,700 --> 01:04:30,660 So I'm very happy with what we keep delivering semester 1348 01:04:30,660 --> 01:04:32,860 after semester. 1349 01:04:32,860 --> 01:04:35,380 [CLAIRE] Well, I am so glad that you joined us today. 1350 01:04:35,380 --> 01:04:39,180 Thank you so much. 1351 01:04:39,180 --> 01:04:41,260 I think we're going to wrap. 1352 01:04:41,260 --> 01:04:44,060 [AFFAN] Thank you for having the discussion. 1353 01:04:44,060 --> 01:04:46,700 [CLAIRE] Let me just go through a few logistics for everybody 1354 01:04:46,700 --> 01:04:47,340 who's listening. 1355 01:04:47,340 --> 01:04:49,940 The next episode, episode 23, is going 1356 01:04:49,940 --> 01:04:53,060 to be recorded live on Wednesday, January 15th, 1357 01:04:53,060 --> 01:04:55,340 at 10am PST. 1358 01:04:55,340 --> 01:04:57,700 And our guest will be Daniel Gustafsson, 1359 01:04:57,700 --> 01:05:02,620 who is one of the Postgres major contributors and committers who 1360 01:05:02,620 --> 01:05:05,620 works on the team at Microsoft. 1361 01:05:05,620 --> 01:05:09,940 And the topic is going to be How I got started as a developer 1362 01:05:09,940 --> 01:05:11,260 and in Postgres. 1363 01:05:11,260 --> 01:05:12,860 If you want to mark your calendar now, 1364 01:05:12,860 --> 01:05:14,900 you can with this calendar invite, 1365 01:05:14,900 --> 01:05:20,860 aka.ms/TalkingPostgres-Ep23-cal 1366 01:05:20,860 --> 01:05:22,940 And you can always get to past episodes 1367 01:05:22,940 --> 01:05:25,980 and get links to subscribe on whatever 1368 01:05:25,980 --> 01:05:30,500 your favorite podcast platform is at talkingpostgres.com. 1369 01:05:30,500 --> 01:05:33,100 And there are transcripts included on the episode pages 1370 01:05:33,100 --> 01:05:35,060 on talkingpostgres.com as well. 1371 01:05:35,060 --> 01:05:37,620 And before we leave, if you've enjoyed this, 1372 01:05:37,620 --> 01:05:41,740 tell your friends, in person, on social media, in DMs, 1373 01:05:41,740 --> 01:05:43,580 we love compliments, 1374 01:05:43,580 --> 01:05:45,700 we love word of mouth recommendations. 1375 01:05:45,700 --> 01:05:48,460 The hashtag is #TalkingPostgres, all one word, 1376 01:05:48,460 --> 01:05:50,380 and that's it.