Talking Postgres with Claire Giordano

CLAIRE: 00:00:05
Welcome to Talking Postgres, a monthly podcast for developers who love this database. I'm your host, Claire Giordano, and in this podcast, we explore the human side of Postgres databases and open source, which means why do people who work with Postgres do what they do and how did they get there? I want to say thank you to the team at Microsoft for sponsoring this community conversation. Today's guest is Panagiotis Antonopoulos, who many of us call Panos. He is a distinguished engineer at Microsoft who has worked on database technologies for 15 years now, specifically cloud databases and distributed systems. Panos spent his first 13 years on SQL Server. He has a master's in computer and electrical engineering from the National Technical University of Athens. And he's not only a really effective technologist, but a super interesting one, which is why I wanted to have him on the show. Welcome, Panos.

PANOS: 00:01:04
Hi Claire, really nice to be here. Thanks so much for inviting me.

CLAIRE: 00:01:08
Today's topic is going to be working on Postgres after 13 years on SQL Server. People are not necessarily intended to work on the same database technology their entire career, but I still find that transition from one database to another to be interesting. And so I thought we could kind of dig in and explore that a little bit today. [Yeah, absolutely.] So you've listened to some of our episodes. I know that you did your research before saying yes to the invitation to be on the show. So you probably know that we often start with asking, what was your origin story as a developer? And then we can get into your origin story as a database practitioner.

PANOS: 00:01:55
Sounds great yeah and it's not super diverse so you know I finished high school and I was actually thinking of studying mechanical engineering because I was into racing radio control cars and I really enjoyed the mechanical aspect at the time but I thought that you know electrical engineering computer science were really hot at the time so I thought okay you know I may as well try that. And I started more looking into networking and telecommunications, things like that. Not so much into software or hardware initially. I hadn't realized I liked it so much until I started taking some more courses. And that's when I decided that I really enjoyed like especially software. So yeah, I switched my major to be completely software engineering, computer science. So I graduated from college and I was lucky enough at the time there was a recruiting event happening right in Athens where I was studying. There was the SIGMOD conference, one of the biggest database conferences. Many people here may be familiar. So I was again, the timing was great because it was, I think it was the only year it has happened in Greece and it was the year I was graduating. So I decided to attend there and that was it. Like I was hired and joined Microsoft. That's my early career journey, I guess.

CLAIRE: 00:03:12
Okay, so wait a minute. Conferences like SIGMOD can be super overwhelming, even to people who are experienced in a field, right? There's different tracks, probably different talks. How do you know what to go to? What was that experience like? Or did you go to SIGMOD just to participate in the recruiting event?

PANOS: 00:03:31
Yeah, so it was a little bit of... You're absolutely right, first of all. Even now, after all these years I've attended maybe even 10s at this point of this conference they can still be overwhelming as you said there are so many interesting sessions running in parallel it's really hard to pick and even when you join one imagine people from academia I've been spending one or two years on a specific topic they're presenting it in 10 minutes their whole research is presented it's such a short amount of time so it's very hard to absorb all of that. That was my first, very first conference, so it was a mix of both. I wanted to attend it because I was actually doing my thesis on data management. So it was relevant for me. But the recruiting event was definitely a big part of why I definitely wanted to be there. So I picked some sessions and even now, it doesn't really matter. You go there mostly to network to understand what are the main topics being discussed. And then for anything that seems interesting, you have to go back and really read the papers and understand, really invest the time. There's no way you can understand everything in such a short time, but you just get homework effectively when you go back home. So that was the same thing back then. Hopefully now I can absorb a little bit more, but still the pattern is the same.

CLAIRE: 00:04:47
And you landed a job as part of the recruiting event that happened at SIGMOD. Was that with Microsoft?

PANOS: 00:04:54
Yeah, it was with Microsoft. And at the time, again, because it was a SIGMOD recruiting event, it was specifically with databases. So that there were a lot of good coincidences at the time, like I was into data coming out of college and the recruiting event was specifically from the SQL Server team. It was at the time before the transition to cloud. So that's why I say SQL server, not Azure SQL database. So it was really, we started and that's part of my career journey, maybe good to discuss some more as we go. But, you know, we started from the on-premises, what we call box SQL Server that we sell to customers and they run in their own environments. And then later we transition to the whole cloud service. But yes, it was with Microsoft. It was with SQL Server.

CLAIRE: 00:05:38
Got it. And this was in Athens, obviously. So did you start off working on SQL Server in Athens or did you move to somewhere else?

PANOS: 00:05:48
No, it was like a job for Redmond, in Seattle area for the headquarters. So it just happened that the event, the recruiting event was there. And a few people from Southern Europe, Eastern Europe came over to just interview. But all the position was from Seattle. And actually, that's an interesting story because I'm not a big fan of traveling. I've been to a few countries before. But in just a few days, I decided after having lived for 23 years in Athens, in my home, you know, where I grew up just to take a plane to a place I've never visited before and come over to Seattle Redmond area and join Microsoft. So it was really big adventure, but it just felt right. So I immediately signed and, you know, a couple of months later when visas and everything were ready, I just flew over to Redmond.

CLAIRE: 00:06:38
Okay, so you did fly to Redmond, though, as part of the interview process. No.

PANOS: 00:06:47
No, not as part of the interview. They were there from the databases team. But then the interview finished, I was hired, I signed online I guess. And then when I flew, I really flew. I had never seen the place until a week before my starting day. So it was very new.

CLAIRE: 00:07:03
Oh my goodness. And you went from a place that is sunny and warm most of the year, except maybe in the dead of winter. And just beautiful blue sky and gorgeous landscapes too cold and rainy and cloudy.

PANOS: 00:07:19
Yes, more cloudy. Yeah, I didn't know that. I had done very little research. I was just super excited. It was the domain I enjoyed. It seemed like a great opportunity. I didn't think of any of that. I also am a big fan of windsurfing. It's a thing I cannot miss. And I didn't even know if there is a place to windsurf. I just thought, okay, that seems the right opportunity to take. So I didn't even think about anything. I just jumped on it and off I am.

CLAIRE: 00:07:48
Well, at least in the Seattle area, you are near the coast. You still have beautiful vistas. You have the ocean. You have the islands nearby. It's just maybe the temperature's a little different, but it's still a beautiful place.

PANOS: 00:08:01
That's right. Temperature and precipitation is very different. Yes. But generally, it's definitely a very beautiful place, but it is a change for sure from even the culture and the climate. There is definitely a difference there. But it's still yeah, I really have enjoyed it all these 15 years as you said that I've been here.

