1
00:00:05,260 --> 00:00:09,500
[CLAIRE] Welcome to Talking Postgres, a monthly podcast for developers who love this database.

2
00:00:10,100 --> 00:00:15,460
I'm your host, Claire Giordano, and in this podcast, we explore the human side of Postgres

3
00:00:15,820 --> 00:00:20,800
databases and open source, which means why do people who work with Postgres do what they

4
00:00:21,000 --> 00:00:22,720
do and how did they get there?

5
00:00:23,420 --> 00:00:27,800
I want to say thank you to the team at Microsoft for sponsoring this community conversation.

6
00:00:28,520 --> 00:00:33,840
Today's guest is Panagiotis Antonopoulos, who many of us call Panos.

7
00:00:34,390 --> 00:00:39,840
He is a distinguished engineer at Microsoft who has worked on database technologies for 15 years now,

8
00:00:40,740 --> 00:00:43,600
specifically cloud databases and distributed systems.

9
00:00:44,880 --> 00:00:47,620
Panos spent his first 13 years on SQL Server.

10
00:00:48,680 --> 00:00:54,360
He has a master's in computer and electrical engineering from the National Technical University of Athens.

11
00:00:55,060 --> 00:01:01,020
And he's not only a really effective technologist, but a super interesting one, which is why I

12
00:01:01,100 --> 00:01:02,120
wanted to have him on the show.

13
00:01:02,700 --> 00:01:03,460
Welcome, Panos.

14
00:01:04,339 --> 00:01:05,920
[PANOS] Hi Claire, really nice to be here.

15
00:01:06,120 --> 00:01:07,200
Thanks so much for inviting me.

16
00:01:08,500 --> 00:01:13,640
[CLAIRE] Today's topic is going to be working on Postgres after 13 years on SQL Server.

17
00:01:16,440 --> 00:01:21,639
People are not necessarily intended to work on the same database technology their entire

18
00:01:21,660 --> 00:01:28,080
career, but I still find that transition from one database to another to be interesting.

19
00:01:28,360 --> 00:01:31,820
And so I thought we could kind of dig in and explore that a little bit today. [Yeah, absolutely.]

20
00:01:34,940 --> 00:01:37,800
So you've listened to some of our episodes.

21
00:01:37,960 --> 00:01:42,720
I know that you did your research before saying yes to the invitation to be on the show.

22
00:01:42,920 --> 00:01:50,200
So you probably know that we often start with asking, what was your origin story as a developer?

23
00:01:50,700 --> 00:01:54,820
And then we can get into your origin story as a database practitioner.

24
00:01:55,500 --> 00:02:00,940
[PANOS] Sounds great yeah and it's not super diverse so you know I finished high school and I was actually

25
00:02:01,240 --> 00:02:05,960
thinking of studying mechanical engineering because I was into racing radio control cars

26
00:02:05,990 --> 00:02:11,100
and I really enjoyed the mechanical aspect at the time but I thought that you know electrical

27
00:02:11,380 --> 00:02:15,980
engineering computer science were really hot at the time so I thought okay you know I may as well

28
00:02:16,000 --> 00:02:22,060
try that. And I started more looking into networking and telecommunications, things

29
00:02:22,060 --> 00:02:27,760
like that. Not so much into software or hardware initially. I hadn't realized I liked it so much

30
00:02:27,830 --> 00:02:33,040
until I started taking some more courses. And that's when I decided that I really enjoyed like

31
00:02:33,400 --> 00:02:39,400
especially software. So yeah, I switched my major to be completely software engineering,

32
00:02:39,660 --> 00:02:46,120
computer science. So I graduated from college and I was lucky enough at the time there was a

33
00:02:46,370 --> 00:02:51,460
recruiting event happening right in Athens where I was studying. There was the SIGMOD conference,

34
00:02:52,140 --> 00:02:56,680
one of the biggest database conferences. Many people here may be familiar. So I was again,

35
00:02:56,810 --> 00:03:01,300
the timing was great because it was, I think it was the only year it has happened in Greece and it

36
00:03:01,370 --> 00:03:07,800
was the year I was graduating. So I decided to attend there and that was it. Like I was hired and

37
00:03:07,820 --> 00:03:11,800
joined Microsoft. That's my early career journey, I guess.

38
00:03:12,500 --> 00:03:13,920
[CLAIRE] Okay, so wait a minute.

39
00:03:14,540 --> 00:03:17,320
Conferences like SIGMOD can be super overwhelming,

40
00:03:17,660 --> 00:03:20,200
even to people who are experienced in a field, right?

41
00:03:20,460 --> 00:03:23,940
There's different tracks, probably different talks.

42
00:03:24,200 --> 00:03:25,280
How do you know what to go to?

43
00:03:25,700 --> 00:03:27,200
What was that experience like?

44
00:03:27,260 --> 00:03:30,800
Or did you go to SIGMOD just to participate in the recruiting event?

45
00:03:31,760 --> 00:03:35,900
[PANOS] Yeah, so it was a little bit of... You're absolutely right, first of all. Even now, after

46
00:03:35,920 --> 00:03:40,020
all these years I've attended maybe even 10s at this point of this conference they can still be

47
00:03:40,200 --> 00:03:44,180
overwhelming as you said there are so many interesting sessions running in parallel it's

48
00:03:44,280 --> 00:03:50,460
really hard to pick and even when you join one imagine people from academia

49
00:03:50,620 --> 00:03:55,040
I've been spending one or two years on a specific topic they're presenting it in 10

50
00:03:55,300 --> 00:03:59,940
minutes their whole research is presented it's such a short amount of time so it's very hard to

51
00:04:00,140 --> 00:04:04,739
absorb all of that. That was my first, very first conference, so it was a mix of both. I wanted to

52
00:04:04,760 --> 00:04:09,340
attend it because I was actually doing my thesis on data management. So it was relevant for me.

53
00:04:10,240 --> 00:04:15,860
But the recruiting event was definitely a big part of why I definitely wanted to be there.

54
00:04:17,000 --> 00:04:21,200
So I picked some sessions and even now, it doesn't really matter. You go there mostly

55
00:04:21,359 --> 00:04:27,120
to network to understand what are the main topics being discussed. And then for anything that seems

56
00:04:27,380 --> 00:04:32,260
interesting, you have to go back and really read the papers and understand, really invest

57
00:04:32,280 --> 00:04:36,360
the time. There's no way you can understand everything in such a short time, but you just

58
00:04:36,560 --> 00:04:41,040
get homework effectively when you go back home. So that was the same thing back then. Hopefully

59
00:04:41,340 --> 00:04:45,300
now I can absorb a little bit more, but still the pattern is the same.

60
00:04:47,480 --> 00:04:52,940
[CLAIRE] And you landed a job as part of the recruiting event that happened at SIGMOD.

61
00:04:53,120 --> 00:04:53,980
Was that with Microsoft?

62
00:04:54,860 --> 00:04:58,760
[PANOS] Yeah, it was with Microsoft. And at the time, again, because it was a SIGMOD recruiting

63
00:04:58,780 --> 00:05:03,280
event, it was specifically with databases. So that there were a lot of good coincidences

64
00:05:03,410 --> 00:05:09,080
at the time, like I was into data coming out of college and the recruiting event was specifically

65
00:05:09,280 --> 00:05:15,220
from the SQL Server team. It was at the time before the transition to cloud. So that's why I say SQL

66
00:05:15,400 --> 00:05:20,520
server, not Azure SQL database. So it was really, we started and that's part of my career journey,

67
00:05:20,940 --> 00:05:25,100
maybe good to discuss some more as we go. But, you know, we started from the on-premises,

68
00:05:25,200 --> 00:05:28,700
what we call box SQL Server that we sell to customers

69
00:05:28,820 --> 00:05:30,020
and they run in their own environments.

70
00:05:30,560 --> 00:05:34,060
And then later we transition to the whole cloud service.

71
00:05:34,580 --> 00:05:35,740
But yes, it was with Microsoft.

72
00:05:35,900 --> 00:05:37,000
It was with SQL Server.

73
00:05:38,300 --> 00:05:38,580
[CLAIRE] Got it.

74
00:05:39,900 --> 00:05:41,260
And this was in Athens, obviously.

75
00:05:41,680 --> 00:05:47,460
So did you start off working on SQL Server in Athens or did you move to somewhere else?

76
00:05:48,220 --> 00:05:50,300
[PANOS] No, it was like a job for Redmond,

77
00:05:50,460 --> 00:05:52,320
in Seattle area for the headquarters.

78
00:05:52,340 --> 00:05:55,320
So it just happened that the event, the recruiting event was there.

79
00:05:55,600 --> 00:06:01,040
And a few people from Southern Europe, Eastern Europe came over to just interview.

80
00:06:01,680 --> 00:06:04,560
But all the position was from Seattle.

81
00:06:04,600 --> 00:06:09,100
And actually, that's an interesting story because I'm not a big fan of traveling.

82
00:06:09,180 --> 00:06:11,300
I've been to a few countries before.

83
00:06:11,640 --> 00:06:17,260
But in just a few days, I decided after having lived for 23 years in Athens,

84
00:06:17,360 --> 00:06:24,040
in my home, you know, where I grew up just to take a plane to a place I've never visited before and

85
00:06:24,220 --> 00:06:29,160
come over to Seattle Redmond area and join Microsoft. So it was really big adventure,

86
00:06:29,320 --> 00:06:34,440
but it just felt right. So I immediately signed and, you know, a couple of months later when visas

87
00:06:34,480 --> 00:06:47,320
and everything were ready, I just flew over to Redmond.

88
00:06:38,980 --> 00:06:42,960
[CLAIRE] Okay, so you did fly to Redmond, though, as part of the interview process.

89
00:06:43,290 --> 00:06:44,280
No.

90
00:06:47,320 --> 00:06:53,640
[PANOS] No, not as part of the interview. They were there from the databases team. But then the interview finished, I was hired, I signed

91
00:06:54,280 --> 00:06:58,060
online I guess. And then when I flew, I really flew. I had never seen the place

92
00:06:59,180 --> 00:07:04,340
until a week before my starting day. So it was very new.

93
00:07:03,760 --> 00:07:04,380
[CLAIRE] Oh my goodness.

94
00:07:04,810 --> 00:07:10,000
And you went from a place that is sunny and warm most of the year,

95
00:07:10,260 --> 00:07:12,240
except maybe in the dead of winter.

96
00:07:13,060 --> 00:07:21,920
And just beautiful blue sky and gorgeous landscapes too cold and rainy and cloudy.

97
00:07:19,580 --> 00:07:20,520
[PANOS] Yes, more cloudy.

98
00:07:22,900 --> 00:07:24,000
Yeah, I didn't know that.

99
00:07:24,160 --> 00:07:25,640
I had done very little research.

100
00:07:26,040 --> 00:07:27,440
I was just super excited.

101
00:07:27,640 --> 00:07:29,020
It was the domain I enjoyed.

102
00:07:29,260 --> 00:07:30,580
It seemed like a great opportunity.

103
00:07:30,760 --> 00:07:32,280
I didn't think of any of that.

104
00:07:32,420 --> 00:07:35,060
I also am a big fan of windsurfing.

105
00:07:35,240 --> 00:07:36,620
It's a thing I cannot miss.

106
00:07:36,840 --> 00:07:39,040
And I didn't even know if there is a place to windsurf.

107
00:07:39,160 --> 00:07:42,780
I just thought, okay, that seems the right opportunity to take.

108
00:07:42,860 --> 00:07:44,880
So I didn't even think about anything.

109
00:07:45,030 --> 00:07:47,380
I just jumped on it and off I am.

110
00:07:48,780 --> 00:07:52,420
[CLAIRE] Well, at least in the Seattle area, you are near the coast.

111
00:07:52,660 --> 00:07:54,360
You still have beautiful vistas.

112
00:07:55,140 --> 00:07:55,980
You have the ocean.

113
00:07:56,120 --> 00:07:57,460
You have the islands nearby.

114
00:07:57,980 --> 00:08:02,560
It's just maybe the temperature's a little different, but it's still a beautiful place.

115
00:08:01,600 --> 00:08:02,020
[PANOS] That's right.

116
00:08:02,300 --> 00:08:05,040
Temperature and precipitation is very different.

117
00:08:05,300 --> 00:08:05,400
Yes.

118
00:08:05,940 --> 00:08:08,580
But generally, it's definitely a very beautiful place,

119
00:08:08,840 --> 00:08:11,619
but it is a change for sure from even the culture

120
00:08:11,640 --> 00:08:17,540
and the climate. There is definitely a difference there. But it's still yeah, I really have

121
00:08:17,800 --> 00:08:21,040
enjoyed it all these 15 years as you said that I've been here.

122
00:08:22,260 --> 00:08:27,160
[CLAIRE] So I want to obviously the podcast is called Talking Postgres and so most of our listeners

123
00:08:27,240 --> 00:08:31,280
have an affection for or actually work on Postgres.

124
00:08:32,130 --> 00:08:35,539
But before we dive into your transition onto it,

125
00:08:35,810 --> 00:08:38,460
is there anything I should know or understand about

126
00:08:39,610 --> 00:08:42,620
what parts of the database you worked on the most

127
00:08:42,880 --> 00:08:46,040
during your SQL Server and Azure SQL DB tenure?

128
00:08:47,260 --> 00:08:50,600
Are you a specialist of some kind or more of a generalist?

129
00:08:51,160 --> 00:08:53,680
[PANOS] I would say a generalist.

130
00:08:53,880 --> 00:08:56,280
I've worked quite a bit across the stack.

131
00:08:56,450 --> 00:09:01,340
So I worked a lot in what we call metadata, like schema management, effectively, which

132
00:09:01,410 --> 00:09:02,840
also includes index management.

