Michael: Hello, and welcome to Postgres FM
a weekly show about all things PostgreSQL.

I am Michael founder of pgMustard, and this
is my cohost Nikolay founder of Postgres AI.

Hey Nikolay what are we talking about today?

Nikolay: Hi, Michael.

I, I guess today we, again, are going to react to feedback or requests.

We saw on Reddit good request asking us to discuss how
to become DBA if you are currently in different area.

And we want to shift to this field.

So let's, let's discuss.

Michael: Yeah, absolutely.

It was really nicely worded.

Wasn't it?

It was around both.

What are the expectations maybe for a junior DBA and
also what would their responsibilities typically be?

And I think this is gonna vary quite a
lot, depending on the type of organization.

And we can go into that for sure.

But equally there doesn't seem to be a
ton of good materials out there on this.

So I'm looking forward to hearing your thoughts on it.

So yeah.

Should we start with, should we start with what
maybe the, we use an acronyms or I guess, but yeah.

What do we mean by DBA?

Nikolay: database administrator, I guess over last
decade this term changed its its meaning a lot.

Right?

And it's many, many factors here.

Originally DBA was like sysadmin style person.

Who should be invisible if work has done well, it should be like,
nobody knows DBA is there because it's like people learn about,

they exist only in the case of some incidents, troubles and so on.

But in cloud error some of work almost disappeared because if you
use managed version of SSUS as cloud SQL and GCP or RDS on AWS.

Of course you don't need to be an expert in backups and replication at.

Moreover yesterday remember last day on Twitter, we
discussed once again, that dumps are not backups.

And I, I have belief that RRGs plays a
big role, other managed positive services.

They play big role in teaching bad things
because people don't realize what the cops are.

I mean, Junior people, junior engineers and they also want at the same time
to sometimes to have backups in hand, but you cannot take backup from RG.

So you still use dump, but probably this is different topic, right?

Dump sources, normal backups.

But anyway, like some, some functions of DBA vanished.

Because they were replaced by managed service.

Others appear like knowledge about how
to manage cloud resources and, and so on.

Somehow reacting to this, some organizations started to
introduce new terminology, like DBRE also reacting to SRE

Michael: Yeah.

So we are talking about site, site, reliability, engineers,
database, reliability engineers, which is a term, the, the latter

of those is a term I've only started hearing more recently.

But I think that that factors into where these tasks are done
in an organization and not necessarily what title they have.

So in, in the.

Well, actually, even nowadays in a small organization, there's a
really good chance you don't have any person with DBA in their name.

You might not even have an SRE by title.

If you've only got a team of four, probably the founder
handles it, or one of the engineers takes the lead on that.

So I guess if we start with tasks, you've already mentioned
backups, but I think there's a, there's like a few more that used to

typically live within the DBA role and still exist, but maybe get.

In different roles these days, but we've got in.

When I was at Redgate, we always had different
tools kind of dedicated to different roles.

And we always thought of our monitoring tool as predominantly a DBA tool.

We had backup tools and they were predominantly
a DBA tool and we had a few others as well.

Yeah.

Well, yeah.

So rep replication and major upgrades, I'd also
consider, were typically part of the DBA role.

Maybe, maybe not so much anymore, but again with managed
services handling some of that, but monitoring, I know we've

already discussed it in depth that just recently, but that

Nikolay: Yeah, we, we, should say that those who just
joined us a week ago, we discussed Pogo monitoring

and, and I think it's, it was quite successful episode.

So please check it out.

But hundred percent like monitoring is still on the plate and it's
very relevant skill that GBA should have, but you are missing big chunk

of, or maybe just not mention it yet, tuning performance, tuning and

Michael: Yeah.

Nikolay: analysis query optimization.

Right.

Michael: Yes.

So sometimes that, so once an organization is, is large enough, sometimes
that gets put into a different team than the, than the engineering team.

And that, that is often called the database team
or the DBA team or some, something like that.