CLAIRE: 00:08:22
So I want to obviously the podcast is called Talking Postgres and so most of our listeners have an affection for or actually work on Postgres. But before we dive into your transition onto it, is there anything I should know or understand about what parts of the database you worked on the most during your SQL Server and Azure SQL DB tenure? Are you a specialist of some kind or more of a generalist?

PANOS: 00:08:51
I would say a generalist. I've worked quite a bit across the stack. So I worked a lot in what we call metadata, like schema management, effectively, which also includes index management. And it's a fairly complex area about how you manage all the schema of users and how you build indexes and so on. And then I moved over to security. So I spent a few years on security, working on some new technologies we built there. I'm happy to share more. But then eventually, I ended up working a lot in storage. So I think I would say I'm somewhat of a generalist. I haven't spent as much time in core query processing and especially query optimization. I would say maybe one of the areas I haven't had as much expertise. But outside of that, I have fairly good understanding across the stack on operational database to some degree analytics, too. And the same, I mean, talking about Postgres, we'll discuss more. But I've followed similar route on the Postgres side after I transitioned.

CLAIRE: 00:09:54
And then obviously these days you're a distinguished engineer and I imagine but I don't know if this is true that you spend some time mentoring other people architecting solutions your job is probably quite different than it was when you started you know 15 years ago what was that like that transition from being an individual contributor to becoming more of a technical lead to you know, not just being responsible for your own work anymore.

PANOS: 00:10:25
Yeah you know that's a good question and like I one positive thing is it doesn't happen overnight you know there are many levels you have to go through so you know it's each one of them is a step up and gets you closer to you know the other end of the spectrum that you called out. 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. 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. So, you know, over time, stretching this further and further, it ended up in where I am today. So it was more of a continuum, I would say, where you, you know, even for people in their early careers, as they're trying to stretch more and more and grow their expertise, grow their impact across the product, you know, they will find themselves having bigger influence, bigger scope, and then eventually grow into more senior roles.

CLAIRE: 00:11:44
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.

PANOS: 00:11:52
Yep. Correct.

CLAIRE: 00:12:00
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. Is there anything that I should ask you about there? Are there any stories there?

PANOS: 00:12:17
Yeah, I mean, again, we can spend a lot of time on it. It has definitely a very interesting journey. Interestingly, at the time we called it Azure SQL. It was one of the first cloud services of Microsoft and maybe even across the industry. 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. So it definitely was a super interesting journey. I think none of us really knew what cloud meant. Even at the time, there was a clear distinction. We were building databases and other people were operating them. These lines have blurred a lot through this time of getting into the cloud. We have to operate very large portions. We are part of running the database. Of course, there is part of the application and administration happening on the customer side. But we own a lot of the stack from the infrastructure, storage layout. So there is definitely, you know, we had to expand our understanding and operationalizing a lot of the aspects of the database that we hadn't thought of before. Earlier, we're just building something, writing it on a DVD and customers would be running it on their site. Definitely cloud had us to stretch a lot to understand what it means to operate the database, especially at scale with the right availability and performance that our customers expect.

CLAIRE: 00:13:56
Okay, so is it fair to say that in your later years on SQL Server, Azure SQL DB, that you were focused primarily on the cloud versus the box?

PANOS: 00:14:07
That's a good point. Yeah, I didn't call that out, but you're absolutely right. It felt more natural at the time, but the whole organization and the company as well switched to that model. So we switched from writing software and giving it to customers to operate in cloud services. So all of the things I mentioned, they were very frequently motivated by cloud. Just to give some examples, right? I worked on resumable indexing operations. So there are indexing operations, and I'm sure it's the same in Postgres, that they can take many hours. On-premises, that was kind of okay because the environments are extremely stable. The connections are extremely stable. Even if it takes 10 hours to complete, usually it will complete. In the cloud world, there are always glitches. 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. So we did the work to make that resilient to transient failures and allow it to resume from where it was. Or some of the confidentiality or data integrity work that we did on the security space. Again, in the on-premises environment, they're very locked down. They have customers have full control. Very few admins have access. So it's a much more protected environment. 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. 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. 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. So you're absolutely right, Claire. Yes, all of this work, even though it mostly, to a large extent, remained in the core database, it was really done for the world of Azure and the world of cloud, where things are not as resilient always as they are in a very locked-down on-premise environment.

CLAIRE: 00:16:17
You just mentioned the name of the capability, and I want to make sure I caught it right. Did you say constant time recovery?

PANOS: 00:16:23
Constant time recovery, that's the name of the paper we published. The public marketing name is Accelerated Database Recovery. And interestingly now, coming to the world of Postgres, it's something Postgres has been designed with from day one, whereas SQL Server was very different in how it did database recovery. So yeah, we had to innovate that. It's still not like Postgres, it's different, and that's what made it interesting. We had to invent something new, but effectively bringing similar promises as Postgres that it can recover in a much shorter window than it could before.

CLAIRE: 00:17:01
Okay, Panos, you just gave me the perfect introduction to ask the next question, which is I want to get into what it's like to work on Postgres after 13 years working on Azure SQL DB. And obviously, when you start working on a new database, part of your perspective is going to be influenced by what you're already familiar with. So I'm expecting some comparisons here, at least as they affected you and your work personally. But what is it like to work on Postgres after 13 years on SQL Server?

PANOS: 00:17:35
Yeah, one thing that was interesting to me is that at the high level, it feels extremely familiar. You know, once you get to the code, of course, and the exact features, there are differences. But the concepts are very similar. You know, how transactions work, how storage works. So of course, again, in the lower level details, there are substantial differences in how storage layout is in one versus the other, how exactly transactions are managed. But the concepts are extremely similar. So that was one thing that felt good. It was that I felt that all the expertise I had built was very relevant. I could quickly ramp up, engage in complex technical discussions. Of course, I didn't know every line of code by any means, but at least I could very quickly understand how things work and contribute meaningfully to our designs. Now, coming to the lower level, I would say there is definitely a big difference between what SQL has and Postgres. SQL is like, you know, over the years we have accumulated and added a very large set of features that customers have been asking for. So then this has pros and cons. I mean, even now after working on Postgres and how much I love Postgres the past couple of years, like SQL is very complete as a product in terms of you know, whether it's columns or indexes, advanced security features, like some of what I mentioned, or even the thread concurrency model that it has. It's really you know, pretty fascinating product. But because of all of that, you know, there has definitely been a layer of complexity in the code base, in our test cases and collateral, you know, everything has grown over time and has become more complex. Postgres feels a little bit on the other end of the spectrum. You know, it has all the basic capabilities one would expect on the database. It's still, I feel a little bit behind. I hope the audience here doesn't hate me for that. It feels a little bit behind on some of the more, you know, fancy, more complicated features that enterprise customers expect. But the benefit of that is like the committers have done an amazing job keeping the core engine extremely lean. So with that, you know, you can read the code. That was a shocking experience for me. I could understand new areas in Postgres much faster than I could for SQL. So, you know, that was definitely, you could see that the architectural cleanliness, I guess, of Postgres really stands out. And then the extensibility framework really goes a really long way. So people have been able, without introducing this complexity that I mentioned from SQL, they have been able to add significant features that have helped Postgres gain a lot of momentum with developers or other scenarios so yeah that's I would say at the high level my comparison so far.