133
00:09:03,010 --> 00:09:09,020
And it's a fairly complex area about how you manage all the schema of users and how you build

134
00:09:09,240 --> 00:09:10,860
indexes and so on.

135
00:09:10,950 --> 00:09:12,920
And then I moved over to security.

136
00:09:13,010 --> 00:09:17,800
So I spent a few years on security, working on some new technologies we built there.

137
00:09:18,180 --> 00:09:19,100
I'm happy to share more.

138
00:09:19,900 --> 00:09:23,260
But then eventually, I ended up working a lot in storage.

139
00:09:23,440 --> 00:09:25,940
So I think I would say I'm somewhat of a generalist.

140
00:09:25,940 --> 00:09:30,640
I haven't spent as much time in core query processing and especially query optimization.

141
00:09:31,050 --> 00:09:35,740
I would say maybe one of the areas I haven't had as much expertise.

142
00:09:36,080 --> 00:09:43,340
But outside of that, I have fairly good understanding across the stack on operational database to some degree analytics, too.

143
00:09:44,560 --> 00:09:47,920
And the same, I mean, talking about Postgres, we'll discuss more.

144
00:09:48,180 --> 00:09:53,460
But I've followed similar route on the Postgres side after I transitioned.

145
00:09:54,960 --> 00:10:00,500
[CLAIRE] And then obviously these days you're a distinguished engineer and I imagine but I don't know if this is

146
00:10:00,570 --> 00:10:07,520
true that you spend some time mentoring other people architecting solutions your job

147
00:10:07,530 --> 00:10:14,360
is probably quite different than it was when you started you know 15 years ago what was that like

148
00:10:14,620 --> 00:10:20,620
that transition from being an individual contributor to becoming more of a technical lead to

149
00:10:20,960 --> 00:10:24,860
you know, not just being responsible for your own work anymore.

150
00:10:25,660 --> 00:10:30,160
[PANOS] Yeah you know that's a good question and like I one positive thing is it doesn't happen

151
00:10:30,460 --> 00:10:35,120
overnight you know there are many levels you have to go through so you know it's each one of

152
00:10:35,130 --> 00:10:40,979
them is a step up and gets you closer to you know the other end of the spectrum that you called out.

153
00:10:41,000 --> 00:10:55,820
And you're absolutely right. Mentoring people and guiding the team is a huge part of my job, as well as technical leadership, both product direction to a large extent, but definitely also the architectural direction of the services we're building.

154
00:10:56,280 --> 00:11:17,100
So, from the early days, I, you know, I really like to stretch myself outside of my immediate work. Like I was looking at the immediate things I have to do as table stakes. And I was always trying to push myself a little bit outside, trying to pick up some more areas just to broaden my knowledge, help the team in areas that I don't directly own.

155
00:11:17,140 --> 00:11:23,540
So, you know, over time, stretching this further and further, it ended up in where I am today.

156
00:11:23,670 --> 00:11:29,080
So it was more of a continuum, I would say, where you, you know, even for people in their

157
00:11:29,300 --> 00:11:34,000
early careers, as they're trying to stretch more and more and grow their expertise, grow

158
00:11:34,050 --> 00:11:38,820
their impact across the product, you know, they will find themselves having bigger influence,

159
00:11:39,120 --> 00:11:43,240
bigger scope, and then eventually grow into more senior roles.

160
00:11:44,640 --> 00:11:55,600
[CLAIRE] Okay. So metadata, schema management, index management, security, which is obviously hugely important, maybe more so than it's ever been before. Storage as well.

161
00:11:52,000 --> 00:11:52,080
[PANOS] Yep.

162
00:11:56,110 --> 00:11:56,460
Correct.

163
00:12:00,640 --> 00:12:11,160
[CLAIRE] And I guess before we move into the Postgres side of things, you mentioned the fact that you started with SQL Server and then you moved more into cloud and Azure SQL DB.

164
00:12:11,340 --> 00:12:15,040
Is there anything that I should ask you about there?

165
00:12:15,400 --> 00:12:16,560
Are there any stories there?

166
00:12:17,520 --> 00:12:20,540
[PANOS] Yeah, I mean, again, we can spend a lot of time on it.

167
00:12:21,600 --> 00:12:23,640
It has definitely a very interesting journey.

168
00:12:24,040 --> 00:12:27,540
Interestingly, at the time we called it Azure SQL.

169
00:12:27,800 --> 00:12:32,480
It was one of the first cloud services of Microsoft and maybe even across the industry.

170
00:12:33,000 --> 00:12:54,680
So, you know, we started from very primitive stuff, just putting servers together and just trying to run a database service with a few first party, mainly customers to begin with, all the way to running a very large scale service these days with millions of databases and very mission critical customers and workloads running on our platform.

171
00:12:54,700 --> 00:12:57,700
So it definitely was a super interesting journey.

172
00:12:57,700 --> 00:12:59,960
I think none of us really knew what cloud meant.

173
00:13:00,110 --> 00:13:03,760
Even at the time, there was a clear distinction.

174
00:13:03,930 --> 00:13:07,620
We were building databases and other people were operating them.

175
00:13:08,200 --> 00:13:12,860
These lines have blurred a lot through this time of getting into the cloud.

176
00:13:13,030 --> 00:13:15,100
We have to operate very large portions.

177
00:13:15,310 --> 00:13:18,220
We are part of running the database.

178
00:13:18,400 --> 00:13:23,540
Of course, there is part of the application and administration happening on the customer side.

179
00:13:23,620 --> 00:13:28,040
But we own a lot of the stack from the infrastructure, storage layout.

180
00:13:28,380 --> 00:13:32,600
So there is definitely, you know, we had to expand our understanding

181
00:13:32,820 --> 00:13:35,640
and operationalizing a lot of the aspects of the database

182
00:13:35,800 --> 00:13:36,920
that we hadn't thought of before.

183
00:13:37,120 --> 00:13:40,460
Earlier, we're just building something, writing it on a DVD

184
00:13:40,720 --> 00:13:43,000
and customers would be running it on their site.

185
00:13:43,420 --> 00:13:47,340
Definitely cloud had us to stretch a lot to understand

186
00:13:47,440 --> 00:13:48,960
what it means to operate the database,

187
00:13:49,520 --> 00:13:52,319
especially at scale with the right availability and performance

188
00:13:52,340 --> 00:13:53,900
that our customers expect.

189
00:13:56,920 --> 00:14:04,220
[CLAIRE] Okay, so is it fair to say that in your later years on SQL Server, Azure SQL DB, that you

190
00:14:04,220 --> 00:14:07,620
were focused primarily on the cloud versus the box?

191
00:14:07,160 --> 00:14:07,860
[PANOS] That's a good point.

192
00:14:08,270 --> 00:14:09,800
Yeah, I didn't call that out,

193
00:14:09,810 --> 00:14:10,760
but you're absolutely right.

194
00:14:11,399 --> 00:14:13,460
It felt more natural at the time,

195
00:14:13,620 --> 00:14:15,200
but the whole organization

196
00:14:15,620 --> 00:14:17,060
and the company as well

197
00:14:17,400 --> 00:14:18,320
switched to that model.

198
00:14:18,580 --> 00:14:20,320
So we switched from writing software

199
00:14:20,340 --> 00:14:23,280
and giving it to customers to operate in cloud services.

200
00:14:23,760 --> 00:14:25,460
So all of the things I mentioned,

201
00:14:26,280 --> 00:14:30,000
they were very frequently motivated by cloud.

202
00:14:30,320 --> 00:14:31,540
Just to give some examples, right?

203
00:14:31,680 --> 00:14:34,040
I worked on resumable indexing operations.

204
00:14:34,520 --> 00:14:35,840
So there are indexing operations,

205
00:14:36,160 --> 00:14:37,660
and I'm sure it's the same in Postgres,

206
00:14:38,080 --> 00:14:39,320
that they can take many hours.

207
00:14:39,960 --> 00:14:42,040
On-premises, that was kind of okay

208
00:14:42,440 --> 00:14:44,180
because the environments are extremely stable.

209
00:14:44,260 --> 00:14:46,060
The connections are extremely stable.

210
00:14:46,280 --> 00:14:48,080
Even if it takes 10 hours to complete,

211
00:14:48,620 --> 00:14:49,460
usually it will complete.

212
00:14:49,580 --> 00:14:52,020
In the cloud world, there are always glitches.

213
00:14:52,180 --> 00:15:01,120
There's something in the network, like some packets may drop, the connection may drop, and your operation after five hours can be completely abandoned and you have to start from scratch.

214
00:15:01,380 --> 00:15:06,980
So we did the work to make that resilient to transient failures and allow it to resume from where it was.

215
00:15:07,400 --> 00:15:12,320
Or some of the confidentiality or data integrity work that we did on the security space.

216
00:15:12,900 --> 00:15:15,780
Again, in the on-premises environment, they're very locked down.

217
00:15:15,860 --> 00:15:17,700
They have customers have full control.

218
00:15:17,910 --> 00:15:19,560
Very few admins have access.

219
00:15:20,340 --> 00:15:22,600
So it's a much more protected environment.

220
00:15:22,860 --> 00:15:34,460
Coming to cloud, you know, anyone that is storing really sensitive data, like financial, social security and so on, the bar goes significantly higher in the cloud because there is now this shared ownership.

221
00:15:34,740 --> 00:15:43,900
I talked about it from the operational side, but even from the security side, there is a shared access that the cloud provider has as well as the customers.

222
00:15:44,460 --> 00:15:58,820
So, you know, most of my work almost, I would say, has been highly motivated by the switch to the cloud, like constant time recovery is another feature we worked on to expedite recovery again from deployments that are running in the cloud.

223
00:15:59,000 --> 00:16:00,560
So you're absolutely right, Claire.

224
00:16:01,220 --> 00:16:06,400
Yes, all of this work, even though it mostly, to a large extent, remained in the core database,

225
00:16:07,320 --> 00:16:11,220
it was really done for the world of Azure and the world of cloud,

226
00:16:11,330 --> 00:16:17,300
where things are not as resilient always as they are in a very locked-down on-premise environment.

227
00:16:17,840 --> 00:16:21,360
[CLAIRE] You just mentioned the name of the capability, and I want to make sure I caught it right.

228
00:16:21,540 --> 00:16:23,100
Did you say constant time recovery?

229
00:16:23,080 --> 00:16:26,980
[PANOS] Constant time recovery, that's the name of the paper we published.

230
00:16:27,280 --> 00:16:31,360
The public marketing name is Accelerated Database Recovery.

231
00:16:31,960 --> 00:16:35,260
And interestingly now, coming to the world of Postgres,

232
00:16:35,540 --> 00:16:39,020
it's something Postgres has been designed with from day one,

233
00:16:39,840 --> 00:16:43,440
whereas SQL Server was very different in how it did database recovery.

234
00:16:43,720 --> 00:16:46,400
So yeah, we had to innovate that.

235
00:16:47,540 --> 00:16:49,680
It's still not like Postgres, it's different,

236
00:16:49,760 --> 00:16:51,000
and that's what made it interesting.

237
00:16:51,140 --> 00:16:52,640
We had to invent something new,

238
00:16:52,760 --> 00:16:55,639
but effectively bringing similar promises as Postgres

239
00:16:55,640 --> 00:17:00,420
that it can recover in a much shorter window than it could before.

240
00:17:01,580 --> 00:17:05,319
[CLAIRE] Okay, Panos, you just gave me the perfect introduction to ask the next question, which

241
00:17:05,319 --> 00:17:13,920
is I want to get into what it's like to work on Postgres after 13 years working on Azure

242
00:17:14,050 --> 00:17:14,579
SQL DB.

243
00:17:16,300 --> 00:17:22,139
And obviously, when you start working on a new database, part of your perspective is going

244
00:17:22,160 --> 00:17:26,699
to be influenced by what you're already familiar with. So I'm expecting some comparisons here,

245
00:17:27,780 --> 00:17:32,800
at least as they affected you and your work personally. But what is it like to work on

246
00:17:33,020 --> 00:17:34,920
Postgres after 13 years on SQL Server?

247
00:17:35,300 --> 00:17:39,900
[PANOS] Yeah, one thing that was interesting to me is that at the high level, it feels extremely familiar.

248
00:17:40,240 --> 00:17:44,500
You know, once you get to the code, of course, and the exact features, there are differences.

249
00:17:44,860 --> 00:17:47,140
But the concepts are very similar.

250
00:17:47,420 --> 00:17:50,200
You know, how transactions work, how storage works.

251
00:17:50,300 --> 00:17:55,100
So of course, again, in the lower level details, there are substantial differences in how storage

252
00:17:55,420 --> 00:17:58,980
layout is in one versus the other, how exactly transactions are managed.

253
00:17:59,140 --> 00:18:01,500
But the concepts are extremely similar.

254
00:18:01,590 --> 00:18:03,660
So that was one thing that felt good.

255
00:18:03,930 --> 00:18:07,520
It was that I felt that all the expertise I had built was very relevant.

256
00:18:07,820 --> 00:18:11,440
I could quickly ramp up, engage in complex technical discussions.

257
00:18:12,080 --> 00:18:16,499
Of course, I didn't know every line of code by any means, but at least I could very quickly

258
00:18:16,880 --> 00:18:20,680
understand how things work and contribute meaningfully to our designs.

259
00:18:21,760 --> 00:18:26,760
Now, coming to the lower level, I would say there is definitely a big difference between

260
00:18:27,120 --> 00:18:28,740
what SQL has and Postgres.

261
00:18:29,340 --> 00:18:34,800
SQL is like, you know, over the years we have accumulated and added a very large set

262
00:18:34,800 --> 00:18:37,240
of features that customers have been asking for.

263
00:18:37,400 --> 00:18:39,500
So then this has pros and cons.