But I've also seen that work taken on.

Hundred percent by a development team.

So I have seen, I have seen some of that.

I guess, I guess they're doing DBA tasks at that point.

Is that what you're saying?

Nikolay: Well, when, when we discuss these things, we, we see
that some things already went to manage services if you use them.

But others, actually, all of them, when I just name them, I immediately
distinguish two areas, infrastructure DBA and application DBA.

I very, I like it a lot.

I like this classification.

It's very good.

Michael: I've never seen it in a job advert.

the first time I ever heard the phrase application
DBA was reading a Haki Benita blog post.

I don't know if that's where yeah, so either.

Yeah, well kudos to him.

Great blogs.

If you haven't checked them out, I'll link them up in the show notes.

But yeah, that feels like a really good distinction.

And maybe what we're saying is.

In the world of having managed services, there is less need for some of those
infrastructure DBA tasks, but just as much need for the application DBA tasks.

Nikolay: Right.

Exactly.

And I, I guess if we talk about junior DBA and how to start, the first
question is which database system and which of these two areas you think

most about like infrastructure area — people teams still manage Postgres
themselves a lot, like RDS is not like a hundred percent of cases.

Right?

So infrastructure, DBA or application DBA.

This is the main question to start because different skill sets are needed.

Michael: Yeah, that's a good point.

So you're thinking of

Nikolay: There is overlapping of course, right?

This is overlap.

Michael: Yeah.

Well, and at smaller organizations you might need to do both.

Even in that kind of junior type role I've I've
definitely seen some people fall into the role.

Like they've one of our early customers
described themselves as a, a pretend DBA.

They were, you know, they were just the
person in the, they didn't even step forward.

For the role, when it was asked, they just were the one person that
didn't step back when they were picking the person that was gonna.

You know, look after it.

But I guess if we talk about larger organizations, it's a bit
easier because you can have these specialist teams or areas.

And maybe if you can find a role in one of those where you can learn from
the other application DBAs or the other infrastructure DBAs, then you've

got a smaller set of responsibilities that you, you need to learn about.

And you can maybe get skilled at before either
learning the others or specializing deeper.

Nikolay: Right.

Well, in, in larger organizations, I think the
need in application DBS is usually bigger than an

infrastructure and also speak, thinking about structure.

Infrastructure team probably is like some big department.

And if, if they exist and they can work only, or if manage services or they
can manage Postgres themselves, but it's some kind of monolithic entity.

But if we think about engineering in bigger organizations,
usually it's split to if, if they follow microservices,

for example, it's a lot of teams, smaller teams.

Even if there is no microservices approach, still, there
are many teams and I strongly believe that it's good.

When organization management found a way to have
growing knowledge of databases inside each team.

So there are probably few people who are experts, but inside each team,
it's good to have junior DBAs and like midlevel DBAs application DBAs.

They don't need to understand details about backups and replication.

Monitoring, probably yes, some part of it, which related to optimization
queries and some other basics like transaction looking and so on.

But, I saw people who can optimize SQL,
but they don't understand backups at all.

And vice versa.

I saw very good infrastructure DBAs who
even cannot write complex sequel at all.

Like only very basic.

So it's like, it's there is split here.

And I think application DBA is, is like overall if account numbers, I, I
believe industry needs more application DBAs and than infrastructure DBAs in.

Michael: Yeah, that makes sense.

And it makes sense even if we are not talking solely about job titles.

So a lot of those SREs D Bres a lot of the
developers that have to take on DBA responsibilities.

The majority of their, their DBA type work is probably still on
the application side, worrying about correct indexing or looking at

some dodgy queries that ORMs are spitting out that kind of thing.

So, and maybe, maybe advising team members on, on pull requests,
if they have people in their team that don't know as much

about databases, maybe giving them feedback or explaining
to them a better way of doing something in the database.

Nikolay: Right.

So let's start probably with how to be a junior infrastructure to.