CLAIRE: 00:20:21
Yeah, I hope nobody gets pissed off that you used the phrase. It's still a bit behind. But I think if I talk to anybody I know that works in Postgres, I mean, there are things they want for Postgres that are being worked on in some cases or being talked about in other cases. [Exactly.] And so I think people will agree with you that there are new capabilities and problems that we want to solve. Like Postgres isn't done yet. It's still evolving and every release gets better.

PANOS: 00:20:46
Of course. Exactly.

CLAIRE: 00:20:49
So that's the positive spin to try to restate what you just said.

PANOS: 00:20:54
No, for sure. For sure. And Postgres has proven it can close the gap very quickly. And that's why all of the industry is building Postgres-based services. So absolutely, yes. Behind means that there is a clear path to catch up. So yes, Postgres is on it. And we from Microsoft are on it as well, by the way, with Postgres. So, yeah.

CLAIRE: 00:21:16
Do you have a perspective on why Postgres is so popular?

PANOS: 00:21:23
Yeah, so maybe I'm not necessarily the best in the sense I don't have, maybe you or others have even more context on this. My take is it feels like good enough it's open source right so it has built the trust of the community and the open source and then it's like for a very large set of scenarios it's good enough you know even many of the things that I mentioned and even I worked on the really high-end features like you know that the top of mission critical and high security workloads really need but the vast majority doesn't so Postgres has made a great you know made progress over the past years, catching up with all the core database fundamentals. It performs very well for normal scenarios. So, you know, even when I was thinking of transition, I was doing some research of why people love it so much. And that seemed to be the sentiment. People seem to be saying, you know, why not? Right? You know, Postgres is actually, it's free if you use it as an open source product. It's actually fairly cheap, even in the cloud services and then it just delivers what you all the basics you need so unless you have a super like niche or complicated case people seem to feel that it's good enough now again you know I've spent a lot of time on SQL Server so it's definitely a lot of goodness there but that seems to be the consensus at least for you know all the normal scenarios until you get into higher end more mission critical Postgres does an amazing job so that seems to me to be the biggest motivation together again with all the community extensibility allowing people to use their features they love easily there.

CLAIRE: 00:23:01
I think trust is a really important thing to think about. What does it mean to trust a database with your most important data, whether it be financial or, you know, think of retailers, think of, I mean, there's so many scenarios where people put, and what could be more important than the data you're trying to protect and that you're trying use to facilitate your business or your research or whatever. And so I sometimes wonder about, well, why is it that people trust Postgres? And I do want to give a shout out to all of the committers and the contributors and the community members, because part of trusting a technology is trusting the people behind it and the team behind it and the processes that they use to ensure quality. And I don't know, that's how I think about it. I'm not sure what your perspective is but...

PANOS: 00:23:54
No, you're absolutely right. Yes, in databases, trust is a huge thing. And you're right, like, you know, I was kind of taking it for granted coming from the SQL Server world. But you're absolutely right in an enterprise, sorry, in an open source, you know, area, it's really the committers that are responsible for that. And they have done a great job, you know, year over year, really establishing trust, making sure that we don't have data corruptions, we don't have data losses right so yeah absolutely trust is a very big part of it.

CLAIRE: 00:24:28
And what's interesting too, I was thinking about it the other day, in an enterprise, people who were engineers who work on the database, you're not often, well, maybe you'll disagree with me on this, but usually you have PMs that you're working with, right? You're not doing the PM job as well as the engineering job. But when I think about committers and people who are working on an open source project, oftentimes in the same person, they are working on engineering, they are doing their own PM work, they are doing community work and education work, you know, they're helping organize a conference or giving a talk or whatever. There's so many different functional jobs being done by the same people. And it's just different. And I wonder sometimes if people appreciate that or realize it.

PANOS: 00:25:18
No, you're absolutely right. Actually, it's a good thing to call out. Interestingly, my experience has been somewhat similar because I was always very motivated to pursue the product angle like you know participate in understanding customer scenarios requirements figure out what are the things that we should be building to solve the customer pain points but you're right that is not the norm right in an enterprise there is more clear role distinctions to a large extent between engineering and product management and that's not the same in the open source you're absolutely right that the same people have both to think what needs to be done you know as well as go build it so it's definitely there is a multi-persona responsibility there which is definitely complex to navigate.

CLAIRE: 00:26:04
I wonder, do you think that's part of why you're a distinguished engineer? Not everybody becomes a DE after 15 years. So is it, has, do you feel like that interest in the customer scenarios and meeting with customers and understanding those requirements has influenced your engineering work? It must have.

PANOS: 00:26:27
I think so. I always try to understand the big picture of things rather than own a very specific thing, deliver it and be done. I wanted to see things end to end. So from the early days of understanding the customer problems, all the way to building the whole architecture and getting in production, I think this trying to have a broader scope, broader understanding of the problem rather than focusing on something very specific, I think definitely goes a long way. So, yes, I think I would say this definitely helped me over my career.

CLAIRE: 00:27:07
Okay, so let's talk about Postgres. What aspects of Postgres do you really like?