264
00:18:39,600 --> 00:18:44,679
I mean, even now after working on Postgres and how much I love Postgres the past couple

265
00:18:44,700 --> 00:18:49,620
of years, like SQL is very complete as a product in terms of you know, whether it's columns

266
00:18:49,710 --> 00:18:53,660
or indexes, advanced security features, like some of what I mentioned, or even the

267
00:18:53,750 --> 00:18:56,120
thread concurrency model that it has.

268
00:18:56,430 --> 00:18:59,460
It's really you know, pretty fascinating product.

269
00:19:00,460 --> 00:19:05,260
But because of all of that, you know, there has definitely been a layer of complexity in

270
00:19:05,340 --> 00:19:11,260
the code base, in our test cases and collateral, you know, everything has grown over time

271
00:19:11,310 --> 00:19:12,500
and has become more complex.

272
00:19:13,240 --> 00:19:15,940
Postgres feels a little bit on the other end of the spectrum.

273
00:19:16,190 --> 00:19:20,740
You know, it has all the basic capabilities one would expect on the database.

274
00:19:21,420 --> 00:19:22,940
It's still, I feel a little bit behind.

275
00:19:22,990 --> 00:19:25,000
I hope the audience here doesn't hate me for that.

276
00:19:25,010 --> 00:19:30,760
It feels a little bit behind on some of the more, you know, fancy, more complicated features

277
00:19:31,000 --> 00:19:32,820
that enterprise customers expect.

278
00:19:33,300 --> 00:19:38,220
But the benefit of that is like the committers have done an amazing job keeping the core engine

279
00:19:38,580 --> 00:19:39,260
extremely lean.

280
00:19:40,160 --> 00:19:42,160
So with that, you know, you can read the code.

281
00:19:42,380 --> 00:19:44,540
That was a shocking experience for me.

282
00:19:44,600 --> 00:19:46,900
I could understand new areas in Postgres

283
00:19:46,980 --> 00:19:48,860
much faster than I could for SQL.

284
00:19:49,140 --> 00:19:51,300
So, you know, that was definitely,

285
00:19:51,400 --> 00:19:55,140
you could see that the architectural cleanliness,

286
00:19:55,220 --> 00:19:57,960
I guess, of Postgres really stands out.

287
00:19:58,040 --> 00:19:59,960
And then the extensibility framework

288
00:20:00,180 --> 00:20:02,480
really goes a really long way.

289
00:20:02,540 --> 00:20:03,600
So people have been able,

290
00:20:03,860 --> 00:20:05,800
without introducing this complexity

291
00:20:06,080 --> 00:20:07,220
that I mentioned from SQL,

292
00:20:07,360 --> 00:20:09,759
they have been able to add significant features

293
00:20:09,780 --> 00:20:15,940
that have helped Postgres gain a lot of momentum with developers or other scenarios so yeah that's

294
00:20:15,940 --> 00:20:18,760
I would say at the high level my comparison so far.

295
00:20:21,220 --> 00:20:24,940
[CLAIRE] Yeah, I hope nobody gets pissed off that you used the phrase. It's still a bit behind.

296
00:20:25,960 --> 00:20:32,219
But I think if I talk to anybody I know that works in Postgres, I mean, there are things they want for

297
00:20:32,240 --> 00:20:36,500
Postgres that are being worked on in some cases or being talked about in other cases. [Exactly.]

298
00:20:37,090 --> 00:20:43,500
And so I think people will agree with you that there are new capabilities and problems that we

299
00:20:43,600 --> 00:20:49,320
want to solve. Like Postgres isn't done yet. It's still evolving and every release gets better.

300
00:20:46,680 --> 00:20:46,920
[PANOS] Of course.

301
00:20:49,700 --> 00:20:50,200
Exactly.

302
00:20:49,900 --> 00:20:55,040
[CLAIRE] So that's the positive spin to try to restate what you just said.

303
00:20:54,500 --> 00:20:55,140
[PANOS] No, for sure.

304
00:20:55,560 --> 00:20:55,920
For sure.

305
00:20:56,220 --> 00:20:59,400
And Postgres has proven it can close the gap very quickly.

306
00:20:59,460 --> 00:21:03,460
And that's why all of the industry is building Postgres-based services.

307
00:21:03,960 --> 00:21:08,700
So absolutely, yes. Behind means that there is a clear path to

308
00:21:08,940 --> 00:21:12,880
catch up. So yes, Postgres is on it. And we from Microsoft

309
00:21:13,030 --> 00:21:16,560
are on it as well, by the way, with Postgres. So, yeah.

310
00:21:16,560 --> 00:21:19,420
[CLAIRE] Do you have a perspective on why

311
00:21:20,440 --> 00:21:21,500
Postgres is so popular?

312
00:21:23,100 --> 00:21:26,820
[PANOS] Yeah, so maybe I'm not necessarily the best in the sense

313
00:21:26,880 --> 00:21:30,679
I don't have, maybe you or others have even more context on this. My take is

314
00:21:30,700 --> 00:21:36,340
it feels like good enough it's open source right so it has built the trust of the

315
00:21:36,600 --> 00:21:41,980
community and the open source and then it's like for a very large set of scenarios it's

316
00:21:42,020 --> 00:21:46,660
good enough you know even many of the things that I mentioned and even I worked on the

317
00:21:46,710 --> 00:21:53,580
really high-end features like you know that the top of mission critical and high security workloads

318
00:21:53,840 --> 00:21:59,419
really need but the vast majority doesn't so Postgres has made a great you know made

319
00:21:59,960 --> 00:22:05,460
progress over the past years, catching up with all the core database fundamentals. It performs

320
00:22:05,600 --> 00:22:11,200
very well for normal scenarios. So, you know, even when I was thinking of transition,

321
00:22:11,360 --> 00:22:16,220
I was doing some research of why people love it so much. And that seemed to be the

322
00:22:16,340 --> 00:22:20,140
sentiment. People seem to be saying, you know, why not? Right? You know, Postgres is actually,

323
00:22:20,620 --> 00:22:24,599
it's free if you use it as an open source product. It's actually fairly cheap, even in the cloud

324
00:22:24,620 --> 00:22:30,420
services and then it just delivers what you all the basics you need so unless you have a super like

325
00:22:30,660 --> 00:22:37,160
niche or complicated case people seem to feel that it's good enough now again you know I've spent a

326
00:22:37,280 --> 00:22:42,520
lot of time on SQL Server so it's definitely a lot of goodness there but that seems to be the

327
00:22:42,600 --> 00:22:48,240
consensus at least for you know all the normal scenarios until you get into higher end more

328
00:22:48,290 --> 00:22:53,399
mission critical Postgres does an amazing job so that seems to me to be the biggest motivation

329
00:22:53,420 --> 00:22:59,740
together again with all the community extensibility allowing people to use their features they love easily there.

330
00:23:01,020 --> 00:23:05,720
[CLAIRE] I think trust is a really important thing to think about. What does it mean to

331
00:23:06,420 --> 00:23:12,640
trust a database with your most important data, whether it be financial or, you know,

332
00:23:13,090 --> 00:23:18,780
think of retailers, think of, I mean, there's so many scenarios where people put,

333
00:23:19,350 --> 00:23:25,080
and what could be more important than the data you're trying to protect and that you're trying

334
00:23:25,100 --> 00:23:30,800
use to facilitate your business or your research or whatever. And so I sometimes wonder

335
00:23:31,020 --> 00:23:37,220
about, well, why is it that people trust Postgres? And I do want to give a shout out to all of

336
00:23:37,380 --> 00:23:42,060
the committers and the contributors and the community members, because part of trusting a

337
00:23:42,180 --> 00:23:48,240
technology is trusting the people behind it and the team behind it and the processes that they use

338
00:23:48,360 --> 00:23:53,480
to ensure quality. And I don't know, that's how I think about it. I'm not sure what your perspective

339
00:23:53,480 --> 00:23:54,760
is but...

340
00:23:54,140 --> 00:24:00,140
[PANOS] No, you're absolutely right. Yes, in databases, trust is a huge thing. And you're right, like,

341
00:24:00,310 --> 00:24:05,140
you know, I was kind of taking it for granted coming from the SQL Server world. But you're

342
00:24:05,380 --> 00:24:11,600
absolutely right in an enterprise, sorry, in an open source, you know, area, it's really

343
00:24:11,700 --> 00:24:16,420
the committers that are responsible for that. And they have done a great job, you know, year over year,

344
00:24:16,570 --> 00:24:21,559
really establishing trust, making sure that we don't have data corruptions, we don't have data

345
00:24:21,560 --> 00:24:26,080
losses right so yeah absolutely trust is a very big part of it.

346
00:24:28,200 --> 00:24:33,200
[CLAIRE] And what's interesting too, I was thinking about it the other day, in an enterprise,

347
00:24:34,500 --> 00:24:39,200
people who were engineers who work on the database, you're not often, well, maybe you'll

348
00:24:39,420 --> 00:24:44,580
disagree with me on this, but usually you have PMs that you're working with, right? You're not doing

349
00:24:44,720 --> 00:24:50,559
the PM job as well as the engineering job. But when I think about committers and people who are

350
00:24:50,580 --> 00:24:55,320
working on an open source project, oftentimes in the same person, they are working on engineering,

351
00:24:56,040 --> 00:25:01,860
they are doing their own PM work, they are doing community work and education work,

352
00:25:02,310 --> 00:25:06,560
you know, they're helping organize a conference or giving a talk or whatever. There's so many

353
00:25:06,800 --> 00:25:15,820
different functional jobs being done by the same people. And it's just different. And I wonder

354
00:25:15,840 --> 00:25:18,880
sometimes if people appreciate that or realize it.

355
00:25:18,559 --> 00:25:23,700
[PANOS] No, you're absolutely right. Actually, it's a good thing to call out. Interestingly, my experience

356
00:25:23,860 --> 00:25:29,820
has been somewhat similar because I was always very motivated to pursue the product angle like

357
00:25:30,000 --> 00:25:34,480
you know participate in understanding customer scenarios requirements figure out what are

358
00:25:34,480 --> 00:25:39,620
the things that we should be building to solve the customer pain points but you're right that is

359
00:25:39,640 --> 00:25:45,240
not the norm right in an enterprise there is more clear role distinctions to a large extent

360
00:25:45,520 --> 00:25:49,840
between engineering and product management and that's not the same in the open source you're

361
00:25:50,000 --> 00:25:53,700
absolutely right that the same people have both to think what needs to be done

362
00:25:54,440 --> 00:25:59,060
you know as well as go build it so it's definitely there is a multi-persona

363
00:26:00,059 --> 00:26:03,460
responsibility there which is definitely complex to navigate.

364
00:26:04,440 --> 00:26:07,120
[CLAIRE] I wonder, do you think that's part of why you're a distinguished engineer?

365
00:26:08,080 --> 00:26:12,140
Not everybody becomes a DE after 15 years.

366
00:26:13,900 --> 00:26:20,540
So is it, has, do you feel like that interest in the customer scenarios and meeting with customers

367
00:26:20,560 --> 00:26:25,640
and understanding those requirements has influenced your engineering work?

368
00:26:25,840 --> 00:26:26,600
It must have.

369
00:26:27,100 --> 00:26:27,780
[PANOS] I think so.

370
00:26:27,780 --> 00:26:30,760
I always try to understand

371
00:26:31,160 --> 00:26:32,460
the big picture of things

372
00:26:32,500 --> 00:26:37,860
rather than own a very specific thing,

373
00:26:38,020 --> 00:26:39,140
deliver it and be done.

374
00:26:39,330 --> 00:26:41,500
I wanted to see things end to end.

375
00:26:41,950 --> 00:26:43,740
So from the early days of understanding

376
00:26:43,790 --> 00:26:44,900
the customer problems,

377
00:26:45,220 --> 00:26:47,940
all the way to building the whole architecture

378
00:26:48,030 --> 00:26:49,100
and getting in production,

379
00:26:49,330 --> 00:26:52,380
I think this trying to have a broader scope,

380
00:26:52,620 --> 00:26:56,420
broader understanding of the problem

381
00:26:56,780 --> 00:26:59,140
rather than focusing on something very specific,

382
00:26:59,340 --> 00:27:01,060
I think definitely goes a long way.

383
00:27:01,540 --> 00:27:05,680
So, yes, I think I would say this definitely helped me over my career.

384
00:27:07,520 --> 00:27:08,760
[CLAIRE] Okay, so let's talk about Postgres.

385
00:27:09,480 --> 00:27:13,320
What aspects of Postgres do you really like?

386
00:27:14,980 --> 00:27:18,380
[PANOS] Yeah, I would say the code cleanness is the main, the biggest thing.

387
00:27:18,440 --> 00:27:22,020
I like the architecture and code cleanness is amazing for Postgres.

388
00:27:22,220 --> 00:27:25,860
I think I already mentioned that, at least for me,

389
00:27:25,920 --> 00:27:29,240
I could more easily understand new code in Postgres than in SQL

390
00:27:29,380 --> 00:27:30,460
even after all this time.

391
00:27:31,780 --> 00:27:33,280
That means a lot.

392
00:27:34,040 --> 00:27:36,300
So now I'm talking more from the internals.

393
00:27:36,300 --> 00:27:37,680
We should discuss also from the,

394
00:27:38,260 --> 00:27:40,060
maybe as a user of Postgres.

395
00:27:40,140 --> 00:27:43,580
But as an engineer working from inside the code,

396
00:27:43,740 --> 00:27:45,740
definitely this is really important.

397
00:27:46,880 --> 00:27:49,820
Now, of course, we also make very heavy use of AI.

398
00:27:50,820 --> 00:27:52,300
So that also is a big component

399
00:27:52,520 --> 00:27:55,060
because now all the code is open source.