Right.

And then we will discuss how to be junior application DBA.

What's where to start, what to do, like what knowledge should be
definitely in skill set or knowledge set and how to develop skills further.

If you start, any DBA, but if you start my first
recommendation is just to read documentation.

If you print it, it's 3000 pages if I'm not mistaken,

Michael: Really?

Nikolay: Yeah.

I re I remember funny story.

I remember going, going to the office of CTO of very large
organization who like, who was my, became my customer.

And his secretary said of, so Postgres AI and she.

Oh, I just printed 3000 pages.

This is, this is you.

I don't know.

I just use it and suggest people how to use it better.

That's it.

so that's how I, I know 3000 pages at a four of letter size uh, format.

It's very well structured, of course.

And I suggest reading it from the very beginning and just read it.

And of course skip some non-relevant parts, but
very beginning and a lot of interesting stuff.

So the documentation is great.

It it's missing a lot of things like use cases, but it's great.

Michael: It's actually split quite well for this topic.

I'm just looking at the table of contents right now.

And there's obviously a really good introduction at the beginning.

And then it does a whole load on sequel language which
I'd probably consider a bit more on the application

Nikolay: Yeah.

As I've said, don't know, SQL almost like, so , it's possible.

Michael: But then the next whole big section is on server administration.

So that feels like a really good place to start
for, for the infrastructure DBA side of things

Nikolay: Exactly.

Yeah.

Michael: and slight aside, but the documentations famously good in Postgres.

So I know, I know not all systems have good documentation, but it is . I
found it really approachable when I was first getting to know Postgres.

And the other thing that was found surprisingly accessible to,
to me when I was new to Postgres was the source code as well.

The not in the source code itself, but the comments in the source code.

So if you're ever in interested in what, like why something's a certain way or
why a certain default is a certain number, that kind of thing often, there's

a, there's a really good comment in the source code that will tell you why.

So don't be scared of that.

Nikolay: Definitely a hundred.

Absolutely.

And I, like, I always say the same and but it's already kind of
deeper than junior maybe, but also like if you go to source code

uh, you shouldn't be scared about C and just read the comments.

Sometimes comments are in the readme file in
some directory, or sometimes they are in line.

And it's not, it's not just, if you want to go deeper, sometimes
important concepts are missing in documentation happens.

For example heap only twos, tops, hip only tops.

Right?

Currently hackers, I saw the discussion hackers and
it's about to be added to documentation on the reason

like, or, or just recently added and it'll be in S 15.

So it's still missing.

And I always used link to source code to explain what it is.

So source code it augments documentation.

Michael: Yeah, by the way I looked it up and
both two pools and tops are very much acceptable.

So it's, it's good news.

Nikolay: Problem solved.

We discussed it

like three weeks ago or two, right.

But don't expect good how-tos in documentation or in on soft score.

This is what is missing there.

And for that you need books like video courses, maybe, or articles,
blog posts that are many, many very good materials around.

planet postgresql org will show some of them.

Howtos usually are there, unfortunately the PSGs documentation
doesn't have, howtos almost like step by step and so,

Michael: Otherwise, it would be 10,000 pages.

But yeah, the other thing I'd say is it, I think it's acceptable and okay.

As a junior DBA to only know one way of doing something,
so make sure, you know, like the basics and how, how the

default is in Postgres and a way of solving a problem.

And maybe like, don't worry.

There's 20 different backup tools.

Make sure you make sure, you know, and can use one of the
better ones or you understand the basics of, of one of them.

I wouldn't worry too much about there's there's so much
depth in each of these topic areas that you could go into.

I'd recommend more getting a breadth of the tasks and being able to
solve each one a little bit instead of, or how would you, how do you

Nikolay: well, it depends on personality.

Some people have like, they read documentation.

It's like a.

A book which educates you explains the concept.

So shows, shows some examples and so on, but some people just
need the like modern time we live in a stack overflow approach is

