Managed services vs. DIY

Managed services vs. DIY

Nikolay and Michael discuss some options for hosting Postgres — what are the main reasons for going for a managed service, versus managing it in-house (DIY).

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.

Some kind things our listeners have said