400
00:27:55,300 --> 00:27:57,800
All the mailing lists and so on are open source.

401
00:27:57,960 --> 00:28:00,120
So all the large language models

402
00:28:00,140 --> 00:28:04,980
have already picked up both on the code, all the discussions going on. So that's where the open

403
00:28:05,220 --> 00:28:10,700
source angle plays an important role because you can, first of all, the code is pretty easy to

404
00:28:10,880 --> 00:28:15,620
understand because of the great work that committers have been doing over the years. But also now AI can

405
00:28:15,780 --> 00:28:22,480
also take a big step in and bring even more understanding of using, again, both the code base

406
00:28:22,560 --> 00:28:28,760
as well as all the mailing discussions so you can understand why certain decisions were made and so,

407
00:28:28,780 --> 00:28:33,180
again, as an engineer, I would say that that is the biggest thing.

408
00:28:33,200 --> 00:28:38,020
I can easily understand and navigate and make progress in the code base.

409
00:28:39,600 --> 00:28:41,400
That helps a lot in the velocity.

410
00:28:42,040 --> 00:28:48,400
Maybe now coming as a user, I would say I think the extensibility has helped a lot.

411
00:28:48,520 --> 00:28:51,420
Maybe it's a bit both from user as well as coder perspective.

412
00:28:51,540 --> 00:28:54,640
But the fact that you can easily plug in things

413
00:28:54,960 --> 00:28:57,940
without having to make significant redesigns

414
00:28:57,940 --> 00:29:00,660
of the core engine, that is super critical.

415
00:29:00,790 --> 00:29:02,480
You can very quickly build extensions

416
00:29:02,920 --> 00:29:05,540
that provide the necessary functionality

417
00:29:06,130 --> 00:29:08,540
without having to modify the core engine,

418
00:29:08,840 --> 00:29:11,400
without having to go into gazillion architectural discussions

419
00:29:11,700 --> 00:29:12,740
about how this should happen.

420
00:29:13,300 --> 00:29:16,520
So yeah, this pluggability model and sensibility model

421
00:29:16,660 --> 00:29:17,940
is a huge, huge asset.

422
00:29:18,400 --> 00:29:21,680
So these are the main things I would quickly call out.

423
00:29:23,180 --> 00:29:25,380
[CLAIRE] Is there anything that surprised you?

424
00:29:26,580 --> 00:29:29,460
Maybe you had the wrong perception coming in,

425
00:29:29,780 --> 00:29:33,480
or maybe because of your SQL database experience,

426
00:29:33,900 --> 00:29:37,100
you thought, just assumed things would be a certain way in Postgres,

427
00:29:37,260 --> 00:29:38,860
and then they were not.

428
00:29:39,920 --> 00:29:41,060
[PANOS] Yeah, yeah, for sure.

429
00:29:41,390 --> 00:29:45,820
I mean, there are some things that I will call out maybe two things.

430
00:29:45,960 --> 00:29:50,760
Something that surprised me positively is just the raw performance of Postgres.

431
00:29:51,220 --> 00:29:55,500
For simple scenarios, it just performs extremely well,

432
00:29:55,640 --> 00:29:59,300
whether it's bulk loading data or simple select queries or whatnot.

433
00:30:00,160 --> 00:30:02,300
And I'm still trying to wrap my head why that is.

434
00:30:02,480 --> 00:30:04,080
I think it's mainly because of, again,

435
00:30:04,120 --> 00:30:06,640
it goes back to the simplicity that we've been discussing.

436
00:30:07,160 --> 00:30:09,540
It's just what we call the code path length.

437
00:30:09,700 --> 00:30:11,280
It's just less code to execute.

438
00:30:11,420 --> 00:30:15,140
So you can actually get to the important part of fetching the data faster.

439
00:30:15,200 --> 00:30:18,400
So that's definitely one thing that surprised me positively.

440
00:30:19,180 --> 00:30:23,200
Maybe something that surprised me, not necessarily, I wouldn't say negative, but more, as you were

441
00:30:23,300 --> 00:30:27,440
saying, there were certain, like I was coming with certain mindset that specific things in

442
00:30:27,440 --> 00:30:29,000
the database world are given.

443
00:30:29,880 --> 00:30:34,000
And, you know, I was surprised Postgres doesn't have is definitely, for example, like using

444
00:30:34,780 --> 00:30:37,380
processes instead of threads for new connections.

445
00:30:37,380 --> 00:30:43,000
That was something I was assuming it's, you know, threads are always the default just for

446
00:30:43,020 --> 00:30:49,600
performance and scalability or the problems around the wraparound of the transaction ID,

447
00:30:51,020 --> 00:30:55,580
it's a problem that we've generally tried to solve in other systems. I was assuming that for

448
00:30:56,460 --> 00:31:02,560
a product that is so broadly adopted and has become ubiquitous to a large extent for many

449
00:31:02,700 --> 00:31:08,400
workloads, I was expecting some of these table stakes things like problems that have been solved

450
00:31:08,420 --> 00:31:13,940
in the industry to be solved and there's still big problems of Postgres. Of course, I understand

451
00:31:14,160 --> 00:31:18,840
that it's not easy to go fix them and big backward compatibility and other issues. So I understand

452
00:31:19,020 --> 00:31:23,940
the challenges but I still I would still say I was surprised when I saw some of these more

453
00:31:24,360 --> 00:31:26,720
solved problems in the industry still be there.

454
00:31:28,100 --> 00:31:35,180
[CLAIRE] For anyone listening who is new to Postgres, please know that there are people in the Postgres

455
00:31:35,230 --> 00:31:38,100
open source project who are absolutely working on multi-threading.

456
00:31:39,000 --> 00:31:45,200
I can't predict and I don't think there's a betting pool on what release that support would get added into.

457
00:31:46,400 --> 00:31:50,180
And I don't know if it would be added in any kind of phased way over time.

458
00:31:50,460 --> 00:31:54,560
But the discussions are certainly and the engineering work is certainly happening.

459
00:31:54,900 --> 00:31:56,620
So that's goodness.

460
00:31:55,840 --> 00:31:56,660
[PANOS] That's great to hear.

461
00:31:57,360 --> 00:31:57,520
Yes.

462
00:31:58,260 --> 00:32:04,380
[CLAIRE] But the future is still undefined, uncertain.

463
00:32:04,900 --> 00:32:06,660
I don't know what's going to happen when.

464
00:32:06,780 --> 00:32:16,720
Yeah. You mentioned multi-threading. Are there things in SQL Server that you hope Postgres gets in the future?

465
00:32:17,840 --> 00:32:22,720
[PANOS] Yeah, so I mean, maybe I'll draw two categories.

466
00:32:23,340 --> 00:32:29,600
The product fundamentals let's call it yeah multi-threading is one like memory management is

467
00:32:29,640 --> 00:32:34,900
another thing that SQL I would say has done very well and has been increasingly important for

468
00:32:34,960 --> 00:32:41,780
the cloud especially for scenarios like serverless that have become extremely popular recently just

469
00:32:42,100 --> 00:32:47,880
you know as far as and again please anyone don't get upset at me if I misquote anything,

470
00:32:47,900 --> 00:32:51,660
but my understanding is that memory management is still quite rigid in Postgres,

471
00:32:52,580 --> 00:32:55,620
both configuration of it as well as the elasticity of it

472
00:32:55,760 --> 00:32:57,540
after the database comes up.

473
00:32:58,060 --> 00:33:01,760
So some of these things are becoming bigger and bigger problems

474
00:33:02,800 --> 00:33:03,900
that need to be addressed.

475
00:33:04,100 --> 00:33:07,000
And I'm sure that many of the companies working with Postgres,

476
00:33:07,720 --> 00:33:12,120
including ourselves, are paying attention and trying to improve this.

477
00:33:12,480 --> 00:33:14,840
I'm hoping a lot of this work will go back.

478
00:33:15,020 --> 00:33:20,080
If it's not initiated in the open source, it will also go back to the open source. So yeah, there

479
00:33:20,080 --> 00:33:24,820
are a few things on the fundamentals as we discussed like memory and scheduling and thread

480
00:33:24,940 --> 00:33:31,880
management and so on and then just and that's not necessarily a black or white it just speaks to what

481
00:33:31,900 --> 00:33:37,840
we're discussing earlier you know what level of scenarios or yeah what I don't know

482
00:33:37,960 --> 00:33:44,980
what to call it but you know as you get into more complex enterprise scenarios like you know

483
00:33:45,000 --> 00:33:49,420
better analytics support, whether it's again from columnstore for a better query optimizer.

484
00:33:50,040 --> 00:33:54,600
There are areas that if Postgres wants to address some of these higher end workloads,

485
00:33:55,120 --> 00:33:57,860
this will become increasingly important to address.

486
00:33:59,320 --> 00:34:03,020
Similarly on security, again, we have done some interesting work there.

487
00:34:03,380 --> 00:34:09,260
But you're starting to get into more specific things that not every workload in the world will need.

488
00:34:09,460 --> 00:34:13,860
But if you're really targeting the top few percent of workloads,

489
00:34:14,919 --> 00:34:16,800
these things are required.

490
00:34:16,879 --> 00:34:21,000
So it will be interesting to see how much Postgres starts pushing towards that.

491
00:34:21,120 --> 00:34:23,440
Now that they have covered the ground with all the basics,

492
00:34:24,260 --> 00:34:26,960
we'll see how much they also push into that.

493
00:34:27,040 --> 00:34:31,200
And we see similar things, I mean, even coming from the open source world

494
00:34:31,379 --> 00:34:32,800
with extensions and other things,

495
00:34:34,000 --> 00:34:37,760
showing that there is interest for column-oriented storage and so on.

496
00:34:38,260 --> 00:34:38,540
So, yeah.

497
00:34:40,599 --> 00:34:49,700
[CLAIRE] If I roll the audio recording back a few minutes, you mentioned AI and AI tools a few minutes ago.

498
00:34:50,110 --> 00:34:58,680
Are you willing to share how, and you may not want to dive into this, but I'm always trying to learn

499
00:34:58,750 --> 00:35:05,260
from other people about how the AI tools are changing their day-to-day work. What do you do

500
00:35:05,300 --> 00:35:08,300
differently than what you did, say, three years ago.

501
00:35:09,540 --> 00:35:11,560
Now, of course, three years ago, you weren't working on Postgres yet.

502
00:35:11,700 --> 00:35:14,440
So you've had multiple changes in your life at the same time.

503
00:35:14,800 --> 00:35:17,060
But what can you teach me?

504
00:35:17,160 --> 00:35:22,080
Are there any AI hacks, if you will, that save you time?

505
00:35:24,340 --> 00:35:25,700
[PANOS] I mean, this is also a journey.

506
00:35:25,880 --> 00:35:27,160
You know, I will answer today.

507
00:35:27,340 --> 00:35:30,080
If you ask me again in three months, I will have, you know,

508
00:35:30,740 --> 00:35:32,880
more complete answer on new things I'm doing.

509
00:35:33,040 --> 00:35:35,300
And if you asked me three months ago, it will also be different.

510
00:35:35,500 --> 00:35:40,340
But, you know, I would start from maybe let me explain a spectrum of how I would think about it.

511
00:35:40,420 --> 00:35:42,900
The very first thing is just understanding the code.

512
00:35:42,930 --> 00:35:47,680
Right. And that's where the example I used earlier, especially in the open source world,

513
00:35:47,910 --> 00:35:51,640
because the language models have been exposed to all of this data,

514
00:35:51,830 --> 00:35:54,940
whether it's the actual code base as well as a mailing list.

515
00:35:55,420 --> 00:36:02,000
It's extremely, you know, the very first thing you do, it's extremely easy to just ask Copilot and give you answers about how things work,

516
00:36:02,240 --> 00:36:04,440
why they were designed that way.

517
00:36:04,640 --> 00:36:08,540
[CLAIRE] Do you use the voice tools or are you typing still?

518
00:36:09,060 --> 00:36:15,100
[PANOS] No I'm still typing I've heard conflicting you know opinions of how well the

519
00:36:15,360 --> 00:36:21,000
voice tools work and I've used it a little bit on ChatGPT it seems like to try and address

520
00:36:21,200 --> 00:36:27,220
conversational latency meaning that it really wants to respond in real time not even

521
00:36:27,460 --> 00:36:33,760
wait for one second so it seemed to be less the quality seemed to degrade a bit I've heard the

522
00:36:33,780 --> 00:36:39,260
same from others. So I've been typing. It's also easier, when looking at code, it's easier to

523
00:36:39,420 --> 00:36:45,260
copy-paste function names and variable names. So I've been doing that. But yeah, I haven't tried it

524
00:36:45,360 --> 00:36:49,460
for coding especially. I haven't tried the voice experience.

525
00:36:50,660 --> 00:36:51,420
[CLAIRE] So back to the spectrum.

526
00:36:51,660 --> 00:36:52,020
Number one.

527
00:36:52,080 --> 00:36:57,340
Understanding the code and as well as the decision-making. [Correct.] And I'll just point out that

528
00:36:57,580 --> 00:37:01,780
someone said to me once that one of the things they loved about Postgres isn't just that it's open

529
00:37:02,000 --> 00:37:08,000
source, but that it's open decision-making. That because the mailing list is public, you can see the

530
00:37:08,120 --> 00:37:12,860
rationale and the reasons. And that, particularly to engineers who were just getting

531
00:37:13,120 --> 00:37:19,060
started, that's a huge treasure trove of insight that normally you don't get access to in the world

532
00:37:19,080 --> 00:37:23,940
of proprietary corporations. So it's kind of cool. All right. So that's number one. What else?

533
00:37:24,000 --> 00:37:24,100
[PANOS] Yes.