PANOS: 00:27:14
Yeah, I would say the code cleanness is the main, the biggest thing. I like the architecture and code cleanness is amazing for Postgres. I think I already mentioned that, at least for me, I could more easily understand new code in Postgres than in SQL even after all this time. That means a lot. So now I'm talking more from the internals. We should discuss also from the, maybe as a user of Postgres. But as an engineer working from inside the code, definitely this is really important. Now, of course, we also make very heavy use of AI. So that also is a big component because now all the code is open source. All the mailing lists and so on are open source. So all the large language models have already picked up both on the code, all the discussions going on. So that's where the open source angle plays an important role because you can, first of all, the code is pretty easy to understand because of the great work that committers have been doing over the years. But also now AI can also take a big step in and bring even more understanding of using, again, both the code base as well as all the mailing discussions so you can understand why certain decisions were made and so, again, as an engineer, I would say that that is the biggest thing. I can easily understand and navigate and make progress in the code base. That helps a lot in the velocity. Maybe now coming as a user, I would say I think the extensibility has helped a lot. Maybe it's a bit both from user as well as coder perspective. But the fact that you can easily plug in things without having to make significant redesigns of the core engine, that is super critical. You can very quickly build extensions that provide the necessary functionality without having to modify the core engine, without having to go into gazillion architectural discussions about how this should happen. So yeah, this pluggability model and sensibility model is a huge, huge asset. So these are the main things I would quickly call out.

CLAIRE: 00:29:23
Is there anything that surprised you? Maybe you had the wrong perception coming in, or maybe because of your SQL database experience, you thought, just assumed things would be a certain way in Postgres, and then they were not.

PANOS: 00:29:39
Yeah, yeah, for sure. I mean, there are some things that I will call out maybe two things. Something that surprised me positively is just the raw performance of Postgres. For simple scenarios, it just performs extremely well, whether it's bulk loading data or simple select queries or whatnot. And I'm still trying to wrap my head why that is. I think it's mainly because of, again, it goes back to the simplicity that we've been discussing. It's just what we call the code path length. It's just less code to execute. So you can actually get to the important part of fetching the data faster. So that's definitely one thing that surprised me positively. Maybe something that surprised me, not necessarily, I wouldn't say negative, but more, as you were saying, there were certain, like I was coming with certain mindset that specific things in the database world are given. And, you know, I was surprised Postgres doesn't have is definitely, for example, like using processes instead of threads for new connections. That was something I was assuming it's, you know, threads are always the default just for performance and scalability or the problems around the wraparound of the transaction ID, it's a problem that we've generally tried to solve in other systems. I was assuming that for a product that is so broadly adopted and has become ubiquitous to a large extent for many workloads, I was expecting some of these table stakes things like problems that have been solved in the industry to be solved and there's still big problems of Postgres. Of course, I understand that it's not easy to go fix them and big backward compatibility and other issues. So I understand the challenges but I still I would still say I was surprised when I saw some of these more solved problems in the industry still be there.

CLAIRE: 00:31:28
For anyone listening who is new to Postgres, please know that there are people in the Postgres open source project who are absolutely working on multi-threading. I can't predict and I don't think there's a betting pool on what release that support would get added into. And I don't know if it would be added in any kind of phased way over time. But the discussions are certainly and the engineering work is certainly happening. So that's goodness.

PANOS: 00:31:55
That's great to hear. Yes.

CLAIRE: 00:31:58
But the future is still undefined, uncertain. I don't know what's going to happen when. Yeah. You mentioned multi-threading. Are there things in SQL Server that you hope Postgres gets in the future?

PANOS: 00:32:17
Yeah, so I mean, maybe I'll draw two categories. The product fundamentals let's call it yeah multi-threading is one like memory management is another thing that SQL I would say has done very well and has been increasingly important for the cloud especially for scenarios like serverless that have become extremely popular recently just you know as far as and again please anyone don't get upset at me if I misquote anything, but my understanding is that memory management is still quite rigid in Postgres, both configuration of it as well as the elasticity of it after the database comes up. So some of these things are becoming bigger and bigger problems that need to be addressed. And I'm sure that many of the companies working with Postgres, including ourselves, are paying attention and trying to improve this. I'm hoping a lot of this work will go back. If it's not initiated in the open source, it will also go back to the open source. So yeah, there are a few things on the fundamentals as we discussed like memory and scheduling and thread management and so on and then just and that's not necessarily a black or white it just speaks to what we're discussing earlier you know what level of scenarios or yeah what I don't know what to call it but you know as you get into more complex enterprise scenarios like you know better analytics support, whether it's again from columnstore for a better query optimizer. There are areas that if Postgres wants to address some of these higher end workloads, this will become increasingly important to address. Similarly on security, again, we have done some interesting work there. But you're starting to get into more specific things that not every workload in the world will need. But if you're really targeting the top few percent of workloads, these things are required. So it will be interesting to see how much Postgres starts pushing towards that. Now that they have covered the ground with all the basics, we'll see how much they also push into that. And we see similar things, I mean, even coming from the open source world with extensions and other things, showing that there is interest for column-oriented storage and so on. So, yeah.

CLAIRE: 00:34:40
If I roll the audio recording back a few minutes, you mentioned AI and AI tools a few minutes ago. Are you willing to share how, and you may not want to dive into this, but I'm always trying to learn from other people about how the AI tools are changing their day-to-day work. What do you do differently than what you did, say, three years ago. Now, of course, three years ago, you weren't working on Postgres yet. So you've had multiple changes in your life at the same time. But what can you teach me? Are there any AI hacks, if you will, that save you time?

PANOS: 00:35:24
I mean, this is also a journey. You know, I will answer today. If you ask me again in three months, I will have, you know, more complete answer on new things I'm doing. And if you asked me three months ago, it will also be different. But, you know, I would start from maybe let me explain a spectrum of how I would think about it. The very first thing is just understanding the code. Right. And that's where the example I used earlier, especially in the open source world, because the language models have been exposed to all of this data, whether it's the actual code base as well as a mailing list. 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, why they were designed that way.

CLAIRE: 00:36:04
Do you use the voice tools or are you typing still?

PANOS: 00:36:09
No I'm still typing I've heard conflicting you know opinions of how well the voice tools work and I've used it a little bit on ChatGPT it seems like to try and address conversational latency meaning that it really wants to respond in real time not even wait for one second so it seemed to be less the quality seemed to degrade a bit I've heard the same from others. So I've been typing. It's also easier, when looking at code, it's easier to copy-paste function names and variable names. So I've been doing that. But yeah, I haven't tried it for coding especially. I haven't tried the voice experience.

CLAIRE: 00:36:50
So back to the spectrum. Number one. Understanding the code and as well as the decision-making. [Correct.] And I'll just point out that someone said to me once that one of the things they loved about Postgres isn't just that it's open source, but that it's open decision-making. That because the mailing list is public, you can see the rationale and the reasons. And that, particularly to engineers who were just getting started, that's a huge treasure trove of insight that normally you don't get access to in the world of proprietary corporations. So it's kind of cool. All right. So that's number one. What else?