very popular and sometimes people just need step by step recipes.

And this is probably bad because if you skip reading books, it's bad.

But if you already read the book and just need
a few examples how to do something and step by.

It's a good thing.

I, I'm not saying that the documentation does have examples,
but it's structured in a way to explain things to teach, not

to show how to perform basic things or more advanced things.

So topics that infrastructure DBA should know of course MVCC
and I can recommend materials from Bruce Momjian of course.

Right.

We can, we will provide some links.

Bruce always has perfect presentations, especially explaining
basics also backups replication monitoring transaction processing.

Right?

What else?

Michael: Upgrades, minor upgrades, major upgrades,

Nikolay: Upgrades?

great, extensions.

Michael: maybe awareness of operating system
and how the operating system and the database

Nikolay: Oh, well, in general, a good DBA infrastructure
DBA should be good expert in Linux, definitely.

And file systems and clouds.

If it's a cloud environment most of cases currently are cloud environments.

So of course these areas should be covered a certain depth and actually also.

We discussed before our episode that sometimes
people manage multiple database systems.

I feel very rare, like successful stories
like that it's quite, it's quite rare.

Database system is very, very advanced system.

It's very deep advanced.

And I saw ideas.

Let's like we have a bunch of experts in Oracle.

For example, let, let teach them all in Pogo.

Our organization has them both.

So they will be experts in both.

It's very difficult to follow both areas.

I don't have time to catch up.

For example, when I'm America, I wake up a lot of
European guys posted so many great materials about polyus.

I want to read them all, but I don't have time.

Right.

And , if you put Oracle on or SQL server, you
just don't have time to to develop yourself.

So my point is that you should be good expert in just one system.

Of course, it's possible to be PLO it's
possible, but you won't be very deep eventually.

Michael: And, and I guess the important point for
juniors is that it's totally okay to only know.

Postgres is a really good choice.

Nikolay: right.

Yeah.

Yeah.

I agree.

Michael: but it shouldn't worry you, if you're considering a junior
role and you only have experience in one database management system,

it's okay to learn one there will be good jobs out there for you.

Nikolay: right, right.

But you should be not expert, but you should know some languages addition.

because sometimes you need to code something.

And also if your colleagues use some languages, you will need to
understand how some libraries or, ORMs various middleware things work.

Right.

Michael: this feels like a really good time to switch over.

I feel like we've talked about infrastructure a little bit, so we let yeah.

Let's switch over to application

Nikolay: Before they do that, just let let's let's mention quite good books.

Both available online.

If you go, if you want to go deeper of course you need to understand
internals because internals it's how things work from inside.

If, if you understand them, you can explain many things that,
that that's which impossible explain if you don't go inside.

And the first is internals online from Suzuki.

Right?

I, I don't sorry.

I don't remember.

Michael: We'll get it.

I'll get it in the, the link in the

Nikolay: Suzuki was Def sorry about name, but
second one recently published from Egor Rogov.

And it was translated from Russian.

It's very good book.

It's missing many parts, of course, but parts it has covered very well.

For example, indexes, how indexes work, various types of indexes.

So I, I recommend both

Michael: yeah, you were right by the way, Hironobu Suzuki.

Nikolay: Sorry.

I forgot the first name, right.

These two books will give you very, very far horizon for development to
be more advanced DBA, actually infrastructure first, but also application.

Cause if you want to understand how various
parts working, you need to go into internals.

If you, if you're an application,

Michael: Yeah, a hundred percent.

Both of them are excellent and go quite deep, but they're also written
in a simple, like they're written simply and it's, I found it able to

follow topics that I didn't know about at all and learn about them.

So I think they're both excellent written.

Nikolay: Yeah.

Yeah.

It looked like they are very different, but, but I
enjoy reading them both and I do it all the time.

I return to specific topics.

I use them as a reference to understand specific, like to, to recall something
or to understand something which I didn't understand before and so on.