534
00:37:24,660 --> 00:37:26,900
So the next step is like, you know, write code.

535
00:37:27,200 --> 00:37:29,080
And then we'll start from small things.

536
00:37:29,160 --> 00:37:31,080
You know, just as you're right,

537
00:37:31,200 --> 00:37:33,880
you have already decided how to write the code.

538
00:37:33,940 --> 00:37:36,520
And, you know, as you're doing the work,

539
00:37:36,520 --> 00:37:37,300
it will help you.

540
00:37:37,840 --> 00:37:39,120
And again, as we're exploring the spectrum,

541
00:37:39,280 --> 00:37:40,620
it can help you with small things.

542
00:37:40,720 --> 00:37:41,820
You know, whether it's some,

543
00:37:42,520 --> 00:37:43,840
I'll use some dummy example,

544
00:37:43,960 --> 00:37:46,620
but list traversal things or anything like,

545
00:37:46,860 --> 00:37:49,580
you know, granular code you need to write or test.

546
00:37:49,860 --> 00:37:53,160
It can do an extremely good job to write these things.

547
00:37:54,220 --> 00:37:56,560
And again, taking small examples here,

548
00:37:56,780 --> 00:37:59,040
just you have decided, you have designed things

549
00:37:59,180 --> 00:38:01,600
you want to execute on. It will help you do that.

550
00:38:02,120 --> 00:38:05,360
The next step is actually brainstorming on even the design.

551
00:38:06,960 --> 00:38:09,940
And the spectrum has also become broader

552
00:38:10,140 --> 00:38:12,620
as models have become more mature.

553
00:38:12,960 --> 00:38:15,100
So that's why I'm saying in three months,

554
00:38:15,340 --> 00:38:17,820
maybe my answer will even be more complete.

555
00:38:19,340 --> 00:38:23,780
But now you can actually brainstorm architectural decisions and trade-offs.

556
00:38:24,070 --> 00:38:26,020
And we need to be careful.

557
00:38:26,490 --> 00:38:29,620
And that's why I think our jobs are still safe,

558
00:38:29,960 --> 00:38:33,720
because somebody needs to verify that what the models are saying is true

559
00:38:33,750 --> 00:38:35,260
and make the right final decisions.

560
00:38:35,370 --> 00:38:36,160
We're still accountable.

561
00:38:36,480 --> 00:38:40,060
But really, they bring up a lot of good points

562
00:38:40,110 --> 00:38:43,880
and a lot of interesting trade-offs that you can do a lot less research

563
00:38:43,880 --> 00:38:45,900
to think about than you normally would do.

564
00:38:46,040 --> 00:38:48,840
So it expedites your work significantly.

565
00:38:48,940 --> 00:38:53,060
So now what I'm getting at is like you can actually brainstorm with it.

566
00:38:53,070 --> 00:38:58,260
You can co-design things with the models and come up with a design.

567
00:38:59,100 --> 00:39:00,860
So that's the next step.

568
00:39:00,960 --> 00:39:06,600
And now the final step I've been exploring, maybe two parts, like I've been exploring recently,

569
00:39:06,760 --> 00:39:12,520
and it's gone surprisingly well, is to actually do the brainstorming, come up with a design,

570
00:39:12,840 --> 00:39:17,320
come up with a plan all together with, you know, Copilot and AI.

571
00:39:17,940 --> 00:39:22,220
And now actually start executing without writing any code

572
00:39:22,320 --> 00:39:24,640
or extremely little code from my side.

573
00:39:25,160 --> 00:39:29,840
So if you go through the whole pipeline of co-designing,

574
00:39:30,200 --> 00:39:31,600
coming up with a plan together,

575
00:39:31,980 --> 00:39:37,740
and finally executing the Copilot or whatever tool you're using,

576
00:39:37,820 --> 00:39:41,880
like Claude, or of course we're using GitHub Copilot to the most extent,

577
00:39:42,580 --> 00:39:43,860
it just has enough context.

578
00:39:44,020 --> 00:39:47,420
So it can actually do a very good job implementing things

579
00:39:47,440 --> 00:39:49,700
and I'm not talking even about super small things,

580
00:39:49,920 --> 00:39:54,780
but even changing the storage design, for example, of your service,

581
00:39:55,460 --> 00:39:58,700
as long as you work with it and you break down the work with it,

582
00:39:58,700 --> 00:40:01,820
it can actually pick this up and execute very well.

583
00:40:02,220 --> 00:40:05,960
So I'm trying to get to a world where, to a very large extent,

584
00:40:06,160 --> 00:40:10,720
I'm able to use it as a peer in my team to go and build things together,

585
00:40:10,940 --> 00:40:14,080
and it will do a very large extent of the coding by itself.

586
00:40:14,860 --> 00:40:20,520
One other dimension, maybe now I talked a lot about the code and the development cycle.

587
00:40:21,060 --> 00:40:25,280
The other part and testing, the other part is the operationalization of it, right?

588
00:40:25,420 --> 00:40:30,720
You know, whether it's debugging test cases that failed in our pipelines or even live

589
00:40:31,000 --> 00:40:36,300
incidents in production, that's another area where we're pushing a lot across the team to

590
00:40:36,440 --> 00:40:38,640
leverage AI and reduce the toil.

591
00:40:38,900 --> 00:40:44,800
I'm sure nobody enjoys, you know, or at least almost nobody enjoys all these investigations

592
00:40:45,090 --> 00:40:46,680
and getting called in the middle of the night.

593
00:40:46,970 --> 00:40:53,240
So that's another area that we're trying to heavily leverage AI to go and help us with,

594
00:40:53,680 --> 00:40:57,920
whether it's test failures or even live incident investigations,

595
00:40:59,600 --> 00:41:02,800
expedite this and mitigate even automatically in many cases.

596
00:41:07,359 --> 00:41:09,440
[CLAIRE] I take notes while we're talking.

597
00:41:09,590 --> 00:41:12,020
I don't know if anybody listening to this show knows that.

598
00:41:12,350 --> 00:41:17,160
So it makes it easier for me to remember exactly what you said, even rolling back five or ten minutes.

599
00:41:17,740 --> 00:41:26,220
And you mentioned that you're not so pleased with the latency on the conversational latency

600
00:41:26,420 --> 00:41:28,680
of the voice tools that you find with Copilot.

601
00:41:29,120 --> 00:41:30,920
[PANOS] No, actually, I was trying to say the opposite.

602
00:41:31,180 --> 00:41:33,280
It seemed to optimize for low latency

603
00:41:33,780 --> 00:41:36,340
when you use the voice experience.

604
00:41:36,790 --> 00:41:38,520
And I think this degraded quality.

605
00:41:38,630 --> 00:41:39,700
So if you type it,

606
00:41:39,710 --> 00:41:41,880
it seemed to give you higher quality answer

607
00:41:42,140 --> 00:41:43,740
than if you talk to it.

608
00:41:43,940 --> 00:41:45,680
That's what I felt, at least.

609
00:41:46,160 --> 00:41:48,340
So they tried to optimize the performance,

610
00:41:48,580 --> 00:41:49,800
like the latency aspect,

611
00:41:50,080 --> 00:41:53,920
but I felt this degraded the precision of the response.

612
00:41:55,480 --> 00:42:09,240
[CLAIRE] So what one of the people said on the Discord chat that I find to be true as well is that there are separate third party voice to text tools and you use those in conjunction with the LLMs, you're going to get a different result.

613
00:42:08,020 --> 00:42:08,340
[PANOS] Makes sense.

614
00:42:09,980 --> 00:42:12,920
[CLAIRE] And people tend to be much happier with that result right now.

615
00:42:13,100 --> 00:42:17,200
Now, of course, in three months, it'll probably be very different because these tools are changing so fast.

616
00:42:17,360 --> 00:42:18,320
So who's to say?

617
00:42:18,080 --> 00:42:18,980
[PANOS] Oh, that's great to know.

618
00:42:18,580 --> 00:42:23,060
[CLAIRE] So I'll send you a link to one of those and you can see your mileage may vary.

619
00:42:21,420 --> 00:42:21,820
[PANOS] Excellent.

620
00:42:22,100 --> 00:42:22,360
Thank you.

621
00:42:25,180 --> 00:42:34,140
[CLAIRE] Okay, so let's get back onto Postgres and your transition from SQL Server onto Postgres after 13 years.

622
00:42:35,760 --> 00:42:40,900
You've made that transition as a practitioner, as somebody who works on the databases themselves.

623
00:42:41,660 --> 00:42:47,880
But you already said that you've spent part of your career thinking about users and user scenarios and things like that.

624
00:42:48,240 --> 00:42:51,460
So do you have any tips for developers or DBAs,

625
00:42:52,300 --> 00:42:54,300
people who run their apps on top of databases

626
00:42:54,620 --> 00:42:58,100
for making that transition from one database to another,

627
00:42:58,300 --> 00:43:01,300
whether it's Oracle to Postgres or whatever to whatever?

628
00:43:02,500 --> 00:43:06,320
[PANOS] Yeah, I would still say a similar answer. That's my feeling, at least, that

629
00:43:06,930 --> 00:43:12,180
your high level skills are extremely reusable the concepts are exactly the same the high

630
00:43:12,290 --> 00:43:18,400
level problems are exactly the same so at least I found myself fairly quickly you know transitioning

631
00:43:18,600 --> 00:43:23,559
to this new world whereas if I had switched to a completely different domain it would have been

632
00:43:23,580 --> 00:43:29,000
whole other story. So I think people should not be super scared of making that jump. All your,

633
00:43:29,110 --> 00:43:35,300
you know, your core knowledge is still very, very widely applicable. Whereas of course, there's some

634
00:43:35,480 --> 00:43:40,800
differences is just as you start really getting into the weeds of specific performance debugging

635
00:43:41,120 --> 00:43:48,940
trouble or, you know, even maybe some very extreme nuances of concurrency control and subtle, you know,

636
00:43:49,120 --> 00:43:54,300
behaviors that concurrency control and isolation levels, for example, just may have between databases.

637
00:43:54,980 --> 00:43:59,400
I mean, this is unavoidable and it will be hopefully a small percent of your work.

638
00:44:00,540 --> 00:44:05,580
Otherwise, I mean, the SQL language is largely an ANSI standard. Of course, there are subtle

639
00:44:05,760 --> 00:44:11,180
differences, but it's mostly the same. The way you approach the problems, whether it's storage

640
00:44:11,360 --> 00:44:16,720
fragmentation, query performance troubleshooting or other things, again, they're very similar.

641
00:44:17,140 --> 00:44:23,600
The exact tools and exact behaviors may slightly vary but I would say that people should at least

642
00:44:23,680 --> 00:44:27,860
my experience has been they should be too scared of making the leap they can reuse their knowledge

643
00:44:28,060 --> 00:44:32,620
and of course they will need to learn some things but that's also what makes it interesting so

644
00:44:32,870 --> 00:44:38,280
yeah I would advise that they shouldn't yeah they should if they have an opportunity they

645
00:44:38,400 --> 00:44:42,840
should try to learn and that's what also what motivated me you know to move to Postgres like

646
00:44:42,860 --> 00:44:44,760
I had spent quite some time on SQL.

647
00:44:44,830 --> 00:44:46,600
I knew most of the internals.

648
00:44:47,030 --> 00:44:49,920
It was interesting to see a completely different system

649
00:44:49,990 --> 00:44:52,100
and understand how all this works,

650
00:44:52,280 --> 00:44:55,140
but having the fundamentals be reusable.

651
00:44:56,680 --> 00:45:01,320
[CLAIRE] So, the fact that the fundamentals about those high-level skills and knowledge and

652
00:45:01,340 --> 00:45:08,480
everything are reusable, that's huge. But at the end of the day, people are going to have to

653
00:45:08,840 --> 00:45:15,420
skill up on the small things that are different, right? And that's work, right? That takes time.

654
00:45:16,020 --> 00:45:23,240
Although I suppose LLMs make it easier and faster. So it's perhaps an easier transition to make today

655
00:45:23,460 --> 00:45:30,300
than it would have been five years ago. I have had two people on the show who both started their

656
00:45:30,320 --> 00:45:36,900
careers more in Oracle and then ultimately moved into the Postgres space. Gwen Shapira and Jeremy

657
00:45:37,200 --> 00:45:41,780
Schneider. And one of the things that Jeremy Schneider created that Gwen gave a shout out to

658
00:45:42,470 --> 00:45:49,320
in her episode is this poster, if you will, called Postgres Happiness Hints. And it's chock full of

659
00:45:49,320 --> 00:45:56,320
those kind of just a bunch of tips about those small specific things that maybe somebody coming

660
00:45:56,340 --> 00:46:02,560
from Oracle, for example, should know about Postgres, about what default timeouts and limits

661
00:46:02,610 --> 00:46:09,640
would be a good idea, or kind of good logging best practices, or how to use connection pooling in

662
00:46:09,860 --> 00:46:14,780
Postgres and things like that. So I will include a link to the Postgres Happiness Hints in the show

663
00:46:14,880 --> 00:46:20,780
notes, just because I think for someone making that transition from another database onto Postgres,

664
00:46:21,180 --> 00:46:21,940
they're super useful.

665
00:46:23,480 --> 00:46:26,580
And Jeremy actually made it as a poster.

666
00:46:27,090 --> 00:46:32,340
He made it years ago, but he updated it this year and displayed it as a poster at PGConf.dev,

667
00:46:33,020 --> 00:46:38,040
which is the annual Postgres development conference that happens each year in Canada.

668
00:46:39,120 --> 00:46:45,240
So anyway, he got more feedback from people there who were in the room in the poster exhibit,

669
00:46:45,500 --> 00:46:46,860
and then he updated it again.

670
00:46:47,440 --> 00:46:48,320
So it's current.