PANOS: 00:37:24
Yes. So the next step is like, you know, write code. And then we'll start from small things. You know, just as you're right, you have already decided how to write the code. And, you know, as you're doing the work, it will help you. And again, as we're exploring the spectrum, it can help you with small things. You know, whether it's some, I'll use some dummy example, but list traversal things or anything like, you know, granular code you need to write or test. It can do an extremely good job to write these things. And again, taking small examples here, just you have decided, you have designed things you want to execute on. It will help you do that. The next step is actually brainstorming on even the design. And the spectrum has also become broader as models have become more mature. So that's why I'm saying in three months, maybe my answer will even be more complete. But now you can actually brainstorm architectural decisions and trade-offs. And we need to be careful. And that's why I think our jobs are still safe, because somebody needs to verify that what the models are saying is true and make the right final decisions. We're still accountable. But really, they bring up a lot of good points and a lot of interesting trade-offs that you can do a lot less research to think about than you normally would do. So it expedites your work significantly. So now what I'm getting at is like you can actually brainstorm with it. You can co-design things with the models and come up with a design. So that's the next step. And now the final step I've been exploring, maybe two parts, like I've been exploring recently, and it's gone surprisingly well, is to actually do the brainstorming, come up with a design, come up with a plan all together with, you know, Copilot and AI. And now actually start executing without writing any code or extremely little code from my side. So if you go through the whole pipeline of co-designing, coming up with a plan together, and finally executing the Copilot or whatever tool you're using, like Claude, or of course we're using GitHub Copilot to the most extent, it just has enough context. So it can actually do a very good job implementing things and I'm not talking even about super small things, but even changing the storage design, for example, of your service, as long as you work with it and you break down the work with it, it can actually pick this up and execute very well. So I'm trying to get to a world where, to a very large extent, I'm able to use it as a peer in my team to go and build things together, and it will do a very large extent of the coding by itself. One other dimension, maybe now I talked a lot about the code and the development cycle. The other part and testing, the other part is the operationalization of it, right? You know, whether it's debugging test cases that failed in our pipelines or even live incidents in production, that's another area where we're pushing a lot across the team to leverage AI and reduce the toil. I'm sure nobody enjoys, you know, or at least almost nobody enjoys all these investigations and getting called in the middle of the night. So that's another area that we're trying to heavily leverage AI to go and help us with, whether it's test failures or even live incident investigations, expedite this and mitigate even automatically in many cases.

CLAIRE: 00:41:07
I take notes while we're talking. I don't know if anybody listening to this show knows that. So it makes it easier for me to remember exactly what you said, even rolling back five or ten minutes. And you mentioned that you're not so pleased with the latency on the conversational latency of the voice tools that you find with Copilot.

PANOS: 00:41:29
No, actually, I was trying to say the opposite. It seemed to optimize for low latency when you use the voice experience. And I think this degraded quality. So if you type it, it seemed to give you higher quality answer than if you talk to it. That's what I felt, at least. So they tried to optimize the performance, like the latency aspect, but I felt this degraded the precision of the response.

CLAIRE: 00:41:55
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.

PANOS: 00:42:08
Makes sense.

CLAIRE: 00:42:09
And people tend to be much happier with that result right now. Now, of course, in three months, it'll probably be very different because these tools are changing so fast. So who's to say?

PANOS: 00:42:18
Oh, that's great to know.

CLAIRE: 00:42:18
So I'll send you a link to one of those and you can see your mileage may vary.

PANOS: 00:42:21
Excellent. Thank you.

CLAIRE: 00:42:25
Okay, so let's get back onto Postgres and your transition from SQL Server onto Postgres after 13 years. You've made that transition as a practitioner, as somebody who works on the databases themselves. But you already said that you've spent part of your career thinking about users and user scenarios and things like that. So do you have any tips for developers or DBAs, people who run their apps on top of databases for making that transition from one database to another, whether it's Oracle to Postgres or whatever to whatever?

PANOS: 00:43:02
Yeah, I would still say a similar answer. That's my feeling, at least, that your high level skills are extremely reusable the concepts are exactly the same the high level problems are exactly the same so at least I found myself fairly quickly you know transitioning to this new world whereas if I had switched to a completely different domain it would have been whole other story. So I think people should not be super scared of making that jump. All your, you know, your core knowledge is still very, very widely applicable. Whereas of course, there's some differences is just as you start really getting into the weeds of specific performance debugging trouble or, you know, even maybe some very extreme nuances of concurrency control and subtle, you know, behaviors that concurrency control and isolation levels, for example, just may have between databases. I mean, this is unavoidable and it will be hopefully a small percent of your work. Otherwise, I mean, the SQL language is largely an ANSI standard. Of course, there are subtle differences, but it's mostly the same. The way you approach the problems, whether it's storage fragmentation, query performance troubleshooting or other things, again, they're very similar. The exact tools and exact behaviors may slightly vary but I would say that people should at least my experience has been they should be too scared of making the leap they can reuse their knowledge and of course they will need to learn some things but that's also what makes it interesting so yeah I would advise that they shouldn't yeah they should if they have an opportunity they should try to learn and that's what also what motivated me you know to move to Postgres like I had spent quite some time on SQL. I knew most of the internals. It was interesting to see a completely different system and understand how all this works, but having the fundamentals be reusable.

CLAIRE: 00:44:56
So, the fact that the fundamentals about those high-level skills and knowledge and everything are reusable, that's huge. But at the end of the day, people are going to have to skill up on the small things that are different, right? And that's work, right? That takes time. Although I suppose LLMs make it easier and faster. So it's perhaps an easier transition to make today than it would have been five years ago. I have had two people on the show who both started their careers more in Oracle and then ultimately moved into the Postgres space. Gwen Shapira and Jeremy Schneider. And one of the things that Jeremy Schneider created that Gwen gave a shout out to in her episode is this poster, if you will, called Postgres Happiness Hints. And it's chock full of those kind of just a bunch of tips about those small specific things that maybe somebody coming from Oracle, for example, should know about Postgres, about what default timeouts and limits would be a good idea, or kind of good logging best practices, or how to use connection pooling in Postgres and things like that. So I will include a link to the Postgres Happiness Hints in the show notes, just because I think for someone making that transition from another database onto Postgres, they're super useful. And Jeremy actually made it as a poster. He made it years ago, but he updated it this year and displayed it as a poster at PGConf.dev, which is the annual Postgres development conference that happens each year in Canada. So anyway, he got more feedback from people there who were in the room in the poster exhibit, and then he updated it again. So it's current.