Like all the time, this is more advanced DBA.

Two must have resources this time, in
addition to the commutation and source code.

Of course, of course.

Oh.

And finally for simple things, how, how to I criticize
the commutation in terms of how to, there are many

block posts but of course let's mention one of them.

This is cyber tech and their posts are always brief, problem oriented.

And I enjoy reading them as well.

They like, let's take this problem and attack it.

And also they explain things, but they show how to do something.

Right,

Michael: Yeah, true.

I like them as well, and I, I think they include some comics
as well at the start, especially I think it's Laurenz.

He does.

But the other thing I was gonna say.

There's a blog aggregation site called planet
Postgres that not everybody seems to be aware of.

And that's a great resource.

The Cybertec blog gets syndicated to it as do maybe
20, 30, 40 others that get released regularly.

So that's a great place to, if you want to start seeing what
people are writing about at the moment, but of course, if you

want to know a bit more about a topic, you can just search it.

And often one of those good blog post will be surfaced right near the top.

Nikolay: Yep.

Okay.

Application DBA where to.

Michael: Right, so what would be expected, let's say, if you've
started as a developer or data analyst or something like that.

And you've been taking on more and more database type tasks.

You've, you've become maybe a little bit of the
expert in your team when it comes to database things.

But if you look at what a DBA is expected to do, maybe that's
quite intimidating and you feel like you've got a lot to learn.

Where should you start?

Or, or could I apply for a junior DBA?

Application DBA role today and then learn those things
as I, as I work or, or what should I be doing in

Nikolay: I think the number one step is to learn SQL and learn modern SQL.

It can be not very advanced, but it should be modern, not to
be like from SQL 92 standard and good, good place to learn it.

For example, it's modern sql.com from Markus Winand.

Right.

So I also Use the Index Luke these two websites are very like, they
are great very great places to, of course, basics can be learned from

anywhere, like from, poss documentation, from books, courses it's,
it's not a big deal, but, these two resources will give you some

good momentum towards modern SQL and a little bit more advanced SQL.

And you understand how much you can do.

And of course, application DBA should know SQL well.

Michael: Yeah, and I think that's a really good point, even if you
flick through modern SQL and just make sure you don't have any blind

spots, maybe you've already got really advanced on SQL through your,
through your development role or, or different role you have, but

maybe you, you just haven't had a need for window functions yet.

Or so there's like one realize like one or
two topics that you haven't had to learn yet.

It's just not been necessary, but brushing up on note or learning about those
and then maybe trying it out a little bit, that could be really helpful.

I was gonna mention one more book which is The Art of PostgreSQL.

I think that would be re a really good, for an application.

Nikolay: And since we started to talk about application DBA,
you already mentioned Haki Benita and has beautiful posts.

Of course.

And some of posts are structured in a way like items 1, 2, 3, 4, and so on.

It's very good.

Like I found them very, very, they also.

We'll educate you and let you know something new all the time.

And of course like let's, let's do some buzzwords.

You mentioned window functions, CTE, so
WITH, recursive CTE, lateral, what else?

If you are, there are things which are standard.

These things are standard.

, but there are things which POG has probably for many, many
years, which also worked learning, for example, how to work with

arrays, race other all the time, or, or we mentioned in some of
previous episodes row type or record type row type, basically.

So how to wrap and unwrap these things.

Many, many functions posts has regular expressions so on.

Michael: jsonb, like there's so

Nikolay: oh, it's language inside language
because Jason B is already in stand.

Not Jason B standard Ja Jason support is in modern SQL standard.

So it's like language inside language or they are interconnected, of course.

And of course this is huge area worth learning

Michael: But.

Even to get the basics, you know, even to, to have a look
at where in the documentation, can I look up which functions

there are, or, you know, what, what could it be used for?

I think there was, you mentioned cyber tech already.

I think they did a really good blog post on when is it appropriate when.

Why do we have JB support?