671
00:46:49,480 --> 00:46:52,940
[PANOS] Excellent. Oh, that's great. That sounds like a great resource. Yes, because you're right.

672
00:46:52,990 --> 00:46:57,440
I mean, these little details matter and you need to learn them. So it's it for that. It

673
00:46:57,440 --> 00:46:58,240
can go a very long way.

674
00:46:59,060 --> 00:47:05,720
[CLAIRE] Now, we've had this whole conversation without me really understanding what in Postgres you

675
00:47:06,240 --> 00:47:08,760
actually work on the Azure side of things.

676
00:47:09,210 --> 00:47:13,300
So I'm assuming you're doing a lot of learning from the Postgres open source project.

677
00:47:13,900 --> 00:47:19,860
And obviously our Postgres offerings in Azure have a major dependency on the open source

678
00:47:20,140 --> 00:47:20,240
projects.

679
00:47:20,350 --> 00:47:23,780
They are the open source project then made available as a cloud service.

680
00:47:25,220 --> 00:47:29,540
But I don't actually really know exactly what you work on.

681
00:47:30,070 --> 00:47:34,160
I think you work on HorizonDB, but you've got to tell me.

682
00:47:34,510 --> 00:47:34,940
What do you do?

683
00:47:34,579 --> 00:47:40,160
[PANOS] Yes so that's exactly right so hey and that was big part of the reason why I also joined

684
00:47:40,160 --> 00:47:47,280
the Postgres team yes so HorizonDB is my main priority and just for the

685
00:47:47,310 --> 00:47:52,180
audience maybe they're not as familiar with HorizonDB so it's effectively our take for a

686
00:47:52,540 --> 00:48:00,160
disaggregated compute and storage cloud-native Postgres offering in Azure so you know this

687
00:48:00,220 --> 00:48:04,980
compute and storage disaggregation brings many benefits. You can scale your storage.

688
00:48:06,770 --> 00:48:11,640
There are many terabytes, hundreds of terabytes of data. It introduces the primitive of shared storage.

689
00:48:11,750 --> 00:48:16,880
So you can scale out your read replicas without having to duplicate your storage and spin up new

690
00:48:16,960 --> 00:48:23,620
replicas in a few seconds rather than having to seed a whole new database. So performance,

691
00:48:23,810 --> 00:48:28,060
of course, also gets significantly better. So yes.

692
00:48:26,620 --> 00:48:29,680
[CLAIRE] Wait, can you, I need you to explain that to me.

693
00:48:29,780 --> 00:48:35,800
How is it that you spin up new replicas in a few seconds just because you have shared storage?

694
00:48:30,200 --> 00:48:30,260
[PANOS] Yes.

695
00:48:36,640 --> 00:48:37,400
Right, right.

696
00:48:36,800 --> 00:48:37,340
[CLAIRE] What does that mean?

697
00:48:37,750 --> 00:48:40,000
[PANOS] So let's maybe take a step back, right?

698
00:48:40,050 --> 00:48:42,160
How traditional databases have operated.

699
00:48:42,370 --> 00:48:44,060
The moment you need a new replica,

700
00:48:44,580 --> 00:48:46,040
it is an independent replica.

701
00:48:46,090 --> 00:48:47,820
It is independent in terms of its compute,

702
00:48:48,000 --> 00:48:50,000
but it's also independent in terms of its storage.

703
00:48:50,480 --> 00:48:52,780
So what this normally meant is that you have to take

704
00:48:53,050 --> 00:48:54,620
some sort of database backup,

705
00:48:55,000 --> 00:48:56,300
move it to your other replica,

706
00:48:56,940 --> 00:48:59,240
restore it there, and then catch it up,

707
00:48:59,420 --> 00:49:02,260
replay WAL records until it's fully caught up,

708
00:49:02,280 --> 00:49:04,220
and now it can serve all your read requests.

709
00:49:04,960 --> 00:49:09,580
That's the huge change in this disaggregated shared storage architecture,

710
00:49:09,940 --> 00:49:13,980
because now there is one single source of truth at the storage layer.

711
00:49:14,560 --> 00:49:16,880
Your primary database writes to that.

712
00:49:17,200 --> 00:49:19,660
It keeps track of all the latest pages.

713
00:49:19,800 --> 00:49:23,340
So the moment you need to bring up a new or many new replicas,

714
00:49:23,780 --> 00:49:25,700
all you have to do is bring up the compute.

715
00:49:25,940 --> 00:49:30,180
So just bring up a Postgres instance, and you can directly attach to this storage.

716
00:49:30,760 --> 00:49:32,800
So it's no longer a size of data operation.

717
00:49:33,080 --> 00:49:38,320
It's really just the time you need to take to spin up your compute and just bring up the database there.

718
00:49:38,540 --> 00:49:40,820
Attach, let me call it, the database there.

719
00:49:41,260 --> 00:49:44,200
So this allows you to bring up any number of replicas.

720
00:49:44,360 --> 00:49:45,660
It really gives you the elasticity.

721
00:49:46,000 --> 00:49:48,860
Say that you have some end-of-month reporting or whatnot,

722
00:49:49,020 --> 00:49:54,640
you can very quickly spin up a replica or multiple of them, do your reporting or other queries on the read replicas.

723
00:49:55,180 --> 00:49:57,880
And again, you don't have to pay for duplicate storage.

724
00:49:58,320 --> 00:50:01,460
You don't have to take the time to seed this new duplicate storage.

725
00:50:01,840 --> 00:50:04,100
So that's a huge benefit of these architectures.

726
00:50:07,480 --> 00:50:10,720
[CLAIRE] So you were back to what it is that you do.

727
00:50:10,920 --> 00:50:11,860
Thank you for that little segue.

728
00:50:12,050 --> 00:50:13,120
It helped me understand.

729
00:50:14,619 --> 00:50:18,520
So you work on HorizonDB, disaggregated compute and storage,

730
00:50:19,480 --> 00:50:20,920
giving you the benefits of shared storage,

731
00:50:21,200 --> 00:50:23,240
such as spinning up replicas super fast.

732
00:50:23,830 --> 00:50:24,280
Tell me more.

733
00:50:24,980 --> 00:50:28,580
[PANOS] Yeah. So I'll tell you more on both sides.

734
00:50:29,740 --> 00:50:33,540
So for Horizon, the goal is to effectively bring up

735
00:50:33,680 --> 00:50:36,580
this new generation of Postgres in Azure.

736
00:50:37,220 --> 00:50:39,300
And we're even looking at, as you said,

737
00:50:39,500 --> 00:50:40,840
we leverage the open source

738
00:50:41,020 --> 00:50:44,540
and we're also contributing back to the open source.

739
00:50:44,910 --> 00:50:48,320
But we also want to take it as much we can improve

740
00:50:49,120 --> 00:50:50,700
any gaps that the Postgres has.

741
00:50:50,840 --> 00:50:52,800
HorizonDB's mission is to do that.

742
00:50:52,920 --> 00:50:56,300
So our goal is to really serve enterprise workloads with HorizonDB.

743
00:50:56,380 --> 00:51:06,040
So whether it's in optimizing performance, like giving a huge number of IOs, IO operations, to queries and so on, that's a mission of Horizon.

744
00:51:06,180 --> 00:51:13,820
Now, in terms of my own work, just naturally, most of the work so far has been in the core of storage,

745
00:51:14,120 --> 00:51:15,640
just because as we were just discussing,

746
00:51:17,390 --> 00:51:22,460
the first part is to really move from the normal traditional database architecture

747
00:51:22,530 --> 00:51:25,260
where compute and storage are fully coupled,

748
00:51:25,580 --> 00:51:27,480
move to this decoupled, disaggregated storage.

749
00:51:27,720 --> 00:51:28,980
Most of the work is in storage.

750
00:51:29,220 --> 00:51:31,800
So I worked a lot around the storage layer,

751
00:51:33,730 --> 00:51:36,160
whether it's recovery is one concrete area,

752
00:51:36,210 --> 00:51:39,880
I spend a lot of time on optimizing recovery in that new architecture,

753
00:51:40,480 --> 00:51:45,160
whether it's the management of people who may be familiar with the term SLRU pages,

754
00:51:45,380 --> 00:51:49,660
how we track committed transactions and other internal state.

755
00:51:50,100 --> 00:51:56,000
So I think it stands for simple least recently used.

756
00:51:56,000 --> 00:52:01,120
So it's a special type of pages that Postgres has that is tracking effectively internal metadata,

757
00:52:01,800 --> 00:52:06,980
commit state transaction identifiers for multi-state transactions and so on.

758
00:52:07,380 --> 00:52:08,460
There are different types.

759
00:52:09,160 --> 00:52:12,320
[CLAIRE] Is that a Postgres term or an Azure term?

760
00:52:09,320 --> 00:52:10,840
[PANOS] So yeah, it's internal method.

761
00:52:11,700 --> 00:52:12,620
It is a Postgres term.

762
00:52:12,750 --> 00:52:14,040
It is a Postgres term, yeah.

763
00:52:15,880 --> 00:52:18,360
So bottom line, I've spent a lot of time

764
00:52:19,100 --> 00:52:20,460
looking at the core of storage

765
00:52:21,540 --> 00:52:24,960
and redesigning it to fit this new architecture effectively.

766
00:52:25,150 --> 00:52:26,780
So that's the main part.

767
00:52:27,080 --> 00:52:28,960
Both myself as well as the rest of the team,

768
00:52:29,110 --> 00:52:32,040
storage has been our main focus so far.

769
00:52:32,480 --> 00:52:34,899
Of course, now we're also trying to bring new features

770
00:52:34,920 --> 00:52:40,600
around geo resiliency and customer-managed encryption keys to really meet the enterprise

771
00:52:40,980 --> 00:52:46,380
promises that Azure always has. So, but yeah, most of it is happening at the storage layer.

772
00:52:46,920 --> 00:52:51,680
As HorizonDB grows and we get into general availability and beyond, I'm sure we will invest

773
00:52:51,800 --> 00:52:56,820
in more areas, even query processing and so on. But for now, most of the team is focused on the

774
00:52:56,840 --> 00:52:57,380
storage side.

775
00:52:58,460 --> 00:53:04,340
[CLAIRE] Now, we've also, I've been lucky enough to have had Adam Prout as a guest on this podcast.

776
00:53:05,440 --> 00:53:10,320
And the title of his episode was From MemSQL to HorizonDB, An Engineer's Journey.

777
00:53:11,020 --> 00:53:16,880
And we focused on his personal journey because he obviously was one of the founders of MemSQL,

778
00:53:17,310 --> 00:53:18,480
which is now called SingleStore.

779
00:53:18,650 --> 00:53:20,220
They rebranded a couple of years ago.

780
00:53:21,150 --> 00:53:26,680
But he's been at Microsoft again for his second tenure for a couple of years now and very involved

781
00:53:26,840 --> 00:53:27,400
in HorizonDB.

782
00:53:27,800 --> 00:53:30,880
So I imagine the two of you must work together closely.

783
00:53:30,990 --> 00:53:32,100
Is that fair to say?

784
00:53:31,640 --> 00:53:37,940
[PANOS] Yeah, that's exactly right. We work together every day. So yes, that's also been a great

785
00:53:38,520 --> 00:53:47,140
collaboration so far. We're divided and conquered different areas of HorizonDB and it's been

786
00:53:47,140 --> 00:53:52,260
a really good collaboration. I think it shows up in the results of HorizonDB as well from

787
00:53:52,280 --> 00:53:58,340
availability and performance I think we've made really solid progress very fast so yeah

788
00:53:58,980 --> 00:54:03,660
Adam has been a great collaborator and he has as you said a lot of relevant experience for Microsoft

789
00:54:03,820 --> 00:54:10,020
but also you know more diverse background with MemSQL or SingleStore so yeah it's been great

790
00:54:10,040 --> 00:54:11,900
having his perspective and contributions.

791
00:54:12,760 --> 00:54:16,460
[CLAIRE] Well, in his episode, we also went through his origin story.

792
00:54:17,120 --> 00:54:24,120
And before he was at SingleStore or MemSQL at the time, he also worked at Microsoft early days in his career.

793
00:54:26,210 --> 00:54:28,760
So did the two of you work together way back then?

794
00:54:29,340 --> 00:54:30,000
[PANOS] No, unfortunately,

795
00:54:30,210 --> 00:54:31,820
I think I joined right after

796
00:54:32,770 --> 00:54:33,480
Adam left or

797
00:54:34,280 --> 00:54:35,880
around the time. I think maybe he

798
00:54:35,970 --> 00:54:37,900
was even gone by the time I joined. So I had never

799
00:54:38,020 --> 00:54:38,980
met him before

800
00:54:39,940 --> 00:54:44,440
unfortunately. But yeah, we got the chance to work together now. Yes, not in Microsoft though.

801
00:54:44,720 --> 00:54:47,260
Yeah, no, not before. I mean now in Microsoft.

802
00:54:45,040 --> 00:54:45,340
[CLAIRE] Got it.

803
00:54:48,940 --> 00:54:51,220
So for anyone listening who's like,

804
00:54:51,380 --> 00:54:52,920
huh, I've never heard of HorizonDB,

805
00:54:53,740 --> 00:54:55,040
just some context.

806
00:54:55,560 --> 00:54:58,480
Azure now has two managed Postgres services.

807
00:54:58,820 --> 00:55:02,720
So the one that people are probably very familiar with, my gosh, they should have heard of it

808
00:55:02,820 --> 00:55:05,080
by now, is Azure Database for PostgreSQL.

809
00:55:05,780 --> 00:55:09,680
And I think of that as vanilla Postgres as a service.

810
00:55:09,930 --> 00:55:15,900
It is, you know, the Postgres technology from the open source project made available as a

