Michael: Hello, and welcome to Postgres FM, a new weekly show
about all things PostgreSQL.
I am Michael I'm from pgMustard, and this is my co-host Nikolay
founder of Postgres AI.
Hello Nikolay.
How're you doing?
Nikolay: Hello, doing great.
How are you?
I'm still, I'm still traveling, still traveling right now.
And Prague prag is beautiful.
So let's, let's talk about some Postgres stuff.
Michael: Oh, so good, very jealous, but also I'm, I'm in the UK and
it's about 28 degrees at the moment.
So it feels like summer finally.
Yes, so today I was keen to talk about hosting of Postgres.
So specifically, when should people choose a managed Postgres service
versus DIY or do it yourself?
Should people even be considering do it yourself these days, if
they opt for managed, what are the best options out there?
That kind of thing.
So, yeah.
I'm really keen to hear your thoughts on this.
What are you seeing at the moment?
Nikolay: My thoughts are we should always go the DIY path.
We should always compile kernel of Linux, and so on.
I'm joking of course, but the opinion's changing actually, right?
Because, if you are DBA back in 2005 to 10 and you see something which
replaces part of your work, uh, probably you will, you will be very skeptical.
Right?
What do you think?
Michael: Well, yeah.
So I deal probably with more smaller companies, startups, generally.
And I can't think of the last time I saw somebody starting a new project
DIY, but I do hear and see about it a lot more in larger companies.
And some of those startups that are getting big, they're starting to
consider, maybe for cost reasons, maybe for a little bit more control.
They're starting to consider taking things, if not completely
DIY at least, you know, still on Amazon, but not RDS, for example.
Nikolay: Have you seen ever like a company who started, like 10 or 15 years ago.
And they started with self-managed Postgres and then
moved to RDS or something.
Michael: Yes.
So I think I actually saw them blog about it recently, so I think it's
okay to mention that the team at Auto Trader, which is a big, secondhand
car, online dealership in the UK, I think they're in the process of,
or maybe now have completed their migration to Google Cloud SQL, from
what I believe were, if not completely self-hosted then self-managed databases.
Nikolay: I saw a couple of examples as well, uh, including
some very large companies.
And, I've noticed that they just understand that, managing Postgres
probably is very difficult.
Also, I think it depends on how big your databases and workload, if you manage
to split for example, to microservices and you have dozens of databases, it's
easier for you to go to RDS because limits are quite far so, so, but if you
have very heavily loaded huge database, probably it'll be challenging because, for
example, discs on RDS, regular RDS, they are like network attached, EBS volumes.
So if they're not local and so latency is a bit higher, of course.
So, it's tricky, but I saw examples, the specifically microservice
architecture and very big company.
They decided by purpose to get rid of any self-managed, but
as usual, it takes many years.
So it's a combination usually.
Michael: Well, so that's a good, like, is that almost a rule of thumb that
if somebody's got either one or a lot of smaller databases, there's probably
not a good, are there any good reasons if I've got one or lots of smaller
databases to not use a managed service?
Nikolay: Well, I think, if you consider some already grown company, you have many
databases, probably like two big reasons.
I see first is, to move, small databases to manage services and
just not to think about backing up, replication of the follower about,
but also there is another big reason.
This reason understood usually by upper management, not by DBAs
because DBAs usually think like, let's do everything yourself.
Like, let's keep it in our hand.
Yeah, let's have access to PGDATA and so on, or like process list and so on.
But upper management thinks like it's, it's better to rely on, Amazon or Google
engineers and their infrastructure in terms of backups and, uh, related
like RPO RTO related service level objective objectives, instead of
trying to hire a lot of good experts, it's very hard to find good experts
and scale the process of their work.
So this second reason, I think it's for bigger companies.
It's very important.
Uh that's why like, like RDS and others are growing.
I think I don't, I don't have numbers, unfortunately, but I think,
from, as you said, like, everyone is on managed already, but not
everyone, actually, not everyone.
And sometimes people go back actually sometimes, but not often.
Michael: Yeah in well, could you give us, do you know any, any examples or
the reasons why they went backwards.
Nikolay: Well, the price is big reason.
Of course.
If you manage Postgres yourself, for example, on EC2 instances and you, you
can have one year, three year contracts, there are ways to optimize the price and
it's will be definitely, cheaper than RDS.
So then you can do additional infrastructure optimization, in terms
of backups and various clones, for non-production use and so on so it's it's
of course, like much cheaper, like I would say roughly like up to two times cheaper,
but cost is sometimes not a big driver.
I think it will change by the way we are in the beginning of some crisis coming.
So maybe reasons will like reasoning will start changing but, uh, also
moving back sometimes like a weaker reason is, uh, pure technical.
So to, to troubleshoot some weird things, it's not a fun when you go to RDS and
say something like we have an issue and their engineers say it's a Postgres issue.
You go to Postgres experts, even sometimes to, to Postgres mailing
list or some various chats.
And they say RDS is not Postgres.
Work with RDS not fun to be between if very, very difficult incidents
happen and you don't have full access.
So I've been there a couple of times with my clients.
It's like, it's not fun.
so this is a technical reason to move back to and take full control, but you need
to have very strong experts to do that.
Michael: Really good point about the, about
Nikolay: Oh, there is.
Michael: and
Nikolay: Third reason there is third reason as various extensions and
capabilities that RDS doesn't offer.
Right.
Michael: This is the one I wanted to bring up.
I think this is more of a reason to start on a DIY or maybe, maybe one of
the only reasons to start on DIY is if you really want an extension that
isn't supplied by the managed service part of it that you want to go with?
I am seeing some of the newer ones really aggressively go after
installing lots of the extensions.
But if until a few years ago, a lot of them really didn't have
even some of the contrib modules.
I think as an example, I, I think Heroku still doesn't let people install
auto_explain, which comes with Postgres.
Nikolay: Heroku unfortunately, there were recently big discussions on Hacker News.
So why Heroku has not been developed and it's a pity because it was a pioneer
of managed Postgres many years ago.
It was so great.
But then they started to after acquisition by Salesforce, I guess they
started to lag in terms of pricing.
I remember helping several companies, at least two, migrate to RDS just because
of pricing and also capabilities.
I have currently.
Three clients who want to migrate and they say, let's postpone a little bit
implementation of, cloning stuff we Postgres AI are developing because we are
in the process of migrating off Heroku.
So, so I don't see anyone who is migrating to Heroku , unfortunately, but Heroku
was great back to like 10 years ago.
Michael: Well, I still think they have some features that others don't.
So I think they, they come with better defaults.
So once you upgrade off the smallest instance, they keep changing your various
settings to keep up with your instance size in a better way, I think, than
some of the bigger ones like, uh, RDS.
I had a, a friend recently moved from Heroku to Crunchy Bridge,
which is one of the newer ones.
A lot of the team behind Heroku.
I was really surprised by some of the defaults still there.
And the, there was, not as good documentation, but
everything else looks amazing.
But he ended up migrating back to Heroku and upping his instance size.
I think he thought some of the reliability was, was on the Heroku
side, but it turned out it might have been something he was doing instead.
So it was interesting to see somebody that does rely on some of
the Heroku features, really valuing those and ending up migrating back.
And the other thing I think they do that most of the others don't
do nicely yet, at least is major version upgrades, mostly for you.
Uh, now I think they require a little bit of downtime, but, I only just recently
saw that added to Google Cloud SQL.
So I thought that was quite a nice thing that they still do that others don't.
Nikolay: Well, good thing here is that, the variety increases a lot
and you touched Crunchy Bridge.
So we should already add one more, set of players here, which are
based on Kubernetes operators.
Right.
And I, like, I know Alexander Kukushkin the maintainer of Patroni not long ago,
developed major upgrade automation for the building block of their operator.
It's called Spilo so it's like container image for very ready to use in AWS.
First of all, but not only I think, and, he managed to achieve good level of major
upgrade automation with small downtime.
So, it's improving.
But I, I want to blame, manage services for one thing.
They usually don't provide access to look at PGDATA and at least to have,
uh, physical replication connection.
Right.
I remember like four, four years ago or so I met the founder of
Aiven who is now big, very big.
Uh, they raised a lot and they grow very fast.
And, I asked him like, okay, very good, you are building similar, similar
offering to RDS, but with more flexibility and more features probably and so on,
can you provide, physical replication connection and access to PGDATA and so on?
He said by default, no, but if you contact support, it's possible.
Guess what?
Uh, recently, their support answered.
Of course, no it's not possible.
So this, this whole is closed also.
And lack of physical replication connection means
some kind of vendor lock in.
So if you want to migrate off managed service, you must use on the logical
replication connection, which is quite tricky and complex has a lot of issues
if you have a very heavy workload.
Michael: And we're talking about, about big instances, right?
Cause smaller ones.
We still have the option of, dump and restore, I guess.
Nikolay: Right, but, well, what does small mean today?
Small today, for me, it's less than one terabyte already.
Michael: Great.
Nikolay: So I would not dump, uh, like, I, I, of course like when you do logical.
Actually initialization is dump restore basically, right?
So we need to do it anyway.
Even for 10 terabyte database, we need to do it.
And there are ways to speed it up, but, it's not fun.
I would rather prefer physical copy of files.
Michael: Awesome.
Let's talk about upgrades another day, maybe.
Um, it feels like a whole good topic and actually I'll put it
in the show notes, but you did a really good panel with a few people.
I think it was a Postgres Vision recently.
Um, I enjoyed that,
Nikolay: Yeah, it's interesting yesterday.
They invited me to Postgres Europe conference to talk about upgrades again.
And they also accepted database branching talk.
But I want to say once again, it's my public position that, actually I already
booked hotel to Berlin late October I'm going to come, it's very good,
but I ask them, do they record talks?
Do, do they have plans to publish it later?
if they don't I probably will not come because this is my position.
Everything should be recorded and published later.
Like I understand this is a huge conference, 500 people.
Some of them will probably come to my talk, but I want to
have recorded session as well.
And to be able to share and refer later to my materials,
because for me, it's a huge trip.
So that's why, like we talked today and this is good because if someone
is interested in the comparison of managed versus non managed and
Kubernetes, we can send a link, right?
So, I must say all Postgres conference organizes, please
record and publish share.
Michael: And, uh, full disclosure, I'm not sure you knew this Nicolay, but I'm
actually on the panel for the PGConf
Nikolay: Yes.
Yeah.
I knew that, but I forgot.
Yes okay.
Michael: So yeah, I'm excited to see those, hopefully if you do come.
Nikolay: So you also, can, pass my words to the organizers, right?
Michael: Yeah, absolutely.
And it's possibly worth giving a quick shout out to some of the work
you've been doing on the Postgres TV channel to publish some of these talks.
So some of these talks that were given that were not recorded in
the past at different conferences, you've picked some of the better ones
and, recorded them and put them on, remind me of the name of the series.
Nikolay: It's it's called Postgres open talks because
talks should be open as well.
But like the idea of that series conflicts with my position to come to
conferences that only recorded of course.
But so if every conference starts to record and publish later and
probably this series will be over, but I will be happy actually.
Michael: That's a sign you really care about solving the problem isn't it.
We're taking a definite tangent here, but I had the same experience with my
browser extension for, redirecting people on the Postgres documentation nowadays.
Yeah, well, yeah, but hopefully you won't need to soon.
Nikolay: Right.
Well, actually I should stop using, right, right,
Michael: So, yeah, but I'm happy because I don't, I didn't
want this extension to exist.
I, I would much rather it worked first time.
Nikolay: Yeah, Google search results are much better.
I, I mean, we, we know the problem, but maybe our audience doesn't know the
problem is that like, until very recently, if you search something related to
Postgres, you saw some versions up to 7.4.
So like some 7.3 and so on.
Like very, very old and it was not fun.
And people shared these links, very old thinking it's it's not old.
And so like a lot of confusion, but it, it was recently solved.
And I, I recently saw some example of not good occurrence, maybe should I should
post it to the, the mailing list, but, uh, like 99%, it works very well right now.
Michael: Sadly, I don't think there's much we can do on the Postgres
side for, for specific bad examples other than let time play out.
Um, but yeah, so the, the worst thing for me was sometimes I'd forget that
it was an old version, read it and then not realize about a feature.
Anyway, uh, sorry, probably should get back to hosting!
Nikolay: We, we we've got off topic upgrades off topic,
Michael: Yeah.
Nikolay: Off topic conference and off topic search results in Google.
Yeah.
Okay.
A lot of off topics.
Michael: Yeah.
So let's assume we don't need an extension that we can't get on a provider, we
don't have a really experienced DBA team, and we're not expecting to have more
than a terabyte of data anytime soon.
What are you thinking in terms of, which, which managed services would you tend
to lean towards, in what circumstances?
Nikolay: Well, it depends on which cloud you use, maybe you're not on.
In cloud on cloud sometimes like very, very rarely, but sometimes people
don't use clouds, but if you are on cloud, you probably should just
choose the offering they provide.
But sometimes it's awful.
Like a few years ago, I would not recommend Google Cloud SQL to anyone.
They had only eight, uh, knobs to tune from from almost 300 setting
parameters and was not flexible, not ready to, to, you cannot tune to you.
Like it's not good, but I, I don't remember some other,
problems , there offering had, but right now it's improving a lot.
So
Michael: Very quickly, right.
Nikolay: Since, since we mentioned, yeah, since we mentioned, uh, Postgres TV, we
had, Ilya Kosmodemiansky and I had great guest, Hannu Krosing who was, in the past
was, Skype database architect developed a lot of things in Skype, and, he talked
about, vacuum issues and was great talk.
So if.
If interested in vacuum issues in Postgres, uh, go check this
presentation on postgres.tv.
And, uh, he, he works at Google right now.
So cloud SQL has very, very strong experts and it's improving.
And they also recently released AlloyDB.
Right.
So it's like, it's very, also interesting, like among all, Postgres
uh, offering, you can choose in cloud.
They are like almost pure Postgres, like RDS Postgres, almost pure.
Nobody except Amazon engineers can say, there are no patches.
Of course there are some patches there.
So, but there are also very different databases, like, uh, Aurora, which
has different storage or recent NeonDB, which like open source of
Aurora also with different storage.
Uh, so we cannot say it's already Postgres.
Like, it looks like Postgres.
It feels like Postgres, but not always, but they're also much more different.
Like AlloyDB, it's quite different.
They have interesting idea to have, uh, column store, right.
And memory.
In addition to row stores or row store converted to column store to have
very fast aggregates for analytical workloads, or we have also Yugabyte.
Which is not Postgres at all, but kind of looks, looks like Postgres.
So among all these options, it's hard to choose.
Right?
Michael: Right.
I guess it depends so much on the use case.
And I, I think you're right.
I think if you don't need anything special and you're fully committed
to a single cloud provider already, it makes sense by default to go
with theirs, unless, you know, you read the fine print and there's a, a
really good reason not to, or go on.
Nikolay: If you, for example, on Google or Asia or I don't like, and
you committed to be on this cloud, you still may think to use not their own
Postgres managed service, but also, uh, offering from companies like Aiven
or ScaleGrid because they work on all.
So you will have.
API and the UI are ready to work on any cloud, if you just, if you move
or expand to other cloud providers.
So it's also interesting, but you know what we should choose,
we should choose Kubernetes.
The only question is, I mean, Kubernetes, um, operators or
products like, like StackGres.
Why?
Like, because this is the same, like managed, but more power you have access
and everything, if you need to diagnose.
And so on, the only question is when?
Maybe not today, maybe tomorrow.
Right?
Because still they are, they are started a few years ago and they're still very
young, but I'm sure in five years, a lot of users will prefer Kubernetes under
their full control, compared to, fully managed by cloud provider, uh, services.
Michael: Well, I think for people that are using Kubernetes themselves,
which is a growing number, for their application side, I think those people,
once they've built up that muscle and they, they understand it and they
understand the, the sharp edges, um, Then.
Yeah, I think it, I think it does make a lot of sense.
I think there was a lot of fear.
What's it FUD: fear uncertainty.
I dunno.
Is it denial?
Uh, but I didn't see any good arguments against it and it does seem to really
help in a few very specific ways.
But equally, I don't see most small companies needing it.
Like, I think there's like a scale where it becomes really useful when
you need to provide a certain service level, um, maybe you have a really,
really low tolerance for downtime or absolute zero data loss requirement.
And that's really a, you know, that kind of.
Uh, really high level thing that everyone thinks they need or want, but
not everyone actually is willing to pay for maybe is the main criteria.
But yeah, I don't see any reason why not, but I do think it won't be self-managed.
I think a lot of people will then pay for somebody else to manage that
for them, uh, still to not need that Kubernetes, uh, expertise in house, at
least in the early days of a startup.
Nikolay: Maybe, but with, this approach, Kubernetes based, maybe
you can hire a vendor of this Kubernetes, uh, product, uh, Postgres.
But, uh, with this approach, you can install anything.
You have like Postgres is very well known for its extensibility, but fully
managed offering, always limits this.
For example, Timescale extension is available only on Timescale cloud.
Michael: But that's, that's due to licensing, right?
Nikolay: Among, among managed Postgres, it's not available on RDS and, and will
never be available there because Timescale thinks it's, uh, a reason to, for users to
go to their cloud offering instead of RDS.
By the way, what do you think, uh, how successful will be this, uh, approach?
Like we have some very good extension, very popular.
We, we will have it on only on our managed service?
Michael: So I saw, I think, the founder of OrioleDB gave a really good talk
recently where he described some of some extensions are kind of normal extensions.
They add a little bit of function.
Yeah.
So they add a little bit of functionality to Postgres that makes it
a little bit better in a certain way.
And he then also added a category of, yeah, I think he
did call them super extensions.
So Citus, Timescale, I think he included Oriole, um, basically extensions that
are doing so much, they're changing things really fundamentally at certain
levels and actually they change it so much they can almost be considered.
They're not a fork because they are an extension, but they have
some characteristics of a fork.
Where do they play nicely together?
Um, how, yeah how easily can you migrate between them?
Nikolay: It's like not fork, but different database right already.
Michael: Almost, yeah, exactly.
Almost a different database.
Um, so yeah, I, I think I can see why it would work for Timescale because
if you really want their expertise, they are the best at supporting it.
And, uh, going to their cloud makes a lot of sense, but that's a really
good reason for picking DIY as well.
If you really want the Timescale functionality and some of it, it seems
incredibly good even for non-time series workloads, like think, did you see they
did their skip scan implementation?
That's super useful in loads of workloads.
So there's, there's reasons to want that.
And if you want it, but you aren't ready to go to Timescale as your managed service
provider for some reason, you have to DIY.
So yeah, I do think you're right.
But I'm seeing actually a little bit more of a, an excitement around these services
that abstract even more away from you.
And they come, they come with, I think, uh, limitations at the moment.
And they're very, very new, but services like Supabase or Neon looks exciting.
But, I know it's not Postgres, but on the MySQL side, PlantScale.
These services, I can see the excitement in the early startup CTO level.
They're promising them that you start with this today and we'll scale with you.
We can scale up, we can scale out and you don't have to handle any of that yourself.
You just keep talking to us like, we're your database.
There might be some hidden dark secrets that are, that are yet to come out of
the, you know, the reality of that.
But it seems super compelling to me as a, as a simple option of, I
don't need super complex things.
Nikolay: What do you think about security issues with the services?
Because for example, if, if you are customer of Amazon
you have trust with them.
Like they don't access your data in RDS, although they, they could, right.
Like it's, there is some trust, but if it's a smaller player, and they
run your databases with your data inside their AWS account, for example,
like how to achieve good trust here.
Michael: Well, I think security is a really good point.
I think reliability as well.
You know, AWS, there's two angles.
One, they've got a track record of good uptime, good reliability.
And two, if you go down or if they go down and therefore your service goes
down, half the Internet's down as well.
So customers aren't that surprised that your service isn't running because
nothing's, you know, their Spotify isn't working or their Netflix isn't working.
So I think there's a few things you get with these big players that
people underestimate a little bit.
And with these new ones, they sometimes they're built on some
really complex, um, infrastructure to handle some of this stuff.
that does, that does fail and sometimes in very spectacular ways
and could, can result in a lot more downtime than the normal few minutes.
So I think complexity does come cost, uh, or, sorry.
They're, they're taking away the complexity from you, but
they're adding it on their side.
And I, don't know.
I don't know that I would trust her something that needed that myself.
Nikolay: For me as a database performance expert, they add complexity because
in, if I manage Postgres myself, I can install very useful extensions
in addition, to pg_stat_statements, let's talk about performance, Uh,
pg_stat_kcache and pg_wait_sampling, these extensions add two important
dimensions to pg_stat_statements.
One is physical, so you can see disk I/O, pg_stat_kcache, disk I/O and CPU, even
system CPU, user CPU context switches and so on, and another pg_wait_sampling,
it provides similar analysis like performance insights in AWS RDS.
Without these two extensions, it's very hard to understand, for
example, which query consumes a lot of CPU, but not very data intensive.
Sometimes it happens or similar things.
Pg_stat_statements sometimes cannot answer some questions.
Right.
And, uh, if you don't have performance insights, like, uh, like RDS has,
sometimes you are very blind.
So, so they add complexity in terms of query analysis and
performance optimization to me.
Because with these two extensions and proper monitoring, it makes very simple to
perform top down analysis of workload and find, the worst queries . So agree or no?
Michael: Yeah.
Well, I think we're talking about different ends of the spectrum.
I like, I think maybe you're right.
That, that's the kind of thing that the CTO at a startup picking.
Um, let's say, uh, let's pick on PlanetScale, cause it's not even Postgres.
Let's say they pick PlanetScale today.
That maybe they're not aware of that kind of limitation all the way down
the line or that they're completely reliant on PlanetScale's tooling.
Nikolay: I think PlanetScale is not good example because people choose
PlanetScale of my, MySQL users, because they are also developers of Vitess.
And, if you need to build very big system that that requires sharding,
it's actually almost standard defacto.
So you probably will go there because of that.
Or, or use Vitess and that's it.
It's interesting.
It's very specific example and I I'm interested in that example,
but it, it will move us away from our main topic right now.
Michael: Well, what, um, how about, uh, Supabase then in terms of their promising
Nikolay: for smaller projects also very specific.
They, they like, they do very great thing.
Um, but for smaller projects, mostly like,
Michael: At the moment
Nikolay: At the moment.
Right.
But, the, their main offering is.
Like we provide you out of a box API authentication, uh, capabilities and
this, uh, real time like, Firebase, like, uh, right think, but, but, uh,
The question is like, what do you offer?
If my database is 30 terabytes and I have 30,000 TPS, I need
specific performance analysis tools.
I need, to be sure that you will survive for example, five terabytes of WAL
per day, backed up properly and so on.
And this question is interesting.
I'm not sure Supabase is ready for this scale yet.
Michael: No, but who it, like, I'm thinking, looking through the ones
I've got, I think EDB, for example, came out with a managed service
recently and Crunchy, of course, both of those are Postgres consultancies
turned into managed service providers.
Are they the, would you, would you think about those?
Do you think they might have some answers to this kind of thing?
Nikolay: I I'm very negative today for EDB.
I wish they, they provide better consulting still because I have couple
of clients over last few years, not couple, several clients who, uh,
suffered from their consulting, but it's good for me because, uh, they went to
our small shop and we fixed problems.
So I'm, I haven't checked their managed service.
I don't know.
No, no, no, no comments here.
Maybe it's good.
But again, like, it's, it's a very difficult choice, right?
So like many, many, but RDS is growing.
Like Google is interesting.
Microsoft has a power of Citus, so it's a very interesting time we live
in, but again, in in few years, most people will choose Kubernetes based.
I think.
Michael: You heard it here first.
Um, I said you heard it here first.
Probably not first.
People have been talking about this for a while.
Awesome.
I know we could probably talk about this topic for quite a long time.
Is there any last things you wanted to add before we wrap up?
Nikolay: Uh, well, um, I think physical connection is a big limiting factor.
And every company who wants to deal with managed Postgres should
think about this, do they need it?
And also low level on diagnostics capabilities.
So if they're okay without it, it's a go for, for this managed service.
I have many clients who work on RDS and other, managed services and I
like helping them as well, because sometimes it's fun to deal with.
Their support engineers.
It's sometimes it's lengthy discussions, but it's specific kind of fun actually, I
would say, but in general, I think we have like, EDB are called Big Animal, right?
We have huge zoo of, animals of various kinds.
Right.
And, I definitely like, the specific, uh, breed.
That is shaded with Kubernetes.
So let's probably talk about this area some sometime soon as well.
Michael: Sounds good.
Wonderful.
Well, thank you everyone for joining us.
I'm gonna put a bunch of these links in our show notes.
We welcome ideas, suggestions for future topics.
And yeah.
Thank you so much, Nikolay.
I hope you have a good week.
Nikolay: Thank you.
I also want to thank everyone who provided feedback to Michael.
Uh, and I wanted to say you can provide feedback to me as well.
So like, but for Michael is also good and don't forget to subscribe
and also share, please share this channel, this postgres.fm link
and, and links to specific episodes.
This will help us to grow.
Thank you, Michael.
Michael: Take care.
Speak soon.
Bye.
Nikolay: Bye.