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).
Here are links to most of them, roughly in the order they came up:
- How Auto Trader migrated its on-prem databases to Cloud SQL
- PostgreSQL Community Panel: Upgradability
- Postgres TV Open Talks
- PostgreSQL Conference Europe
- Hannu Krosing — excellent vacuum talk
- pg_docs_bot — browser extension for getting to the current docs
- Amazon RDS for PostgreSQL
- Google Cloud SQL for PostgreSQL
- Heroku Postgres
- Crunchy Bridge
- Spilo: HA PostgreSQL Clusters with Docker
- Aiven for PostgreSQL
- AlloyDB for PostgreSQL
- ScaleGrid PostgreSQL Hosting
- EDB BigAnimal
- Azure Database for PostgreSQL
What did you like or not like? What should we discuss next time? Let us know by tweeting us on @samokhvalov and @michristofides
If you would like to share this episode, here's a good link (and thank you!)
Postgres FM is brought to you by:
- Nikolay Samokhvalov, founder of Postgres.ai
- Michael Christofides, founder of pgMustard
- Jessie Draws for the amazing artwork
Creators & Guests
What is Postgres FM?
A weekly podcast about all things PostgreSQL
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.
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.
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.
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.
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.
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.
Nikolay: Third reason there is third
reason as various extensions and
capabilities that RDS doesn't offer.
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.
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.
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.
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.
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.
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
I knew that, but I forgot.
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.
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,
Nikolay: Off topic conference and
off topic search results in Google.
A lot of off topics.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
cannot answer some questions.
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?
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 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.
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.
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.
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
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.
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.
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.
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.