When is it a perfect use case?

When is it a terrible use case?

That's the kind of thing an application DBA should be helping their
team with in terms of if they, if they decide to just have an ID column

and then a JB column, they want to throw the entire schemer in there.

Maybe it's the application DBA that should be pushing back
and saying, that's not the best ideal, you know, here's.

Or maybe if they, they do the opposite and they want a super
wide table with loads of columns that are gonna be mostly nulls.

Maybe that could be, you know, knowing when these things are appropriate,
feels like the, the job of the application, DBA, even a junior one, maybe.

Nikolay: Yeah, this is good point.

So to start to, to do something, I always use Google
and it's so good that recently it was fixed and we

see the latest major version in search result page.

But since you say, like how to choose something here, we already
start to discuss very important skill to make experiments.

like, it's so important to learn from very beginning instead
of asking how to do something or, or why, why it's not working.

It's good.

If people ask, not like, show me how to do like, but
show me how to reproduce something and compare and choose.

Instead of asking what is better json or pure relational approach
normalized to BNF boy called normal form B BNS, BCN F right.

Or like third normal form at least.

And so instead of that, you just, you, you need to.

People help me to conduct proper experimenters.

So I, I will be able in future to compare myself and, you know, my approach,
like for, for infrastructure DBA, we need multi-session experiments.

We should be alone on machine, but for application debates, it's totally fine
to to share one machine among multiple people and focus on IO operations.

Mostly not on timing when you optimize queries
and you can conduct experiments and see results.

Even if you have one connection, you don't need to pgbench.

You don't need benchmarking approaches at all.

You just need to design two schemas to write queries, to
compare plans, to compare how many you operations in both.

And this is basic recipe.

people always use and I'm always using.

Michael: That's a really good point.

Actually, I would include a lot of performance stuff in application DBA role.

So in terms of knowing maybe you want to learn, even if it's a junior,
maybe you want to learn of course, about Bre indexes, but maybe

you also want to learn about the two or three most common types and
when they're appropriate as well as performance optimization work in

general, being able to help people when and why their query might be.

Nikolay: Right.

Well, since I work in this area in the area of scaling
the process of how teams approach SQL optimization, I

see like how you can grow and you can grow your team.

I, I think everyone should be expert in SQL performance,
but I see that 90% of people don't care, they just, they

just want to ship their features and to be good enough.

Right.

So not, not to fail at, at release time, but since like, if you,
if application DBAs of course should be performance experts.

Not huge experts, but some kind of experts and they
should care about performance and they should protect the

application from poor performance, they should care about it.

And it's good if you like, know how to conduct experiments
and if it's also good, if you start using experiments

in some kind of workflow, Constantly in the process.

And it's good when also you ask others to conduct experiments.

If even if they cannot understand all the details, but you
have some workflow in your team and artifacts are collected.

So you can be in application DBA, you can analyze them
and suggest if it's good or not good, or how to optimize.

Right.

And there are many, many resources here.

I think we like out of time to cover all of them, but of course explain tools
are great examples here: explain.depesz, explain.dalibo, pgMustard of course.

And these tools will of course you should
have them and use them to see to read plans.

Michael: Yeah, exactly.

Find one you like and get good at using it to solve problems.

Actually I remembered one last thing on the infrastructure side that I forgot
that what we, I don't think we mentioned was the maintenance side of things.

Maybe that's both of these roles?

Nikolay: Maintenance.

You mean fighting with bloat, rebuilding indexes or,

Michael: and rebuilding indexes.

Yeah.

So it's, I guess, is that, are they the only maintenance tasks,

Nikolay: Well minor grades, my well major grades.

It's already huge task still.

But minor grids can be considered as a, as maintenance task tasks or some
switchovers when we move to some newer hardware, for example, and so on.

Michael: Yeah.

Awesome.

Was there

Nikolay: We can, we can add, add, and a lot.

I, I feel we didn't cover well application
DBA because we like performance topic is huge.

