Postgres FM - Best Practices
Episode Date: March 7, 2025Nikolay and Michael use a recent "best practices" article as a prompt — giving a few tips each on the topics mentioned, like schema design, performance, backups, and more. Here are some li...nks to things they mentioned:7 Crucial PostgreSQL Best Practices (recent blog post) https://speakdatascience.com/postgresql-best-practices“Don't do this” episode https://postgres.fm/episodes/dont-do-thisArticle discussion on Hacker News https://news.ycombinator.com/item?id=42992913Mozilla’s SQL Style Guide https://docs.telemetry.mozilla.org/concepts/sql_style“SQL vs NoSQL” episode with Franck Pachot https://postgres.fm/episodes/sql-vs-nosqlHA episode https://postgres.fm/episodes/high-availability ~~~What did you like or not like? What should we discuss next time? Let us know via a YouTube comment, on social media, or by commenting on our Google doc!~~~Postgres FM is produced by:Michael Christofides, founder of pgMustardNikolay Samokhvalov, founder of Postgres.aiWith credit to:Jessie Draws for the elephant artwork
Transcript
Discussion (0)
Hello and welcome to PostgresFM, a weekly show about all things Postgres Girl.
I am Michael, founder of PG Mustard and this is my co-host Nikolai, founder of PostgresAI.
Hey Nikolai, what are we talking about today?
Hi Michael, we are talking about some article which attracted my attention.
And I hope not just the article because the article is about best practices and I'm I'm hoping discuss that yeah I always
like like 15 mistakes 25 recipes this kind of titles clickbait yeah and
honestly I chose it like let's just choose this article and it attracted my
attention just by title seven crucial post Postgres best practices. Good title, right?
Yeah, and we haven't had an episode called best practices, so it's an
interesting, it's an interesting omission on our part. Really? Yeah. Yeah, okay. Best
practices. We're having something like mistakes to avoid maybe, right? Oh, maybe.
Yeah. From my experience being in program committee
of various conferences and just general conference experience,
people love to hear about mistakes.
They also love to hear pieces of advice.
But mistakes, they somehow love more because it's
like things to avoid.
And yeah, and best practices.
What does it mean and best practices, what does it mean best practices? Like, do this, not that, right?
Yeah, I've been thinking about this. What's the difference between best practices and good
practices? Like it's, I think it's like shorthand for if I'm new to this, and I don't really know
what I'm doing, what are some things I can do to not look stupid
or to at least cover what people generally say
is a good idea?
Because in anything complex, especially databases,
we know often it depends.
It's gonna depend on exactly what you're doing
as to whether you should do X or Y.
So I think these lists and these suggestions are almost
fraught with danger from the beginning. But I think they can be useful educationally.
They can be useful for people to say, in general, this is a good idea. In general, this is a bad idea.
You could be a great consultant, you know. Because you sound like one.
Well, what do you think best practices mean?
For me, it's not about avoiding to look stupid.
It's about...
I like the word shortcut, like to quickly find what other people already experienced
and choose maybe not best, but something better than you would choose on your own.
Right.
So that's a good point.
Actually, not so much about looking stupid, but maybe to avoid things going wrong, like
to avoid the most common trap.
Right.
The goal is not about how we look.
The goal is not to look bad when making decisions, engineering decisions around podcast, but
the goal is to make database work better,
more reliably, better performance, avoid data loss, avoid downtime, these kind of things.
Actually, correctness is one of the goals, but naturally Postgres has very good, in most
cases if we don't touch the null topic, right?
Nulls topic.
In this case, if we don't touch nulls topic,
most of the time Postgres works in a very correct way and unpredictable. I expect this,
I got what I expected. And so in general, three areas, big areas are good performance,
reliability and well, the avoidance of data loss is a big fear of database guys, right?
And also no downtime or very short downtime.
Yeah, perfect.
So the big three areas.
Let's dive into this article.
I know we both are not thinking it's super great material.
Yeah, sadly. let's be honest well it's an attempt
it looks to me like somebody has asked their favorite llm for a list of postgres best practices
and almost copy and pasted it verbatim into an article that's that's what it looks like to me without much review.
Well, maybe it's written by LLM. Yeah, I'm not sure. The author's name is Zaka and I
think it's good that the good attempt is made to bring this again. And actually,
it was on Hacker News Top, I guess. That's how it caught my attention. It's a good
attempt, but I agree with you some parts that maybe it's written purely manually.
It's possible, but I would like to just reflect on the
fields covered.
Seven fields.
From the very beginning, I don't agree that we have seven practices here.
We have seven fields covered and inside each field we have some practices mentioned.
And you also mentioned that you think there should be more fields covered if we try to
come to have this kind of digest of tips, right?
It's not only these seven.
But let's touch my idea.
Let's touch every one of these seven Bring up to three
our own tips we should
like should be sure
Notice like involved into consideration and then in the end
I am very curious what you think is missing in terms of the fields the areas, right?
So sure deal. Deal.
Okay, the first field is database design.
And discussion is about many conventions and so on.
What you think, what's your number one take
when we think about how to make database design good?
What makes it good?
Yeah, so I mean, I'm surprised it starts with this.
I actually saw some of the Hacker News comments and it's an odd choice of where
to start, but I do see a lot of people making the mistake of using spaces in
their names for objects or using mixed case and things and technically if they
followed this advice, they wouldn't do that.
So I do see
people making the opposite mistake. So yeah I don't think it's bad advice and generally people
do have conventions. I actually follow a lot of the ones that are listed here. So yeah not bad.
How about you? Well first of all I think it's not a mistake if you... My previous startup had a camel case, table names, it was inherited.
And I understand it very well that it's not super convenient.
I left it as is because it was intentional.
I also think back, one step back, database design being the first topic,
and then performance will be the next topic and leaving reliability
like backups and HA later.
It just shows a tendency that probably this article and this set of tips are targeting
more backend engineers, developers, programmers, or those who create some systems rather than
purely database folks.
And it's totally fine and
also like if we take managed service managed postgres like RDS or something
the important areas like backups HA are presumably solved already so we have
we have like we have opportunity to focus on things we deal with every day
like database design,
performance, these things are closer to us. So I can understand this choice of
order. And if we talk about database design, I think the main idea is to have
some convention. It can be even a camel case with spaces, but you understand
you will be forced to use double quotes all the time everywhere.
But if it's choice, well, it's inconvenient.
I know I was there.
And I was there after a couple of other startups where I was, how to say, very, very like polishing
every symbol.
I think this is what matters here.
Like conversion is important for yourself
or for people who work with you also, right?
And for LLMs who work with you as well.
But it's a good point.
It doesn't really matter.
Why is it number one in this list?
Like it, yeah.
Yeah.
And there's also no mention in database design and schema
design. There's no mention of normalization, which is a bit odd.
Well let's, let's, let's shift to normalize the tables.
Yeah, I tend to agree and also if you SQL style guide, which is closer to normal programming languages
and moving away from this central space colon, right?
How to say?
Like central space thing like an underscore?
No, no, not only a select space, blah, blah, then you from and you need to move from.
So you maintain the central space vertical line.
Oh, alignment.
All the time.
Oh, alignment.
Yes.
I honestly, I hate it so much.
I know it's old-fashioned approach and many books follow this rule, but it's so inconvenient
guys.
Let's just take Mozilla's SQL style guide, publish it inside your company, wiki or documents
like any confidence or something what you have.
Adjust it for your flavor a little bit and that's it and agree.
Okay, we are following this convention.
As for normalization, this is, I guess let's mention the episode we had a couple of weeks
ago, three weeks ago, maybe with Frank Pacheaux, right?
And about NoSQL versus SQL.
And we talked about normalization, generalization quite a lot there.
I agree this is a very important topic to agree on and follow this.
Well, also for me, I think constraints are super important.
I would say I would put this as a big, like it's a best practice to use database constraints,
all kinds of constraints,
understanding the power of them and also understanding overhead as well.
Yeah, I think it's good default. Like if in doubt, add the constraint and you might want to remove
it in future if you get to a certain scale. But I like the idea of having it by default.
For example, we discussed in the same episode with Frank, we discussed
maybe we should have not null constraint by default. Unfortunately, it's not so usually
in all systems. But we can agree, let's put it by default and lift it only if we know
nulls are going to be useful. So yeah, that's it, I guess. Three tips enough, right?
And what about schema namespacing? Do you ever do you use it?
It's interesting. I'm shifting back and forth and in my career use
namespaces schemas or not use them. Depends on the project. Here I am like, with you, it depends.
Also it doesn't matter that much, right?
Well, it does, because it's about convenience as well. If you think about others, they can
be spending a lot of time trying to find your table. Again, consistency here is the key, because if you chose to start using namespaces, schemas,
suddenly after a few years of development and the majority of your tables are in the
main...
It happens all the time, like I see it all the time.
Majority of the tables are in public schema, but suddenly you start using some additional schemas and hide tables there, basically.
It's maintainability as well, for example, you can control permissions better. And it also,
sometimes namespaces are serving some trick, like you can have multiple tables with the same name sitting in different schemas.
But this can lead to some messy state and problems as well.
I would say this is part of conventional agreements, how we use schemas.
Sometimes people choose, you know, like choose.
This is a good topic, by the way, for maybe one day we should discuss it.
Multitenant applications and architectures and what's about how to create a multitenancy
with good properties in database.
You know, I just recently learned that if you go to time scale cloud, you cannot run
create database and you cannot have multiple logical
databases in a single server.
So in single Postgres, usually we are allowed to have multiple logical databases and there
are recipes for multi-tenancy.
They have an article about this, like let's use schemas and just that's it.
But for me schema is very weak wall between data.
Logical database is a big wall between data because you cannot read from another database
being connected to one database, you cannot read from another database not using something
like Postgres, FDW or dblink.
Because this is how Postgres works.
Database name is a part of connection properties,
the core connection properties.
Unlike schema, schema is kind of, it's something...
Namespace.
Well, yeah, and it's namespace,
and you can revoke rights to use some schema, it's good,
but still it's inside the same database so
if you mess up messed up with permissions you can end up having
security issues if you if you want strict segregation of data separation of
data for for your tenants okay this is definitely different topic I think quite
good like we have at least let's move on to the performance topic,
the second topic, right?
So what?
They talk about indexing
and they talk about query optimization.
I think we've in the past talked about a couple of things
like micro optimizations and macro optimizations.
And I think we could maybe like think in those terms instead.
I do think it's obviously performance is a lot about indexing and about individual query
optimization.
But I do think there's some best practices around macro optimization, like in postgres
we by default we don't have PGSTAT statements turned on.
That feels to me like pretty much a best practice
that we should probably have PGSTAT statements on
or an extension for doing that analysis
that's on the wider system level.
Maybe some logging, like I think there's some performance
logging of slow queries.
Choose just one tip right now. It's already too main.
Oh, a best practice. All right. I would say...
Well, I like their first one, I guess. Use indexes.
Yeah, using indexes is obviously like, yeah. I think my take would be don't leave auto vacuum untuned and don't
postpone blood control. This is how POSGUS works right now, right? So we must be aware of
what blood is, what dead tuples are and like distinguish them actually.
and yeah and be prepared for that in maintenance yeah yeah and this is what nobody do it well in among managed Postgres platforms right now nobody I
mean they don't give you good tools some of them have basic auto vacuum tuning.
And that's it.
Some of them provide the PGRiPAC.
They also have a Rindex concurrently, but that's it.
Obviously, I see a future where more platforms will provide better tools to help you in this
area.
But knowing that right now it's on on your shoulders when
you build some system this should be not postponed right indexes obvious like everyone knows index
index yeah let's get indexes so this tip oh but two two important numbers yeah two important
things that aren't mentioned here are do it with concurrently and don't index everything.
We've done a whole episode on over indexing, but I feel like a whole beginning
category of issues are caused by folks creating indexes everywhere.
Yeah, I agree. And well, there are dozens of tips we can put there around indexing.
Yeah.
But yeah, you said only a couple, right?
Yeah, only a couple, but you already named like more than five.
PgStats.
I agree.
While we are all sitting here and waiting until hackers decide to move this extension
to core, we need to keep this tip active.
PgStats must be installed in any database.
Understanding some very edge case or maybe corner case overhead we also talked about
in the past.
Good.
Yeah, okay, good.
And that's it maybe, right?
Well, performance is huge topic.
We love it.
Yeah, we had many episodes about performance.
But again, auto-vacuum tuning, low-end indexes, many best practices.
And the PGSR settings must be installed.
I agree on these three, maybe, right?
Good, have it? Good, good, good.
So next field, again, the list is far from being complete.
It's just like the tip of the iceberg.
So next, security, suddenly.
I would say make sure you don't have Postgres open to the world.
It's like accessible, right?
It genuinely was going to be mine as well.
That's the main mistake I see people making.
What else?
But obviously if you're using certain managed services, that's on by default in a lot of cases so then it
becomes well of having good right they open it to public but protected maybe
right yes then then it becomes about good password policies and things yeah
right right right but they like this is this started with Hiroko.
I think they also have a Postgres open to public and security by obscurity when host
name is very large hash.
Yeah.
And username also all like everything is like large hash.
But it's just it's it's weak security.
Right.
But but the password is strong, right?
If it's not MD5, but Scrum, it's something better already, right?
But I agree, if you're serious project, this should not be the case.
Port should not be available to public.
I think it should be only like local IP address and available only internally in networks
VP.
Yeah.
So good.
Are you saying it depends?
I'm saying that I'm not against like I can understand people who have well platforms
who have it open to public for because sometimes we want to start very quickly. Yeah. And at the same time,
I would not allow this for in a serious project with data of customers, PII and so on. Like I
would not allow this at all to let the sport to be open, even if it's password is absolutely like
And if it's password is absolutely like difficult to find, like because for example, we have two factor of authentication everywhere.
But here we have just one password.
Well, what about if it's leaked?
Right?
Yeah, this is this is honestly the difficult thing about security best practices is because best practices with security means do everything you possibly can to secure
everything and that's just often not practical, like at what cost at what, you
know, what are you trading off?
Often you do trade off things for better security.
Like as you were saying, like quickness of getting started
or developer experience, like ease of use.
So there's like a, I do think it's a tricky topic
to give best practices on because you don't ever want
to say do something that's slightly less secure
because it has these other benefits
because it's not a best practice anymore.
Yeah, it also makes me think we could have bad pieces of advice episode.
You know, we could have it.
Yeah.
We did go through, there's a Wiki.
Don't do this.
My next advice, next tip for security is divide and conquer.
So, and I found that many teams don't follow this.
So, use different users for different parts of workload.
And for example, humans should have different user names in database,
so we can distinguish them quickly and probably limit differently and so on.
And parts of application also it's wise to avoid using the single
username for everything. I really like that about humans as well.
I mean we don't like to think about it but if you need to
remove somebody from a project,
it's much easier to do that at the use level
if they've got their own user than it is to roll out
and to think about what did they have access to,
which passwords did they know that were like team wide
or something like that.
So yeah, I think I've heard of a similar view.
In fact, I think this article mentions it,
but there's a general
concept of principle of least privilege.
Yeah, yeah, yeah.
Well, this is super important principle, of course, and just it should be a habit.
It's hard to enforce it.
It should be a habit of all the team members to follow this principle.
But it is also painful, right?
Like it is painful because it means anytime you add anything,
you then need to add permissions to it,
like from all of the things.
I get that it's good for security.
Default privileges and Postgres,
the concept of default privileges,
sometimes you can define them as well.
Is that then the least?
Yeah.
Yeah, well, yeah.
Another, maybe let's do the last tip. And I'm grabbing the ideas from article, but like we're trying to unwrap them here.
Password rotation.
Oh, I hate it. I've written yuck by that.
Well, nobody does it actually. Oh, well, nobody. Some people do it. But honestly, honestly, it's first thoughts pain.
but honestly, honestly, it's first thoughts pain.
For me, it's a relic. For me, it's a relic of when people used to use share,
like used to use the same passwords across multiple services.
So I think the risk, when I say used to,
obviously a lot of people still don't.
You think it's a bad advice?
My advice would be make sure all your users are using
some password generator or password manager
so that they have a unique password per service because then the risk of their
password getting leaked by a different service that then they can use as an
attack vector on your service is zero. So it's only if you leak the password that
it becomes an attack vector, which, you know,
do you see where I'm coming from?
Yeah, yeah, yeah, I understand that.
Also like, yeah, I agree.
I think actually Postgres could have improvements in this area.
For example, you could say, if it would be possible to define password policies and so
on, like for example
to forbid short passwords, simple passwords, and Postgres would ensure it's not happening,
or also PgBouncer, I don't know, like Postgres first of all.
And maybe password retention could be one of the policies if people choose to use it.
Right, I don't know, like I don't believe in the rules here established and followed
at all.
It's like I just see companies have this principle and nobody follows this principle and attempts
are like hard.
It should be Postgres who enforces this rule to avoid weak passwords for example.
Yeah.
Right?
Yeah.
Okay.
Well, Articles mentions RLS, but I think it should be very connected to performance and to be used with big caution. So it's it's a controversial topic.
Yeah, let's see, let's check performance additionally. Okay, next, backup and recovery.
If you're on managed service, well,
supposedly it should work good,
but it depends on the service, on the provider.
Not everyone has good capabilities.
I would say also a best practice would be to have a version.
Like to, I know we've talked about the difference
between a backup and a logical backup or a dump, but
if you're on a managed service, I would still recommend having a copy on a period that you're
comfortable with off the service.
Yes, automatically created.
So diversification of backup locations and some platform can go down or your current can be stolen and
You you must have the
Backups, maybe not super frequently, but some backups additionally and secondary
provider or location
like
isolated it's it's similar to
Having backups on the same server where you work, but just a different layer.
Same principle, different layer.
If all backups in the hands of RDS, well, and single account, well, it's not good.
And unfortunately, if you are on RDS and you want to follow this principle, you need to
deal with dumps, logical.
Yes.
Unfortunately.
And it's not unique to them.
There were quite a lot of service providers that that's the only option.
Yeah.
I agree.
What else about backup and recovery?
Testing sometimes, right?
Yeah.
I guess that is the other big one, isn't it?
It's not a backup unless you know it could be restored.
Yeah.
Sure. So some amount of testing
that's restored. And I don't think platforms test all your backups. They test only some of them and
who knows right? So I think it's a good idea to test even if you trust them and don't hear bad stories, still have some testing.
Yeah, what's the age old saying?
Trust but verify, right?
Trust them to do it, but verify it.
Final responsibility is yours.
Like if you lose everything, well, yeah.
So what else?
Anything else in this area? Backup and and recovery understand the RPO RTO and
Yeah, I think discuss the disk RPO RTO. I think it's about discussions internally like have those discussions
I think RPO and RTO are really good tools
And good things to define but more importantly they're good to enforce. You've even had the conversation with, you know, senior management or whoever it is,
maybe co-founders.
What are our trade-offs here?
Like, what are we willing to pay this much more for, like, reduced amount?
Or are we willing to lose a tiny bit of data to keep bringing our costs right down?
You know, I think those are difficult discussions to have and not everybody has the same,
not everybody would make the same trade-offs there
in different situations.
Let's move on and next, it was number four,
field number four, I would jump to field number seven here,
high availability because in my opinion, backups
and DR basically, the disaster recovery
and the share they should consider together
as a foundation of good database system platform or something.
So we chair, right?
I chair.
It's interesting if my number one advice is void systems, which are not a chair systems,
but split brain systems like replication manager avoid it just avoid it and I don't know if you're gonna say a best practice
maybe we just say Patroni or what would you say yeah just Patroni but you know
right now cloud native PG is gaining popularity and it's not using Patroni
so I wrote on Twitter anyone experienced already split brains with Cloud Native Pg?
I'm just wondering, I don't know.
So Patroni is definitely past huge path to achieve very good quality in terms of avoidance
of split brains and maintaining very low downtime in case of primary disappears and
so on.
Yeah, this is number one. Like I would just, if possible, choose Pat. Yeah, this is number one.
Like I will just, if possible choose Patroni.
This is my advice.
What else?
Or managed service provider.
I think that this is where the big, well, all the cloud providers that offer this.
I'm so glad they handle this for me.
A recent case, recent case.
Like I can speak about this openly.
Crunchy Bridge, please, don't do backups from
primary, physical backups. They still do. You need to fix this. If you follow us, like right now,
full backup, if it's not snapshot, even if it's not snapshot, so it should be from some replica,
It should be from some replica, some physical standby, because it's very IEO intensive. Even cloud snapshots can be IEO intensive.
Of course, all archiving should be on the primary to minimize the lag and minimize
the RPO, improve the RPO.
But full backup, if you do it from primary, it's huge stress for the primary.
If it's heavily loaded primary, it's huge stress for the primary and if it's
heavily loaded project, it suffers.
What we recently observed, it was not good.
So advice to backup, if it's under your control, organize backup so full backup or delta backup
or snapshot is done not on the primary.
It's possible.
PG style backups, PG style backup, they support non-exclusive
backups, right? So we can do it on replicas.
Makes sense. And if we've got HA in place, the replica is not doing anything, right?
It's not a read replica.
Well, yeah, it depends here, but I agree it's good to do backup from replica which won't be primary so if we talk in
terminology of Patroni it should be no failover it should have no failover tag
probably also no load balance tag but definitely no failover tag it's Patroni
terminology you can put the tag on replica to say no failover so if
failover needs to happen
Patroni won't choose this replica. Got it okay. I was actually thinking you did
want it to be that one but yeah sure. And then you do backup from it well there
is another like topic if you do backups only full backups only from single node
what happens if it has some local corruption and other nodes are fine so all your backups are corrupted but it's interesting
already deeper topic not like like let's talk about HA we talked about yeah what
else legs leg control right leg monitor leg yeah well also not monitor, but also it can be tuned to have a very low lag.
And also when you do load balancing, it can be very smart logic.
Many people already implemented it or else implemented it in core already.
So it can be like if some write happened, the session deals with primary for some time. It can be even smarter,
right? Comparing other sense and so on. So you have some, it's not strictly about HA,
but it's about load balancing mostly and how we use our replicas. It's like adjacent topic.
What else about HA? We don't have a lot of time, unfortunately.
We have a whole episode on it. Let's link to that. yeah yeah yeah what else in this area any other tips test failovers right
or switchovers yeah true yeah i i remember i i chased rds guys asking you have this checkbox ha
which makes me pay double price for primary but how can can I trust you? I mean, I trust you like in
words, but in action, how can I test it? And they implemented it, you can test failover, which is
great. So, simulate primary failure and see how failover happens, how your application experiences
it. For example, another type of advice here is to write applications so it has retrial logic, not to lose rights.
Okay, let's move on because this is like huge areas itself.
Each of them are huge areas.
What's left?
Maintenance and monitoring.
Whoa, huge area.
Development practices.
And that's it.
Only two areas. And I think it's not possible to
pack it into a few minutes let's uh only maybe use one or two tips everywhere for maintenance
and monitoring we already had a tip to always install pgstar statements what else your choice
well big mistake I see people doing sometimes is turning off auto vacuum.
And the author of this doesn't seem aware of auto vacuum.
So that would be my main tip is keep auto vacuum on and tune it.
I know you mentioned tuning it.
Okay. My tips are two of them, like blood control and index maintenance.
And we had several episodes on these topics and just these must be
implemented in any project which aims to grow even not to huge numbers but some moderate numbers.
Okay and finally development practices and then your secret area as well. Development practices,
what do you think? Version control, code organization? Well yeah I mean version control, code organization. Well, yeah, I mean, version control has been a best practice for years, but I still think
it's harder than it should be.
I know we did a whole episode on this.
But some basic, however you choose to do it, some way of tracking what changes have you
made to your database, it's some form of version control is so much better than not having
anything.
Yeah. version control is so much better than not having anything. Yeah, well, my advice is straightforward. Based on what we do last five years, use proper testing during development and for deployment.
And this testing should involve a lot of data. So thin clones or database branching are great.
Or a staging server that has like just something that has some
reasonable amount of data.
Well, if you're alone, yes.
And also, even if you're alone, if you work on two tasks separately, it's still
like single staging is not enough.
You need to have, and what, what if you started doing something and made
everything wrong and data is changed, how do we start?
Right.
So database branching is the key.
Or best practice.
Yeah, so I recommend in development practices,
grow your level of development methodologies,
so database branching starts to be involved
into all development and testing activities.
It will be level up, huge level up.
So then this is what we do at Postgres.
And okay, what's your secret topic, secret area?
Not secret.
We've discussed it a bunch while we're talking, but I couldn't believe that config tuning
wasn't in, like no mention of changing shared buffers even.
Like I don't understand how you can talk about
best practices for running Postgres
and not talk about changing any settings.
Again, if you are a DS user, I can imagine
like we talked about HA, but we talked about backups
and it's very, in this article,
it's very development focused point of view,
like developers point of view.
Things already solved and configuration partially also solved, but we all remember like Crunchy
Bridge tuned random page cost after our complaint.
They did, but I don't think RDS have yet or most of the others.
So random page cost is still the default on most manage providers.
So many things are still default.
I'm happy I have work during consulting.
We help many people still.
I know that could be covered, but it really just wasn't mentioned.
And then the other big one, I'm sure there are others that have,
it's hard to spot like
the absence of things right when you go through something but I couldn't believe I didn't see a
single mention until the conclusion of upgrades of staying even in security we didn't mention
staying up to date with the latest minor versions and in performance we didn't talk about like
upgrading to major versions that feels to me like a best practice should
be to stay up to date. Yeah, yeah, I agree. It's part of our healthy
post-goss vision. Definitely minor upgrades, major upgrades for sure. It's
part of our health check we do. Everything that's in your health check in my opinion
should be your best practice. Like if you're yeah if that's yeah that makes sense and so also still like I always have feeling it's
not enough we need to extend all the time some things go away like upgrades
we will have in 18 they will have statistics so this will say this tip will
go away but so many tips are still coming.
Okay, I think it's great.
Like maybe we're not very well structured, but I hope some people heard some good pieces
of advice today.
Let us know in the comments, please, or on Twitter or LinkedIn somewhere.
Good.
And we have documental actually, maybe it's a good time to
remind that we have a document with ideas and also if something is missing
and we could dive into some topic. Yeah, you mean so we've got a document that
lets people request or suggest episode ideas, topic suggestions. Yeah. Good.
Nice. Good. Thanks Nikolai, catch you next week. Thank you, bye bye, see you.