811
00:55:16,000 --> 00:55:22,440
managed service with all of the kind of things you would expect from a cloud service added

812
00:55:22,770 --> 00:55:24,960
on top of the open source project.

813
00:55:25,610 --> 00:55:27,940
And now, of course, we also offer Azure HorizonDB.

814
00:55:27,980 --> 00:55:30,960
And if you haven't heard of it yet, that's because it's brand new.

815
00:55:31,980 --> 00:55:38,700
Brand new, not in the sense of it was just written last month, but brand new as in the

816
00:55:38,830 --> 00:55:39,880
product just GA'd.

817
00:55:40,940 --> 00:55:42,500
Well, that did just happen last month.

818
00:55:41,220 --> 00:55:42,740
[PANOS] It's actually still in public preview. [Oh, thank you.]

819
00:55:43,100 --> 00:55:44,800
It is in public preview as of last month.

820
00:55:44,910 --> 00:55:46,060
So it hasn't even GA'd yet.

821
00:55:46,400 --> 00:55:47,380
So you're absolutely right.

822
00:55:48,200 --> 00:55:53,440
We have been spending a lot of energy for some time now, but yes, for anyone in the public,

823
00:55:53,760 --> 00:55:54,820
it is brand new.

824
00:55:55,920 --> 00:55:57,380
[CLAIRE] I'm hitting my head against the wall.

825
00:55:57,460 --> 00:56:03,180
I know that. How did I get that wrong? Okay. People make mistakes. It's okay, Claire. You can handle it.

826
00:56:02,960 --> 00:56:04,320
[PANOS] Yeah, don't feel bad.

827
00:56:04,380 --> 00:56:05,620
We have so many milestones.

828
00:56:04,460 --> 00:56:13,260
[CLAIRE] But it was a big announcement last month. So obviously the foundations of Azure HorizonDB

829
00:56:13,460 --> 00:56:19,400
are Postgres. So it's built on top of the fact that this 30-year-old, 40-year-old technology. [For sure.]

830
00:56:20,660 --> 00:56:26,840
Shout out to the fact that this is the 30th birthday for the Postgres Open Source Project

831
00:56:27,340 --> 00:56:29,660
happening this summer right now.

832
00:56:30,340 --> 00:56:33,420
But the technology itself was created 40 years before.

833
00:56:35,140 --> 00:56:38,240
So yeah, it's not completely newfangled.

834
00:56:40,420 --> 00:56:42,300
All right, so that's what you work on.

835
00:56:42,560 --> 00:56:45,120
And that's what you've worked on for the last two years now?

836
00:56:45,280 --> 00:56:46,420
Is it more than that?

837
00:56:46,960 --> 00:56:49,520
[PANOS] No, about one and one and a half year now.

838
00:56:50,140 --> 00:56:51,680
Yeah, still going.

839
00:56:51,840 --> 00:56:53,720
So it's been very interesting.

840
00:56:53,840 --> 00:56:58,960
I mean, as you said, there was a big announcement and that's because Postgres has gone a very

841
00:56:59,060 --> 00:57:00,220
long way in the industry.

842
00:57:00,500 --> 00:57:02,660
So, you know, we really want to stand behind it.

843
00:57:02,680 --> 00:57:05,400
We want to bring the best Postgres service in Azure.

844
00:57:05,610 --> 00:57:06,880
So that's our mission.

845
00:57:07,160 --> 00:57:10,840
So we released the preview last month, a public preview last month,

846
00:57:10,890 --> 00:57:13,600
and we're going into GA and so on.

847
00:57:13,600 --> 00:57:17,060
So it's going to be a journey and hopefully release a lot of cool things

848
00:57:17,070 --> 00:57:18,380
that people will be excited about.

849
00:57:20,840 --> 00:57:25,120
[CLAIRE] I have a question for you, and maybe you can just help me get smarter on something.

850
00:57:26,600 --> 00:57:33,360
I'm going to be giving a talk at Postgres Summit US in September, which is a rebranded

851
00:57:34,780 --> 00:57:38,720
conference formerly called PGConf New York City, which is probably what a lot of people are

852
00:57:38,920 --> 00:57:42,300
familiar with that as it happens in late September, early October.

853
00:57:42,840 --> 00:57:47,019
Anyway, it is the first time I'll have given this talk, and it's called a secret decoder ring

854
00:57:47,040 --> 00:57:53,100
for Postgres replication. And it's a beginner's guide. And there are people in the world who know

855
00:57:53,110 --> 00:57:59,000
a lot more about Postgres replication than I do. But what I bring to the table is that ability to

856
00:57:59,260 --> 00:58:06,280
explain something in a beginner-friendly way. So that's my superpower. Not that I'm a deep [That makes sense.]

857
00:58:06,620 --> 00:58:11,799
Postgres replication expert the way that a lot of my teammates are. Because we have people, by the

858
00:58:11,820 --> 00:58:19,240
way in Microsoft who work full-time almost contributing to the open source project as

859
00:58:19,480 --> 00:58:21,880
committers and major contributors and things like that.

860
00:58:22,330 --> 00:58:26,500
Anyway, I'm just really curious, have you worked on replication much?

861
00:58:26,610 --> 00:58:33,760
When you think about replication, how do you compare SQL Server to what people see in Postgres,

862
00:58:33,930 --> 00:58:34,440
for example?

863
00:58:34,830 --> 00:58:38,740
Because one of the things that confused me when I was brand new to Postgres is I felt like

864
00:58:38,890 --> 00:58:40,960
there were all these different types of replication.

865
00:58:41,180 --> 00:58:44,360
There was logical, there's physical, there's streaming, there's synchronous, there's asynchronous.

866
00:58:44,760 --> 00:58:46,340
And it really confused my brain.

867
00:58:47,040 --> 00:58:51,620
So is it just a terminology problem or are there really that many different types of replication?

868
00:58:52,320 --> 00:58:53,920
And is that the same in other databases?

869
00:58:55,080 --> 00:59:00,160
[PANOS] Yeah I will say it's both and I think it goes back to my earlier answer that the high level

870
00:59:00,540 --> 00:59:05,220
you know high level knowledge is reusable but then there are the specifics of office engine

871
00:59:05,860 --> 00:59:11,580
so unfortunately SQL Server also has the same history so maybe starting from the high level

872
00:59:12,060 --> 00:59:17,320
as you called out right to a large extent there are two types of replication there is logical

873
00:59:17,340 --> 00:59:23,140
replication where the replicator just translates the operations happening into some logical

874
00:59:23,580 --> 00:59:27,640
operations, like insert this row, update this row, delete this row, and they are logically

875
00:59:27,800 --> 00:59:31,980
replayed on the other side. So technically, the two instances, the two replicas don't even

876
00:59:32,140 --> 00:59:38,240
need to be exactly in sync or aligned in terms of the physical format, or in some situations,

877
00:59:38,400 --> 00:59:43,800
even the exact content of the table, they could even diverge potentially. And then there

878
00:59:43,820 --> 00:59:48,760
physical replication which is generally more performant because it's happening at the physical

879
00:59:48,940 --> 00:59:55,900
layer but it requires full effectively both replicas to be fully identical right so SQL

880
00:59:56,000 --> 01:00:03,020
has both as Postgres does SQL unfortunately on the logical replication side also has a very wide

881
01:00:03,440 --> 01:00:10,680
set of different replication technologies with subtle differences a lot of it is timing you

882
01:00:10,700 --> 01:00:13,560
you know, we released something, it had some trade-offs,

883
01:00:13,610 --> 01:00:15,980
and then we realized that there is another set of customers

884
01:00:16,180 --> 01:00:17,680
that require something slightly different.

885
01:00:17,900 --> 01:00:20,060
So, for example, you know, some logical applications

886
01:00:20,960 --> 01:00:24,380
require the tables to be identical, whereas others allow more flexibility,

887
01:00:25,020 --> 01:00:27,720
even allow updates to happen on different sites

888
01:00:27,980 --> 01:00:30,460
and try to consolidate them and resolve conflicts.

889
01:00:31,160 --> 01:00:35,020
So, yeah, there are, even on the SQL side, SQL Server side,

890
01:00:35,080 --> 01:00:36,140
there are a few different technologies.

891
01:00:36,580 --> 01:00:40,040
I'm not as familiar with all the Postgres details

892
01:00:40,660 --> 01:00:42,080
beyond, again, that there is, of course,

893
01:00:42,220 --> 01:00:43,380
physical and there is logical.

894
01:00:44,320 --> 01:00:47,400
So I can't comment if they are exactly one-to-one,

895
01:00:47,820 --> 01:00:50,240
but definitely both sides have both of these types

896
01:00:50,260 --> 01:00:51,900
of replication, physical and logical,

897
01:00:52,960 --> 01:00:54,960
used, again, for different types of scenarios.

898
01:00:55,260 --> 01:00:56,620
So physical is generally used.

899
01:00:57,120 --> 01:01:00,300
We use it also in HorizonDB to replicate data

900
01:01:00,560 --> 01:01:01,200
across our replicas.

901
01:01:01,780 --> 01:01:03,940
And what we're discussing, you can spin up a replica

902
01:01:03,960 --> 01:01:09,040
anytime this is also using physical replication to keep the replica up to speed and then logical

903
01:01:09,340 --> 01:01:14,340
replication is generally more flexible it's used in scenarios where you know the tables may not be

904
01:01:14,460 --> 01:01:19,000
fully aligned the schema may be slightly different so it allows a little bit more of this flexibility

905
01:01:19,820 --> 01:01:25,860
now comparing the two I would say one area that SQL should have spent a little bit more energy

906
01:01:25,880 --> 01:01:32,720
is logical replication that's where Postgres has done a better job it has become you know more

907
01:01:32,740 --> 01:01:34,460
and more interesting over the years.

908
01:01:35,040 --> 01:01:38,800
So yeah, Postgres has done a good job maintaining it.

909
01:01:38,900 --> 01:01:42,180
SQL now has put more energy back into it

910
01:01:42,180 --> 01:01:43,300
and it's the right thing to do.

911
01:01:44,280 --> 01:01:45,400
Both of them are needed.

912
01:01:45,480 --> 01:01:47,940
So you really need both physical to be extremely fast

913
01:01:48,380 --> 01:01:51,220
just because it's part of the core replicated services

914
01:01:51,460 --> 01:01:53,520
just for resiliency that every cloud service needs.

915
01:01:53,840 --> 01:01:56,080
But then again, logical replication gives the flexibility

916
01:01:56,460 --> 01:01:57,660
for other customer scenarios.

917
01:01:57,940 --> 01:02:00,900
So yeah, both are needed and both are important,

918
01:02:01,160 --> 01:02:02,680
just different in how they work.

919
01:02:05,520 --> 01:02:06,820
[CLAIRE] Well, we have gone through it.

920
01:02:06,920 --> 01:02:07,780
Thank you for that, by the way.

921
01:02:07,880 --> 01:02:10,460
It's going to help me as I put together my talk for New York.

922
01:02:10,720 --> 01:02:11,320
So I appreciate it.

923
01:02:13,400 --> 01:02:14,480
We've gone through a lot of ground.

924
01:02:16,140 --> 01:02:17,940
Is there anything else?

925
01:02:18,900 --> 01:02:21,320
Well, actually, one more question about Azure HorizonDB.

926
01:02:22,000 --> 01:02:24,900
If somebody wants to spin up on it, they've never heard about it before.

927
01:02:25,320 --> 01:02:27,520
Maybe they are a database practitioner.

928
01:02:27,720 --> 01:02:28,260
They're not a user.

929
01:02:29,240 --> 01:02:35,400
But they're thinking about whether they want to work on change companies or work on a database

930
01:02:35,540 --> 01:02:35,860
or whatever.

931
01:02:36,260 --> 01:02:37,220
Or maybe someone's a user.

932
01:02:37,700 --> 01:02:41,340
If they want to spin up on Azure HorizonDB, what's the best place to do that?

933
01:02:41,520 --> 01:02:42,740
Have you written a paper about it yet?

934
01:02:43,280 --> 01:02:43,700
Probably not.

935
01:02:43,840 --> 01:02:49,020
[PANOS] No, we have it, and that's on our to-do list, because there are lots of interesting new technologies we brought.

936
01:02:49,230 --> 01:02:53,200
Even though the architecture, fundamentally, is not brand new, there are lots of interesting,

937
01:02:53,500 --> 01:02:59,120
especially on the performance and reliability side, we've done a lot of cool innovation that we want to share.

938
01:02:59,140 --> 01:03:00,580
So hopefully that will come.

939
01:03:01,580 --> 01:03:03,780
In terms of reading, I think there were a couple...

940
01:03:04,100 --> 01:03:06,600
Adam gave a great talk at Andy Pavlo's.

941
01:03:06,710 --> 01:03:08,240
We should share that link.

942
01:03:09,500 --> 01:03:13,220
It's a part of the Carnegie Mellon database talk series,

943
01:03:13,540 --> 01:03:15,100
so there are lots of details there.

944
01:03:15,240 --> 01:03:18,140
And I think there was also a session at Ignite,

945
01:03:18,270 --> 01:03:20,020
like the Microsoft conference last year.

946
01:03:20,090 --> 01:03:22,220
But if somebody wants to go deep,

947
01:03:22,760 --> 01:03:26,160
this talk at Andy Pavlo's CMU database talk series

948
01:03:26,170 --> 01:03:28,740
is probably the best to go listen to and learn.

949
01:03:29,240 --> 01:03:30,980
For higher level things of course our public

950
01:03:31,180 --> 01:03:32,760
documentation covers a lot of

951
01:03:33,200 --> 01:03:34,960
ground but it's not going to go into the

952
01:03:35,010 --> 01:03:37,020
level of detail that was discussed there

953
01:03:37,020 --> 01:03:39,040
so it depends on what level of