PANOS: 00:46:49
Excellent. Oh, that's great. That sounds like a great resource. Yes, because you're right. I mean, these little details matter and you need to learn them. So it's it for that. It can go a very long way.

CLAIRE: 00:46:59
Now, we've had this whole conversation without me really understanding what in Postgres you actually work on the Azure side of things. So I'm assuming you're doing a lot of learning from the Postgres open source project. And obviously our Postgres offerings in Azure have a major dependency on the open source projects. They are the open source project then made available as a cloud service. But I don't actually really know exactly what you work on. I think you work on HorizonDB, but you've got to tell me. What do you do?

PANOS: 00:47:34
Yes so that's exactly right so hey and that was big part of the reason why I also joined the Postgres team yes so HorizonDB is my main priority and just for the audience maybe they're not as familiar with HorizonDB so it's effectively our take for a disaggregated compute and storage cloud-native Postgres offering in Azure so you know this compute and storage disaggregation brings many benefits. You can scale your storage. There are many terabytes, hundreds of terabytes of data. It introduces the primitive of shared storage. So you can scale out your read replicas without having to duplicate your storage and spin up new replicas in a few seconds rather than having to seed a whole new database. So performance, of course, also gets significantly better. So yes.

CLAIRE: 00:48:26
Wait, can you, I need you to explain that to me. How is it that you spin up new replicas in a few seconds just because you have shared storage?

PANOS: 00:48:30
Yes. Right, right.

CLAIRE: 00:48:36
What does that mean?

PANOS: 00:48:37
So let's maybe take a step back, right? How traditional databases have operated. The moment you need a new replica, it is an independent replica. It is independent in terms of its compute, but it's also independent in terms of its storage. So what this normally meant is that you have to take some sort of database backup, move it to your other replica, restore it there, and then catch it up, replay WAL records until it's fully caught up, and now it can serve all your read requests. That's the huge change in this disaggregated shared storage architecture, because now there is one single source of truth at the storage layer. Your primary database writes to that. It keeps track of all the latest pages. So the moment you need to bring up a new or many new replicas, all you have to do is bring up the compute. So just bring up a Postgres instance, and you can directly attach to this storage. So it's no longer a size of data operation. It's really just the time you need to take to spin up your compute and just bring up the database there. Attach, let me call it, the database there. So this allows you to bring up any number of replicas. It really gives you the elasticity. Say that you have some end-of-month reporting or whatnot, you can very quickly spin up a replica or multiple of them, do your reporting or other queries on the read replicas. And again, you don't have to pay for duplicate storage. You don't have to take the time to seed this new duplicate storage. So that's a huge benefit of these architectures.

CLAIRE: 00:50:07
So you were back to what it is that you do. Thank you for that little segue. It helped me understand. So you work on HorizonDB, disaggregated compute and storage, giving you the benefits of shared storage, such as spinning up replicas super fast. Tell me more.

PANOS: 00:50:24
Yeah. So I'll tell you more on both sides. So for Horizon, the goal is to effectively bring up this new generation of Postgres in Azure. And we're even looking at, as you said, we leverage the open source and we're also contributing back to the open source. But we also want to take it as much we can improve any gaps that the Postgres has. HorizonDB's mission is to do that. So our goal is to really serve enterprise workloads with HorizonDB. 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. Now, in terms of my own work, just naturally, most of the work so far has been in the core of storage, just because as we were just discussing, the first part is to really move from the normal traditional database architecture where compute and storage are fully coupled, move to this decoupled, disaggregated storage. Most of the work is in storage. So I worked a lot around the storage layer, whether it's recovery is one concrete area, I spend a lot of time on optimizing recovery in that new architecture, whether it's the management of people who may be familiar with the term SLRU pages, how we track committed transactions and other internal state. So I think it stands for simple least recently used. So it's a special type of pages that Postgres has that is tracking effectively internal metadata, commit state transaction identifiers for multi-state transactions and so on. There are different types.

CLAIRE: 00:52:09
Is that a Postgres term or an Azure term?

PANOS: 00:52:09
So yeah, it's internal method. It is a Postgres term. It is a Postgres term, yeah. So bottom line, I've spent a lot of time looking at the core of storage and redesigning it to fit this new architecture effectively. So that's the main part. Both myself as well as the rest of the team, storage has been our main focus so far. Of course, now we're also trying to bring new features around geo resiliency and customer-managed encryption keys to really meet the enterprise promises that Azure always has. So, but yeah, most of it is happening at the storage layer. As HorizonDB grows and we get into general availability and beyond, I'm sure we will invest in more areas, even query processing and so on. But for now, most of the team is focused on the storage side.

CLAIRE: 00:52:58
Now, we've also, I've been lucky enough to have had Adam Prout as a guest on this podcast. And the title of his episode was From MemSQL to HorizonDB, An Engineer's Journey. And we focused on his personal journey because he obviously was one of the founders of MemSQL, which is now called SingleStore. They rebranded a couple of years ago. But he's been at Microsoft again for his second tenure for a couple of years now and very involved in HorizonDB. So I imagine the two of you must work together closely. Is that fair to say?

PANOS: 00:53:31
Yeah, that's exactly right. We work together every day. So yes, that's also been a great collaboration so far. We're divided and conquered different areas of HorizonDB and it's been a really good collaboration. I think it shows up in the results of HorizonDB as well from availability and performance I think we've made really solid progress very fast so yeah Adam has been a great collaborator and he has as you said a lot of relevant experience for Microsoft but also you know more diverse background with MemSQL or SingleStore so yeah it's been great having his perspective and contributions.

CLAIRE: 00:54:12
Well, in his episode, we also went through his origin story. And before he was at SingleStore or MemSQL at the time, he also worked at Microsoft early days in his career. So did the two of you work together way back then?

PANOS: 00:54:29
No, unfortunately, I think I joined right after Adam left or around the time. I think maybe he was even gone by the time I joined. So I had never met him before unfortunately. But yeah, we got the chance to work together now. Yes, not in Microsoft though. Yeah, no, not before. I mean now in Microsoft.

CLAIRE: 00:54:45
Got it. So for anyone listening who's like, huh, I've never heard of HorizonDB, just some context. Azure now has two managed Postgres services. So the one that people are probably very familiar with, my gosh, they should have heard of it by now, is Azure Database for PostgreSQL. And I think of that as vanilla Postgres as a service. It is, you know, the Postgres technology from the open source project made available as a managed service with all of the kind of things you would expect from a cloud service added on top of the open source project. And now, of course, we also offer Azure HorizonDB. And if you haven't heard of it yet, that's because it's brand new. Brand new, not in the sense of it was just written last month, but brand new as in the product just GA'd. Well, that did just happen last month.

