[CLAIRE] 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] Hi Claire, really nice to be here.
Thanks so much for inviting me.
[CLAIRE] 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] 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] 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] 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] And you landed a job as part of the recruiting event that happened at SIGMOD.
Was that with Microsoft?
[PANOS] 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] 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] 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] Okay, so you did fly to Redmond, though, as part of the interview process.
No.
[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
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] 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] 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] 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] 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] 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] 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] 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] 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] 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] Yep.
Correct.
[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.
Is there anything that I should ask you about there?
Are there any stories there?
[PANOS] 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] 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] 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] 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] 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] 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] 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] 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] Of course.
Exactly.
[CLAIRE] So that's the positive spin to try to restate what you just said.
[PANOS] 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] Do you have a perspective on why
Postgres is so popular?
[PANOS] 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] 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] 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] 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] 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] 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] 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] Okay, so let's talk about Postgres.
What aspects of Postgres do you really like?
[PANOS] 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] 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] 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] 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] That's great to hear.
Yes.
[CLAIRE] 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] 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] 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] 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] Do you use the voice tools or are you typing still?
[PANOS] 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] 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] 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] 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] 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] 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] Makes sense.
[CLAIRE] 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] Oh, that's great to know.
[CLAIRE] So I'll send you a link to one of those and you can see your mileage may vary.
[PANOS] Excellent.
Thank you.
[CLAIRE] 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] 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] 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] 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] 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] 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] 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] Yes.
Right, right.
[CLAIRE] What does that mean?
[PANOS] 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] 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] 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] Is that a Postgres term or an Azure term?
[PANOS] 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] 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] 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] 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] 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] 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] 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] 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] Yeah, don't feel bad.
We have so many milestones.
[CLAIRE] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] Oh, wow.
Very nice.
No, that's awesome.
[CLAIRE] Anyway, so have you ever been to the Dodecanese or do you go to other places?
[PANOS] 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] So do you have a go-to island that is your favorite place to go in the summer?
[PANOS] 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] 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] 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] 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] No, that was pretty good.
[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.
[PANOS] No, no, thank you again for inviting me.
I hope people learned something from it.
And yeah, super excited to be here.
[CLAIRE] 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.