954
01:03:39,700 --> 01:03:40,800
depth and detail

955
01:03:41,050 --> 01:03:42,880
people are interested in and hopefully

956
01:03:42,990 --> 01:03:44,800
a paper will come soon

957
01:03:45,120 --> 01:03:47,020
but we've been focusing a lot

958
01:03:47,120 --> 01:03:49,040
on releasing the product that we haven't

959
01:03:49,380 --> 01:03:51,100
had the chance to write it up yet but it's

960
01:03:51,200 --> 01:03:51,360
coming

961
01:03:52,020 --> 01:03:56,560
[CLAIRE] Got it. So I'm looking at the CMU database group talk, and I love these tech talks that

962
01:03:57,070 --> 01:04:04,300
the team at Carnegie Mellon, led by Andy Pavlo, has done for years now. Even during COVID,

963
01:04:04,740 --> 01:04:12,180
they were called the vaccination series. Anyway, so the talk is titled HorizonDB,

964
01:04:12,460 --> 01:04:15,340
Co-designing PostgreSQL and Azure for Cloud-Native OLTP.

965
01:04:16,480 --> 01:04:18,660
So we will be sure to include that in the show notes.

966
01:04:19,080 --> 01:04:20,220
It's a great shout out.

967
01:04:20,220 --> 01:04:23,300
And if I can find the Ignite talk that Adam Prout,

968
01:04:23,390 --> 01:04:26,880
I think he co-delivered that maybe with Denzil Ribeiro.

969
01:04:28,060 --> 01:04:31,260
I will include that one as well for anyone who wants to learn more.

970
01:04:30,140 --> 01:04:30,320
[PANOS] Yep.

971
01:04:33,320 --> 01:04:34,820
But it's Postgres, just a quick remark.

972
01:04:35,090 --> 01:04:38,060
You know, there are lots of internal implementation details.

973
01:04:38,430 --> 01:04:41,780
And again, people who are interested into that, I'm sure they will love the talks.

974
01:04:41,870 --> 01:04:45,400
But at the end of the day, the intent is for this to be Postgres, right?

975
01:04:45,540 --> 01:04:51,980
So as a user or even, you know, a DBA, there will be some nuances that you may want to understand.

976
01:04:52,080 --> 01:04:54,560
But to a very large extent if you're familiar with Postgres,

977
01:04:55,060 --> 01:04:58,440
it's just another hopefully more performant, more reliable,

978
01:04:58,650 --> 01:05:02,180
just better service in terms of the storage architecture and so on.

979
01:05:02,300 --> 01:05:06,820
But the surface and how it behaves and operates is still Postgres,

980
01:05:07,020 --> 01:05:09,020
so any knowledge there applies.

981
01:05:12,460 --> 01:05:18,980
[CLAIRE] Take shortcuts and we like to slot something new into a mental model that we're already familiar

982
01:05:19,380 --> 01:05:24,440
with. And I hope my boss doesn't shoot me for saying this, but to my mind, I think of Azure

983
01:05:24,700 --> 01:05:31,140
HorizonDB as Postgres with a shared storage architecture. That's the model I have in my mind.

984
01:05:32,740 --> 01:05:37,540
[PANOS] Yes, that's exactly right. That's exactly right. Shared log, shared storage. You're exactly right.

985
01:05:37,560 --> 01:05:38,560
That's what it is.

986
01:05:38,840 --> 01:05:42,140
And we're just trying to leverage this more modern primitives

987
01:05:42,180 --> 01:05:45,100
of the storage layer to just boost Postgres even further.

988
01:05:45,340 --> 01:05:48,000
But functionally, it's still the same, as you said,

989
01:05:48,280 --> 01:05:49,800
with disaggregated shared storage.

990
01:05:50,620 --> 01:05:57,880
[CLAIRE] Okay. So the point of today's episode, the focus of the discussion is working on Postgres

991
01:05:57,940 --> 01:05:59,500
after 13 years on SQL Server.

992
01:05:59,890 --> 01:06:01,180
And we've covered a lot of ground

993
01:06:01,440 --> 01:06:02,420
from your origin story

994
01:06:03,100 --> 01:06:04,780
through your perceptions of Postgres,

995
01:06:05,540 --> 01:06:07,360
comparisons to SQL Server,

996
01:06:08,040 --> 01:06:09,840
and then the work that you're doing today,

997
01:06:09,950 --> 01:06:11,360
which is on Azure HorizonDB.

998
01:06:13,000 --> 01:06:15,160
Is there anything else I should have asked you

999
01:06:15,280 --> 01:06:16,160
that I forgot?

1000
01:06:16,760 --> 01:06:19,260
Something about any interesting stories.

1001
01:06:19,470 --> 01:06:21,160
I'm curious actually

1002
01:06:21,400 --> 01:06:23,440
about how you made the decision to do this.

1003
01:06:24,220 --> 01:06:26,359
Did someone have to twist your arm

1004
01:06:26,740 --> 01:06:30,600
or did you have to go twist somebody's arm to let you make the switch?

1005
01:06:30,810 --> 01:06:31,900
What was that like?

1006
01:06:33,000 --> 01:06:36,180
[PANOS] No, I don't think it was either or it was a good coincidence.

1007
01:06:36,380 --> 01:06:40,520
You know, I'm always interested in learning new things and new technologies.

1008
01:06:41,200 --> 01:06:46,539
And there was the great timing that we were really ramping up the HorizonDB investment because

1009
01:06:46,540 --> 01:06:50,480
I think there was full alignment all across the leadership team

1010
01:06:50,640 --> 01:06:54,580
that there is a good opportunity. Postgres has been doing extremely well in the

1011
01:06:54,680 --> 01:06:58,280
market and we feel we can really release a service that

1012
01:06:59,080 --> 01:07:01,960
makes it stand out. So the timing was great.

1013
01:07:02,340 --> 01:07:05,860
It was neither, I guess. It was an easy conversation. There was a

1014
01:07:06,100 --> 01:07:09,580
business need. There was a personal interest. So it was a good timing to

1015
01:07:09,920 --> 01:07:13,920
go make that change. And hopefully, I learn new things. I also

1016
01:07:13,940 --> 01:07:18,980
bring some interesting perspectives from my background. So it's a win-win I think for

1017
01:07:19,400 --> 01:07:21,660
both sides. So it was a very smooth transition.

1018
01:07:22,660 --> 01:07:27,320
[CLAIRE] Speaking of your background, one of the things that you and I have in common, we're

1019
01:07:27,400 --> 01:07:32,640
recording this live, by the way, and there's a Discord parallel text chat that happens while we're

1020
01:07:32,640 --> 01:07:38,560
doing the recording. But people are only hearing audio. We publish this podcast only with audio.

1021
01:07:38,980 --> 01:07:46,340
But while you and I are talking, we can see each other on video because we're using another tool to

1022
01:07:46,500 --> 01:07:51,579
do the recording. Anyway, the point is my background graphic behind me as we're talking

1023
01:07:52,000 --> 01:07:58,560
is taken at an island in Greece in the Dodecanese, where I like to go sailing every summer. So,

1024
01:07:58,780 --> 01:08:02,980
well, sometimes we go sailing in the Cyclades, and sometimes we go in the Dodecanese, because

1025
01:08:03,200 --> 01:08:07,540
I'm half Greek. And that is one of the things that you and I have in common, because for anyone

1026
01:08:07,590 --> 01:08:14,220
who knows accents, you have a Greek accent, because you're 100% Greek, as far as I can tell.

1027
01:08:10,920 --> 01:08:12,340
[PANOS] Yes, I do.

1028
01:08:14,820 --> 01:08:15,620
Yes, that's right.

1029
01:08:15,900 --> 01:08:17,580
That's awesome.

1030
01:08:17,900 --> 01:08:21,960
I didn't realize this was from Greece, but it's a really nice background.

1031
01:08:21,920 --> 01:08:27,720
[CLAIRE] This is Kalymnos, and there's a bay there called Vathi, which of course means deep in English. And

1032
01:08:27,720 --> 01:08:32,580
it is, as you can see from the cliff behind me. And if I lean over, you can see that that's my

1033
01:08:32,799 --> 01:08:39,100
husband swimming in the water there.

1034
01:08:33,819 --> 01:08:34,380
[PANOS] Oh, wow.

1035
01:08:34,660 --> 01:08:35,359
Very nice.

1036
01:08:37,140 --> 01:08:38,060
No, that's awesome.

1037
01:08:39,130 --> 01:08:40,480
[CLAIRE] Anyway, so have you ever been to the Dodecanese or do you go to other places?

1038
01:08:40,900 --> 01:08:42,420
[PANOS] I don't think I have, interestingly.

1039
01:08:42,640 --> 01:08:44,819
I think I mentioned earlier, I'm not a big traveler.

1040
01:08:45,020 --> 01:08:47,200
Many people will be frustrated with this.

1041
01:08:48,000 --> 01:08:53,420
And in Greece, standards, as you're saying, the Dodecanese are like,

1042
01:08:53,850 --> 01:08:56,940
okay, maybe you can fly, but there are many hours of boat ride.

1043
01:08:57,180 --> 01:08:59,259
So I have never been that far.

1044
01:08:59,880 --> 01:09:01,520
So I've been to many islands closer.

1045
01:09:01,650 --> 01:09:04,759
You mentioned the Kiklades or Cyclades in English, I guess.

1046
01:09:05,500 --> 01:09:06,580
But not in Dodecanese.

1047
01:09:06,680 --> 01:09:09,339
Now I'm very motivated with your nice picture.

1048
01:09:09,830 --> 01:09:10,859
It seems really cool.

1049
01:09:11,020 --> 01:09:12,480
So it's definitely a place to visit.

1050
01:09:12,620 --> 01:09:15,620
And yeah, people in the audience, if they haven't,

1051
01:09:16,160 --> 01:09:17,740
definitely it's a worthwhile destination.

1052
01:09:17,759 --> 01:09:22,339
[CLAIRE] So do you have a go-to island that is your favorite place to go in the summer?

1053
01:09:23,180 --> 01:09:26,040
[PANOS] Yeah, I mean, Paros has been my main island

1054
01:09:26,339 --> 01:09:28,819
because mainly because I enjoy windsurfing so much.

1055
01:09:28,920 --> 01:09:30,440
It's a good destination for that.

1056
01:09:30,600 --> 01:09:34,440
So yeah, I used to go since I was maybe eight years old

1057
01:09:34,620 --> 01:09:35,180
with my father.

1058
01:09:35,460 --> 01:09:37,440
It has changed a lot over the years,

1059
01:09:37,700 --> 01:09:39,600
but it's still a good place to visit.

1060
01:09:39,720 --> 01:09:41,760
So I'm trying to go there as much as I can

1061
01:09:41,779 --> 01:09:43,480
and enjoy some time in the water.

1062
01:09:45,500 --> 01:09:52,380
[CLAIRE] So when we sail in the Cyclades we start in Paros always and it's an absolutely beautiful

1063
01:09:52,600 --> 01:09:58,140
island and a lovely spot and one of these days my daughter has done some open water swimming like

1064
01:09:58,300 --> 01:10:05,600
she swam all the way across Lake Tahoe once so I'm hoping that she organizes one of her swim clubs to

1065
01:10:05,620 --> 01:10:12,140
go do. There's often been a swim from Antiparos to Paros, like an open water swim race that happens

1066
01:10:12,210 --> 01:10:18,540
like in July each year. And I don't know if it's happening this year. But if one of these days in

1067
01:10:18,620 --> 01:10:23,900
the future, I'm hoping that they organize that. And then of course, I'll just have to go in order

1068
01:10:24,060 --> 01:10:35,440
to cheer her on. So. Hopefully. Well, they better.

1069
01:10:25,320 --> 01:10:26,420
[PANOS] Yes, that would be awesome.

1070
01:10:27,160 --> 01:10:30,600
And it's not too far, so hopefully people can cross

1071
01:10:30,740 --> 01:10:33,060
the channel there and make it to the other side, yeah.

1072
01:10:37,900 --> 01:10:45,980
[CLAIRE] All right. Well, Ευχαριστώ πάρα πολύ, which means thank you very much for joining the show. I speak Greek like a four-year-old

1073
01:10:45,980 --> 01:10:51,720
or a five-year-old. I have a very limited vocabulary.

1074
01:10:47,460 --> 01:10:48,500
[PANOS] No, that was pretty good.

1075
01:10:51,830 --> 01:11:03,100
[CLAIRE] But yeah, I really appreciate you coming on and sharing your story with all of us. Thank you. All right. So thank you to Panos Antonopoulos for joining us.

1076
01:10:53,780 --> 01:10:55,600
[PANOS] No, no, thank you again for inviting me.

1077
01:10:55,620 --> 01:10:58,140
I hope people learned something from it.

1078
01:10:58,140 --> 01:10:59,880
And yeah, super excited to be here.

1079
01:11:03,120 --> 01:11:07,860
[CLAIRE] And if you are listening and you liked today's episode and you

1080
01:11:07,940 --> 01:11:13,640
want to hear more of these Talking Postgres episodes, you should subscribe on Apple, Spotify,

1081
01:11:13,960 --> 01:11:18,840
YouTube, or wherever you get your podcasts. And please tell your friends because word of mouth

1082
01:11:19,020 --> 01:11:24,500
is gold in the podcast world. You can get to past episodes and get links to subscribe

1083
01:11:25,180 --> 01:11:30,980
on all the different platforms by going to TalkingPostgres.com and you'll see transcripts

1084
01:11:31,000 --> 01:11:36,680
included on the episode pages on TalkingPostgres.com too. A big thank you to everyone who joined the

1085
01:11:36,820 --> 01:11:40,520
live recording and participated in today's text chat on Discord.