For example, I mentioned regular expressions, but if you use them blindly,
when you grow to a billion rows, you won't be able to use them because

of lack of some index support, then you will find postgres trigrams.

Then you will find some ways to improve this area, but it's huge.

Like you need to, deal with many extensions.

You need to understand partitioning and so on and so on.

And so.

Michael: Well, but for a junior, let's say for a junior person
coming from a development background type thing, I think

they'll have a lot of those things, the basics of them already.

So it might be a wider topic if you were to go from, let's say straight out
of school or straight out of college into that role, there would be a lot

to learn, but if you're coming from a different profession, I think there
a lot of those skills, you might already have some experience with them,

and maybe it's an easier role to transition into from a different one.

And then the, the.

Other point I wanted to make around that before we finish was that
the role could be quite different at different stages of company.

And depending on how you learn best, it might be that you'd, you'd be
much better off in one of these than the others, but it's definitely worth

considering, you know, if, if you love being chucked in deep end and you
love dealing with problems by facing them head on maybe a startup where

they're scaling very quickly is a great place to learn and maybe getting a
developer role and putting your hand up when there are database problems.

That's a great way of learning if that's where you thrive, but
if that is terrifying to you and I, I would totally empathize

then maybe you're gonna be better off joining a much bigger
company, or much more like maybe steady stable company.

That's uh, smaller.

Where you can learn from somebody who's already been doing it.

And you you've got time to experiment and you've got
time to learn these skills when it's not an emergency

and maybe have some help when there is an emergency.

And there's a few of you to be able to jump
on the problem together, that kind of thing.

The other third category that I hadn't really thought much about,
but is really common in the Postgres world is the consultancy space.

There's lot of people hire DBAs or, or outsource some of this work.

So there are lots of consultancies that are hiring for DBA roles.

And I, I imagine that'd be a great place.

Maybe.

I'm not sure they hire many juniors, but maybe once you've got those
basic skills , or maybe some of them do hire juniors and you can, those,

those are the places where you can learn from real, like deep experts.

And that might be where you'd thrive as well.

Nikolay: Yeah.

And they're experts in specific topics.

Of course.

So I agree.

And it's, it's a good idea to, to Depending on the company size.

It it's a good idea to hire consultants for short term or maybe for
long term, if you need to grow expertise internally, constantly,

of course consultants will help them to grow all the time.

It's a good, good approach.

But maybe last recommendation from, for me.

Don't like we, we discussed this split between infrastructure and application
DBA, but if you chose one side, don't underestimate the other side.

For example, if you came from data analytics area, To application DBA.

And don't, if you don't care about infrastructure at all, you
don't, you just, you just want to learn sequel to understand,

explain to understand some indexes of course, some extensions.

Good.

But if you you never read about MVCC about how replication works.

You'll be very, very surprised when you see that each time
you update not changing anything, new version, new tap is

created, or for example, long run query on standby note
somehow affects the primary node and the performance degrades.

This will be a big surprise to you and only understanding internals
and the, the other side of this big area, which, which we call

DBA will help you to know what to do next, how to deal with it.

Michael: Yeah, absolutely wonderful.

Well, thanks so much, Nicola.

I, I think that's a good, hopefully that's a good overview.

Thanks again for the request to cover this, I
will, I'll make sure to post this up as a reply.

Nikolay: With all the links.

Michael: Yeah, exactly.

So yeah, I feel like we are giving people
who, long reading lists, but it is worth it.

So, yeah.

Thanks everyone for joining us again.

keep the requests and suggestions coming.

Nikolay: Subscribe, like, and share in your social networks and groups.

Michael: Yeah, we really appreciate everybody that's done that so far.

It helps us a lot.

It helps us get more and better suggestions as well.

So we appreciate it.

Nikolay: Feedback drives us.

Thank you so much.

Michael: Yeah.

Take care.

Nikolay: Bye.