PANOS: 00:55:41
It's actually still in public preview. [Oh, thank you.] It is in public preview as of last month. So it hasn't even GA'd yet. So you're absolutely right. We have been spending a lot of energy for some time now, but yes, for anyone in the public, it is brand new.

CLAIRE: 00:55:55
I'm hitting my head against the wall. I know that. How did I get that wrong? Okay. People make mistakes. It's okay, Claire. You can handle it.

PANOS: 00:56:02
Yeah, don't feel bad. We have so many milestones.

CLAIRE: 00:56:04
But it was a big announcement last month. So obviously the foundations of Azure HorizonDB are Postgres. So it's built on top of the fact that this 30-year-old, 40-year-old technology. [For sure.] Shout out to the fact that this is the 30th birthday for the Postgres Open Source Project happening this summer right now. But the technology itself was created 40 years before. So yeah, it's not completely newfangled. All right, so that's what you work on. And that's what you've worked on for the last two years now? Is it more than that?

PANOS: 00:56:46
No, about one and one and a half year now. Yeah, still going. So it's been very interesting. I mean, as you said, there was a big announcement and that's because Postgres has gone a very long way in the industry. So, you know, we really want to stand behind it. We want to bring the best Postgres service in Azure. So that's our mission. So we released the preview last month, a public preview last month, and we're going into GA and so on. So it's going to be a journey and hopefully release a lot of cool things that people will be excited about.

CLAIRE: 00:57:20
I have a question for you, and maybe you can just help me get smarter on something. I'm going to be giving a talk at Postgres Summit US in September, which is a rebranded conference formerly called PGConf New York City, which is probably what a lot of people are familiar with that as it happens in late September, early October. Anyway, it is the first time I'll have given this talk, and it's called a secret decoder ring for Postgres replication. And it's a beginner's guide. And there are people in the world who know a lot more about Postgres replication than I do. But what I bring to the table is that ability to explain something in a beginner-friendly way. So that's my superpower. Not that I'm a deep [That makes sense.] Postgres replication expert the way that a lot of my teammates are. Because we have people, by the way in Microsoft who work full-time almost contributing to the open source project as committers and major contributors and things like that. Anyway, I'm just really curious, have you worked on replication much? When you think about replication, how do you compare SQL Server to what people see in Postgres, for example? Because one of the things that confused me when I was brand new to Postgres is I felt like there were all these different types of replication. There was logical, there's physical, there's streaming, there's synchronous, there's asynchronous. And it really confused my brain. So is it just a terminology problem or are there really that many different types of replication? And is that the same in other databases?

PANOS: 00:58:55
Yeah I will say it's both and I think it goes back to my earlier answer that the high level you know high level knowledge is reusable but then there are the specifics of office engine so unfortunately SQL Server also has the same history so maybe starting from the high level as you called out right to a large extent there are two types of replication there is logical replication where the replicator just translates the operations happening into some logical operations, like insert this row, update this row, delete this row, and they are logically replayed on the other side. So technically, the two instances, the two replicas don't even need to be exactly in sync or aligned in terms of the physical format, or in some situations, even the exact content of the table, they could even diverge potentially. And then there physical replication which is generally more performant because it's happening at the physical layer but it requires full effectively both replicas to be fully identical right so SQL has both as Postgres does SQL unfortunately on the logical replication side also has a very wide set of different replication technologies with subtle differences a lot of it is timing you you know, we released something, it had some trade-offs, and then we realized that there is another set of customers that require something slightly different. So, for example, you know, some logical applications require the tables to be identical, whereas others allow more flexibility, even allow updates to happen on different sites and try to consolidate them and resolve conflicts. So, yeah, there are, even on the SQL side, SQL Server side, there are a few different technologies. I'm not as familiar with all the Postgres details beyond, again, that there is, of course, physical and there is logical. So I can't comment if they are exactly one-to-one, but definitely both sides have both of these types of replication, physical and logical, used, again, for different types of scenarios. So physical is generally used. We use it also in HorizonDB to replicate data across our replicas. And what we're discussing, you can spin up a replica anytime this is also using physical replication to keep the replica up to speed and then logical replication is generally more flexible it's used in scenarios where you know the tables may not be fully aligned the schema may be slightly different so it allows a little bit more of this flexibility now comparing the two I would say one area that SQL should have spent a little bit more energy is logical replication that's where Postgres has done a better job it has become you know more and more interesting over the years. So yeah, Postgres has done a good job maintaining it. SQL now has put more energy back into it and it's the right thing to do. Both of them are needed. So you really need both physical to be extremely fast just because it's part of the core replicated services just for resiliency that every cloud service needs. But then again, logical replication gives the flexibility for other customer scenarios. So yeah, both are needed and both are important, just different in how they work.

CLAIRE: 01:02:05
Well, we have gone through it. Thank you for that, by the way. It's going to help me as I put together my talk for New York. So I appreciate it. We've gone through a lot of ground. Is there anything else? Well, actually, one more question about Azure HorizonDB. If somebody wants to spin up on it, they've never heard about it before. Maybe they are a database practitioner. They're not a user. But they're thinking about whether they want to work on change companies or work on a database or whatever. Or maybe someone's a user. If they want to spin up on Azure HorizonDB, what's the best place to do that? Have you written a paper about it yet? Probably not.

PANOS: 01:02:43
No, we have it, and that's on our to-do list, because there are lots of interesting new technologies we brought. Even though the architecture, fundamentally, is not brand new, there are lots of interesting, especially on the performance and reliability side, we've done a lot of cool innovation that we want to share. So hopefully that will come. In terms of reading, I think there were a couple... Adam gave a great talk at Andy Pavlo's. We should share that link. It's a part of the Carnegie Mellon database talk series, so there are lots of details there. And I think there was also a session at Ignite, like the Microsoft conference last year. But if somebody wants to go deep, this talk at Andy Pavlo's CMU database talk series is probably the best to go listen to and learn. For higher level things of course our public documentation covers a lot of ground but it's not going to go into the level of detail that was discussed there so it depends on what level of depth and detail people are interested in and hopefully a paper will come soon but we've been focusing a lot on releasing the product that we haven't had the chance to write it up yet but it's coming

CLAIRE: 01:03:52
Got it. So I'm looking at the CMU database group talk, and I love these tech talks that the team at Carnegie Mellon, led by Andy Pavlo, has done for years now. Even during COVID, they were called the vaccination series. Anyway, so the talk is titled HorizonDB, Co-designing PostgreSQL and Azure for Cloud-Native OLTP. So we will be sure to include that in the show notes. It's a great shout out. And if I can find the Ignite talk that Adam Prout, I think he co-delivered that maybe with Denzil Ribeiro. I will include that one as well for anyone who wants to learn more.

PANOS: 01:04:30
Yep. But it's Postgres, just a quick remark. You know, there are lots of internal implementation details. And again, people who are interested into that, I'm sure they will love the talks. But at the end of the day, the intent is for this to be Postgres, right? So as a user or even, you know, a DBA, there will be some nuances that you may want to understand. But to a very large extent if you're familiar with Postgres, it's just another hopefully more performant, more reliable, just better service in terms of the storage architecture and so on. But the surface and how it behaves and operates is still Postgres, so any knowledge there applies.

CLAIRE: 01:05:12
Take shortcuts and we like to slot something new into a mental model that we're already familiar with. And I hope my boss doesn't shoot me for saying this, but to my mind, I think of Azure HorizonDB as Postgres with a shared storage architecture. That's the model I have in my mind.

PANOS: 01:05:32
Yes, that's exactly right. That's exactly right. Shared log, shared storage. You're exactly right. That's what it is. And we're just trying to leverage this more modern primitives of the storage layer to just boost Postgres even further. But functionally, it's still the same, as you said, with disaggregated shared storage.

CLAIRE: 01:05:50
Okay. So the point of today's episode, the focus of the discussion is working on Postgres after 13 years on SQL Server. And we've covered a lot of ground from your origin story through your perceptions of Postgres, comparisons to SQL Server, and then the work that you're doing today, which is on Azure HorizonDB. Is there anything else I should have asked you that I forgot? Something about any interesting stories. I'm curious actually about how you made the decision to do this. Did someone have to twist your arm or did you have to go twist somebody's arm to let you make the switch? What was that like?

PANOS: 01:06:33
No, I don't think it was either or it was a good coincidence. You know, I'm always interested in learning new things and new technologies. And there was the great timing that we were really ramping up the HorizonDB investment because I think there was full alignment all across the leadership team that there is a good opportunity. Postgres has been doing extremely well in the market and we feel we can really release a service that makes it stand out. So the timing was great. It was neither, I guess. It was an easy conversation. There was a business need. There was a personal interest. So it was a good timing to go make that change. And hopefully, I learn new things. I also bring some interesting perspectives from my background. So it's a win-win I think for both sides. So it was a very smooth transition.

CLAIRE: 01:07:22
Speaking of your background, one of the things that you and I have in common, we're recording this live, by the way, and there's a Discord parallel text chat that happens while we're doing the recording. But people are only hearing audio. We publish this podcast only with audio. But while you and I are talking, we can see each other on video because we're using another tool to do the recording. Anyway, the point is my background graphic behind me as we're talking is taken at an island in Greece in the Dodecanese, where I like to go sailing every summer. So, well, sometimes we go sailing in the Cyclades, and sometimes we go in the Dodecanese, because I'm half Greek. And that is one of the things that you and I have in common, because for anyone who knows accents, you have a Greek accent, because you're 100% Greek, as far as I can tell.

PANOS: 01:08:10
Yes, I do. Yes, that's right. That's awesome. I didn't realize this was from Greece, but it's a really nice background.

CLAIRE: 01:08:21
This is Kalymnos, and there's a bay there called Vathi, which of course means deep in English. And it is, as you can see from the cliff behind me. And if I lean over, you can see that that's my husband swimming in the water there.

PANOS: 01:08:33
Oh, wow. Very nice. No, that's awesome.

CLAIRE: 01:08:39
Anyway, so have you ever been to the Dodecanese or do you go to other places?

PANOS: 01:08:40
I don't think I have, interestingly. I think I mentioned earlier, I'm not a big traveler. Many people will be frustrated with this. And in Greece, standards, as you're saying, the Dodecanese are like, okay, maybe you can fly, but there are many hours of boat ride. So I have never been that far. So I've been to many islands closer. You mentioned the Kiklades or Cyclades in English, I guess. But not in Dodecanese. Now I'm very motivated with your nice picture. It seems really cool. So it's definitely a place to visit. And yeah, people in the audience, if they haven't, definitely it's a worthwhile destination.

CLAIRE: 01:09:17
So do you have a go-to island that is your favorite place to go in the summer?

PANOS: 01:09:23
Yeah, I mean, Paros has been my main island because mainly because I enjoy windsurfing so much. It's a good destination for that. So yeah, I used to go since I was maybe eight years old with my father. It has changed a lot over the years, but it's still a good place to visit. So I'm trying to go there as much as I can and enjoy some time in the water.

CLAIRE: 01:09:45
So when we sail in the Cyclades we start in Paros always and it's an absolutely beautiful island and a lovely spot and one of these days my daughter has done some open water swimming like she swam all the way across Lake Tahoe once so I'm hoping that she organizes one of her swim clubs to go do. There's often been a swim from Antiparos to Paros, like an open water swim race that happens like in July each year. And I don't know if it's happening this year. But if one of these days in the future, I'm hoping that they organize that. And then of course, I'll just have to go in order to cheer her on. So. Hopefully. Well, they better.

PANOS: 01:10:25
Yes, that would be awesome. And it's not too far, so hopefully people can cross the channel there and make it to the other side, yeah.

CLAIRE: 01:10:37
All right. Well, Ευχαριστώ πάρα πολύ, which means thank you very much for joining the show. I speak Greek like a four-year-old or a five-year-old. I have a very limited vocabulary.

PANOS: 01:10:47
No, that was pretty good.

CLAIRE: 01:10:51
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.

PANOS: 01:10:53
No, no, thank you again for inviting me. I hope people learned something from it. And yeah, super excited to be here.

CLAIRE: 01:11:03
And if you are listening and you liked today's episode and you want to hear more of these Talking Postgres episodes, you should subscribe on Apple, Spotify, YouTube, or wherever you get your podcasts. And please tell your friends because word of mouth is gold in the podcast world. You can get to past episodes and get links to subscribe on all the different platforms by going to TalkingPostgres.com and you'll see transcripts included on the episode pages on TalkingPostgres.com too. A big thank you to everyone who joined the live recording and participated in today's text chat on Discord.