Postgres FM - Self-managing

Episode Date: August 18, 2023

Nikolay and Michael discuss self-managing Postgres — both the practicalities of doing so, as well as some managed-service style tooling.  Here are some links to some things they mentioned:Our episode on Managed services vs. DIY https://postgres.fm/episodes/managed-services-vs-diy WAL-G https://github.com/wal-g/wal-g pgBackRest https://pgbackrest.org/ Barman https://github.com/EnterpriseDB/barman Dead Man’s Snitch https://deadmanssnitch.com/ Netdata https://www.netdata.cloud/ Upgrades https://postgres.fm/episodes/upgrades  High availability https://postgres.fm/episodes/high-availability Configuration https://postgres.fm/episodes/default-configuration Corruption https://postgres.fm/episodes/corruption Connection poolers https://postgres.fm/episodes/connection-poolers Index maintenance https://postgres.fm/episodes/index-maintenance StackGres supported extensions (Michael was wrong, it also has a timescale_tls extension!) https://stackgres.io/extensions/ postgresql_cluster https://github.com/vitabaks/postgresql_cluster Supabase self-hosting https://supabase.com/docs/guides/self-hostingTembo https://github.com/tembo-io/tembo Open source licenses, clouds, Postgres (Postgres TV discussion) https://www.youtube.com/watch?v=1rcbyIjA4gI&t=149s ~~~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 brought to you by:Nikolay Samokhvalov, founder of Postgres.aiMichael Christofides, founder of pgMustardWith special thanks to:Jessie Draws for the amazing artwork 

Hello and welcome to Postgres FM, weekly show about all things PostgresQL. I am Michael, founder of PgMaster. This is my co-host Nikolai, founder of Postgres AI. Hey Nikolai, what are we talking about today? Hi Michael, your turn. Yes, so you chose this topic. We're going to go deeper into self-hosting Postgres. Self-hosting Postgres. Yeah. We had an episode number two more than one year ago, and we compared managed versus self-managed.

Self-managed, self-hosted, is it the same or no? Whoa, good question. What are we including? There is a difference. There is a difference, which probably right now is not visible yet, but it might become more visible over time in the future what i mean in the past we had the model before clouds we had the model when for example oracles was selling for different like microsoft was selling databases as like kind of box right you have software you pay for the license but you then you need to install it yourself probably, right?

And so on. It's like self-hosted, self-managed. But then cloud model showed that there is a new way you don't manage it. You have only SQL connection. You cannot even run top. You don't host, you don't manage. But what if we think you can host yourself, but allow others, I mean, the vendor, for example, manage it remotely?

I think it's possible. And I think several companies are already experimenting with this approach. So I would distinguish self-hosted and self-managed. But today I think we can discuss mostly the case when we have self-hosted and self-managed. So we want to install a purely open solution to our servers on-premise or in cloud, and then deal with all the troubles.

Yeah, great point. I think self-managed is a better definition then, because we don't care if it's on the cloud still, do we? It's the fact we're having to manage it ourselves that's important to this. Right, right. So where to start? And let's warn our audience that we will have two sides of discussion, technical and less technical, non-technical. And technical will be, let's discuss what kind of tasks do you need to solve and which tool probably you need to use and challenges,

technical challenges. And second is less technical about probably where the market is moving and why we don't have what I described, like self-hosted, but managed by some other companies. So you can offload this responsibility to some experts and don't grow in-house expertise. And probably the second discussion, we can just touch it because it's a bigger topic. And let's focus more on the technical side. But definitely let's touch the second side as well. Yeah, absolutely. Great.

So should we start with the more technical, like what the kinds of things that if you're choosing to manage it yourself, the kind of things you have to think about? Yeah, let's consider what is Postgres. Postgres is quite good. Postgres is a very bad database system. Very bad database system. But the others are just worse. Okay, I haven't heard that before. Well, it's from England. It says Churchill saying about

democracy. So I just phrased it. Right. Actually, I see so many bad things about postgres. So many that I can claim this and prove it. But other database systems are definitely worse. But the thing what I'm trying to say right now, Postgres is not a product. It's just one of the pieces you need. It's a core, it's like engine of your car, right? But you need also wheels, you need the trunk and seats, belts, and so on. I think the core idea is really important. I think a lot of comparisons I've seen

are to like the Linux kernel. But I also think of it a bit of like a platform, you can use it on its own, but it's much better if you've added things to it. So I think it's... You cannot use it on your own. You cannot use it on your own. I mean, it's nonsense. It's like you don't put data to files, right, and deal with synchronization. You want SQL somehow.

You want ACID, but it's obvious you want autofillover, you want backups backup verification pulling because postgres lacks all of them right yeah yeah it lacks some of them and some of them it's it there are better tools available i agree so actually backups is a great place to start because that feels like something everybody's gonna want exactly backups as probably should be like number zero always. And I had a discussion a couple of days ago with my old friend who was self-managed,

but recently they moved to RDS. They don't like some things, and they also, of course, don't like price because it roughly doubles the costs compared to also AWS, but self-hosted. They lack some things, like, I don't know, it doesn't matter. But I asked him what is the number one reason why they moved on RDS. And he said the constant fear of having issues with backups is number one reason.

So backups, you're right, should be number one. But not only, we know unverified backup. There are two mantras. There are two mantras around backups. Dump is not backup. First mantra. And second, unverified backup is not a backup. It's a Schrodinger's backup so you need

to verify your backups you need to test them always and moving to rds gives you some confidence that backups are fine you don't see verification signals that but you see backups are created good you know point-in-time recovery is implemented there you can use it you don't see verification tests like results of the tests of those backups you don't see you don't have the list of okay this backup is verified but at on at the same time you know that you can trust rds backups because you know rds is very popular people are not complaining so it feel it feels like you can trust backups RDS has right but if you're self-hosted you need to use some tool to have full-fledged physical backups with point-in-time recovery to minimize RPO, RTO. I'm not going to clarify RPO, RTO here

because we had an episode about it as well. And you need to test them. And testing is super important. It requires effort because, for example, for Wolja, I don't know if testing capabilities exist out of the box. For PGB, probably they exist. And the fact that we have multiple backup solutions for Postgres means that Postgres lacks something.

What does Postgres lack? Postgres is not a product. It's just an engine. It's not a product. You need to productize it yourself if you need to self-manage. And the more databases you are going to have, our last episode about sharding and also Microsoft's approach, if you need just a few databases, probably you can be okay and do some manual stuff. But if you are going to have hundreds of databases, you need very good automation.

This is what I mean productized. You need some scripts, buttons, APIs, CLIs to make Postgres to play well together with Volji or pgbackrest or something else. Or maybe you can leave without them, but it's harder because they provide some functionality Postgres doesn't have. I think the key thing you said was if you want point-in-time recovery, which most people do. Do you want transactions? Some peopletime recovery which most people do like do you want transactions some people can say we can live without transactions okay you can live without

point-in-time recovery until you have some issue and then you are very like sad because you don't you didn't think about in advance of course everyone needs point-in-time recovery but i think that's why i think it's worth explaining that's why you're saying Postgres doesn't include backups, because it doesn't include a point-in-time recovery solution. No, no, no, no, no. It includes point-in-time recovery, but you can think about it like Postgres has like API for it. Like the PG-based backup, you mean?

Yeah, it has recovery target LSN, it has some configuration, it has some handles, but you need something that will use it like an interface right of course we know postgres doesn't have ui right so i'm not talking about ui here but of course it would be good to have ui like you open and see backups you can navigate them you can search you can understand which backups failed probably, like you receive also, you have monitoring, you have alerts, this is needed actually. And Postgres doesn't have it itself. It has only, it exposes some API, so to speak, right?

But some additional tool needs to automate it, and this is exactly what WorldG. By the way, WorldG also doesn't have alerts and and monitoring and ui and so on and it has quite interesting cli which probably is not excellent and sometimes you need to do the math yourself taking two lsns and understanding how much for example barman would say okay yesterday we generated two terabytes of wall. WallG doesn't say it. You need to take to LSNs and go do the math. Okay. So, I mean, it takes some features here, right?

But at least it implements this automation for backups and handles all the things so you can just work in CLI. You probably want UI for it, and you definitely want monitoring and alerts. And I think you mentioned something right at the beginning that doesn't always get mentioned, which is you need to set up backups, but you also need to set up testing. So restoring and doing some checks to make sure your data is there and not corrupt and working as expected.

Yes, and I know while PGB Crest has is there and not corrupt and working as expected. Yes. And I know while pgbackrest has better, has something for testing, wlg doesn't have like special command to test and also pgbackrest has checked some verification for backups. Great. So you probably need to take care of it yourself to have some periodical jobs. If you're in cloud, it's easier. You can start some machine and temporarily, maybe even a spot instance, understanding that you can lose it just for budget saving.

And you can restore there and then report and get rid of it. By the way, reporting here is very interesting because sometimes restoration takes longer. So reporting, and for example, if it fails, it won't report. So we need additional system which will report if backup is not created by some time of the day which we know it should be already created by. Like if you had the phrase dead man switch, that kind of thing. Yes, and this is exactly this name,.com, right?

So you can use that as an external tool, which will tell you that backup didn't come on schedule. And you can also additionally add some corruption checks there and so on. So it's not a trivial thing. And if you want product, this is exactly what RDS provides you, right? Or other managed services. But they hide the testing jobs probably.

Well, I think they don't test each backup, of course, because it's too expensive, but they should test it occasionally, some of them, and have some coverage to understand if everything works well or not after they change some things in backup pipelines so it's not simple topic at all and it touches also monitoring and alerting which is like global thing for all things you will need it and there is no we know i like to say there is no ideal monitoring yet for Postgres. It doesn't exist, unfortunately,

especially if you consider only open source. You will deal with a lot of things missing in a standard Postgres exporter for Prometheus, and then visualization sucks always. I mean, dashboards in open source tools, I don't see any very good solution, and so on. Well, and and you mentioned an important thing, even in the the open source ones, the alerting is never included, right? Like that's that sometimes really important. Like, imagine what a common failure cases running out of disk space, you need an alert on that, like you need an alert on simple alert. Yeah. So great point. I'm scared of time.

Discussed at least half of year of hard work for a couple of people if they want to be prepared to run hundreds of notes, but like, I'm afraid if we continue, someone will say, Oh, it's so hard. hard okay convinced i'm going to buy rds but this is not the goal i i wanted to pursue at all so so i i'm big fan of self-hosted but you can you can start with simple versions of these right set up simple testing set up simple monitoring sorry backup testing set up simple monitoring. Sorry, backup testing, setup, simple monitoring. Yeah.

Simplest monitoring is probably just net data. It's like one line and you have already something quite well covered. And Postgres plugin is being developed quite well. I see. It's not perfect. It lacks a lot of stuff, but it's already something. And it can provide you system level, like host stats monitoring and Postgres plugin. Like it's a very good thing.

BPF it has as well, like something. If we continue, we will need like an hour to, yeah, I know to list all things we need. Like let's probably walk very fast. Other must have components.

If, if you want to self managed backups, auto failover, of course, right. We had, we discussed itailover, of course, right? We discussed it many times. Like, just use Patronium, that's it. Yeah, other options are available,

but that's the tried and trusted one, isn't it? Yeah, what else? You've mentioned major upgrades already. I think there's a couple of settings that are really important when you're first setting up. We did a whole episode on configuration, but there's a couple that require restarts that are really important when you're first setting up. We did a whole episode on configuration, but there's a couple that require restarts that it'd be quite helpful to have on from the start. So yeah, making sure you've checked your config

because you're not getting that set up for you. And they're quite conservative by default or a couple of the settings aren't very sensible by default for most setups. Checksums, you talked about enabling those, like things like that. Uncheck automation, actually. Amchek automation is very important.

I recently saw that one hosting provider which provides managed Postgres. It's not the biggest one. It's somewhere in Europe. They use Zalando operator. And we have a client who uses them. And this hosting provider somehow screwed up some migrations or upgrades. So thanks to Postgres 15 warnings about collation changes, it was detected that many indexes,

bitter indexes, got corruption. And you need Amcheq. And you need to automate Amchecheck with heap all indexed. Because I recently told you, I discovered Amcheck also is able to check heap. So you can check both B3 indexes and heap. This is great. So corruption checks should be automated and just should be a button. I want to check and see if I have some issues, right?

Yeah. In the spirit of running through a few more quickly, extensions. So like PG stat statements won't be on by default. So things like that that would require restart are worth checking if you've got them on from the start. And that will help on the monitoring front, of course. And the big one that gets brought up a lot as well is a connection puller. If you're anticipating you're going to have it or going to need a few hundred connections. And we're going to have connection puller war in at least battles in the upcoming years

because several teams develop alternative solutions and it's becoming more interesting. So yeah, connection puller is I think also should be included. What did I miss? Well, you missed a lot of things. For example, index automation, getting rid of bloat, bloat control, some health check tooling to see do we have unused indexes, index maintenance. We had an episode about it.

It's great to have some automation and tooling for it. And when I say it's great, it means 99% of people will need it eventually. Yeah. And not just self-hosted, not just self-managed. Of course. Currently you need this everywhere, yeah. Yeah, and I don't know any good provider which has it

already. Not yet. No. Right. You probably need something to help your developers with if you have

developers, backend engineers with queue pattern in database. For example, you could install PGQ but it

feels old and outdated. There are other solutions which you probably would like to use and probably it's another component if it has some additional pieces you need to install.

Yeah, new one just came out recently, didn't it? Right. You probably need PGA vector or PGA embedding as well, extensionally, which is super popular. Well, it's not a joke. A lot of companies right now try to adapt LLM into their technological stack.

So if you're a Postgres user, why not? And PGA Vector is receiving this HNSW new algorithm, new type of indexing, which is better for high-dimensional vectors. And PGA Bending has it from beginning. So there are many things we can talk about. Log analysis, very important, can be considered as a part of monitoring, but yes, not only. Yeah. Because many things that are quite important aren't logged by default. So yeah, settings are conservative there as well. But what if not only you don't want to develop everything, but you also don't want to play a Lego game? What are the options?

I see two big options here. One is become the fan of Kubernetes and start using one of numerous operators. And it's great to have alternatives already. It's a land operator, crunchy operator, and Stagress, which Stagress feels more like product, more pieces like bundled together and so on. They don't provide a SaaS,

so they don't care about SaaS right now. And actually, Solando also doesn't care about SaaS. But they developed for their internal needs, while Crunchy has Bridge. So interesting to think about how complete the solution is and licensing also. So it's an interesting area. I think you're missing something.

I think there is quite an interesting trade-off here because some of the reasons you might have wanted to self-manage in the first place, you might lose if you go down one of those routes. An example you brought up... Yeah, let's say you pick StackRest. Let's say you're considering StackRest, but you want timescale-licensed features. I don't think you can have that right now.

Whereas if you self... I think they only support the Apache 2 version. I'm not sure. You should check. I did check. Okay, okay. But what I mean is if you're self-managed, you can install that. So if you want full control of the extensions you installed

and you don't want the operator to control that, there's an interesting trade-off there. I think you can have... If you can have it at all, you can have it in Staggers as well. I thought you said they controlled which extensions you can even install. Ah, yeah, you are right.

This I don't like, by the way. It should be fully open, but it's hard to implement and so on. Yeah, yeah, yeah. So I agree. Postgres is philosophies, extensibility, openness, open source, everything. And you not only you should be able to install any extension, including that extension you developed yesterday yourself, right? Why not? So I mean, you're bringing up the philosophical question i'm talking about in practice in practice if i want pg embedding but it's not yet available staggers has hundreds of

extensions supported it's great but i think it should be changed somehow to be fully open and i discussed it with them but somehow we have slightly different use here. So my idea, it should be fully open, fully open anywhere. If it's purely like Postgres style product. But also you should be able to recompile Postgres if needed. Why not? Sometimes I want to change some constant in the source code and recompile or add some things I want to have. But it's a very good question. Is it possible in Stugger's? Probably

it's not yet possible. I know they think about it. I'm not sure about other Postgres operators. Is it possible to use a different Postgres image to change it? I think it should be possible. You should change source code and start using it. This will mean it's true Postgres product. But this is kind of what I meant that some of the reasons when people might be self-managing in the first place might prevent them using one of these if there's a limitation currently. So I think it's a really interesting point that you kind of move towards no longer being self-managed at that point. If they're managing a lot of those things for you, if they've got a lot of those automation things in place,

maybe you get a lot of those benefits again. But I'm just asking if there are downsides too. Right. And I think there should be some route where I can use defaults, which are very well tested and prepared by vendor of this product, developer of this product. Probably I will be paying for support of this if I want to offload some work, right? But if I need to deviate and I have engineers who can recompile Postgres, for example, if it's very needed, right? Or switch to version which is like, I don't know, like 16 beta 3, which is out a few

days ago. But they don't have it yet. It should be possible for purely open source product to switch to it. There should be some way to install an extension, recompile, switch to new version, it should be possible. In this case, it's great and it's fully open approach. But what if I don't want Kubernetes as well? I know it's easy to get Kubernetes from cloud, but what if I want to run everything on my servers and managing Kubernetes, it's a very big task as well. It's already, yeah. So in this case, I think we also have some new trends, which probably will give my idea development.

So my idea, again, like to have managed services, managed Postgres providers, they showed how a good product can be built on top of Postgres. They did it. Great. But they are not open. They are it. Great. But they are not open. They are proprietary. For example, as I tweeted a few days ago, show me the source code defining RDS super user. We don't know how it is defined. Being able to check source code is essential for me as a specialist, as an engineer, because sometimes I like things in documentation. I don't want to go to provider and play the game like if a good support engineer who knows

things or no, I spend days trying to reach expertise. I would just look at source code and understand how it works. Give it to me. But they don't open it. It's proprietary software. So many, many managed service providers do the same. Some of them already use publicly available open operators for Kubernetes. Good. But in this case, at least I know where to look at. For example, the same guys where we talked about corruption, I said it's probably related to

operational system switch. And I immediately had idea like what's happening there, I immediately found a pull request in spiel, which is used by salons operators pillow is a container image, which includes postgres, all major versions for major upgrades and so on. And as I found they recently switched to one Ubuntu to different Ubuntu, which is probably the reason of corruption, right? And they have some flag to bring locales from old Ubuntu.

Some hack, interesting hack. And actually, Kukushkin mentioned it in private discussions. That's why I actually knew where to look at. But interesting that this flag is disabled by default. And I guess that provider forgot to enable at. But interesting that this flag is disabled by default and I guess that provider forgot to enable it. And they don't have corruption control as I mentioned, everyone should have it.

For B3s and they had corrupted indexes. And I just immediately sent this line of code to my client saying, go to your provider and just show them this line and this pull request, and that's it. This is the power of open source. You just read the code, understand what's happening

under the hood. And if you use managed service provider, you don't have it. So self-managed, consisting of purely open source components has this power, full transparency, what's happening inside. If you have engineering skills skills you can tweak it and fix it and contribute back actually and so on so question is can we have same level of convenience as rds provides but fully on open source components but and also without kubernetes i i mean kubernetes is great if you can if you already have it it it makes sense to continue, extend it to databases. But if you either move away from Kubernetes, I already know some teams who move away from Kubernetes, or you just want to avoid it, do we have anything which would provide the same level of convenience?

And I know three products already, maybe three, I don't know. First is Vitaly, who works with me, has PostgreSQL cluster, open source product, MIT license. It's just Ansible playbooks, which easily install Postgres, PgBackrest or WorldG, PgBouncer, monitoring like NetData or PgWatch2, and what else? Timescale is just a flag, right? And many, many other things.

And it's just a snippet which installs on any server. Patroni, of course. Patroni, PgBounce, I mentioned, right? So it will install it to multiple nodes and you have cluster with HA characteristics, with backups. I think it lacks backup verification. This is like it should be solved.

But it's solvable. And this already is an alternative to RDS without Kubernetes. Very good thing, right? So I would like to explore if this project can be improved and be used by more people. It's an interesting project, I think. I don't like Ansible output because you either have very verbose... So it's very outdated.

Ansible CLI feels very outdated. It's either very verbose or it provides you some steps and you don't know what's happening right now. No progress indication and so on but i think it's also solvable so i think this is a very interesting project for those who want self-hosted to have everything bundled like one product and without kubernetes it's but i think it's also not product again because it lacks some things like this backup verification.

It lacks UI, for example. But it's possible. It already saves a lot of effort if you want to go self-hosted without Kubernetes. You mentioned you knew a few products. What were the other two? I just discovered Superbase, went to monorepo approach, and they have everything under Apache 2.0, meaning that they have control plane they call it dashboard right or i don't remember right so control plane you have ui you have

automation you can install it yourself and have super base super base is also a bundle it's a product they also play this productized game they play a lego game for you so you have all components of your car not only engine so it's posgus it's uh what else like they have a puller definitely they have their own puller they have additional components which are more oriented for back-end and front-end engineers it's api using pGB Crest. Oh, sorry, Postgres. REST there and here. But in PGB Crest, REST means restore. Here it means REST API.

So PGB Crest, also additional components, real-time to make it feel like Firebase. So if change happens in database, you can easily propagate it to application and authentication and so on. So you can use them on your own, self-hosted, and this is a well-tested solution as well. At the same time, I discovered a few months ago they don't have HA, so they didn't have standbys. I think they should already solve it by now. I'm not sure. Did you mention there was a third one?

Third one is probably a new player which was called CoreDB. Oh, yeah. Tembo. I know they want Tembo. They renamed. I know they want to open source everything. They don't have much yet, right? They don't have anything we can do today.

I would keep an eye on this company as well. But probably they will release some good solution which you can use on your machines, even if it's not cloud. How do you know they won't go with Kubernetes? Oh, I don't know, actually. Maybe it's Kubernetes, but maybe not. Actually, good question.

I don't know. Talking to them, I just know they share this philosophy that open source should have some new cycle of development. Because we see many companies who already became quite popular, they move away from open source, sadly. And HashiCorp is just a new example here. Before that, we had database companies like MongoDB and Elastic. They moved away. It's like CloudWars and so on. But I think this opens opportunities for open source to have better product level. Not just features, but to feel like a product.

Because some open source projects, they have this feeling you have UI, you have just magic button that handles everything and it's well maintained. So it happens. For example, Ubuntu, right? So we have Linux, good open source project, but Ubuntu is also open source. And it took a lot of time to achieve some level

where usability is good, but it's already happening. Ubuntu is already not bad, right? Yeah, it's going to be interesting, right? Like the thing that seems to be driving it is business models. And historically, the business model that worked around open source, well, the two big ones were support-based. So you could make your business offering support for the system

or companies that it's not their main differentiator collaborated on building a system. So I think those two combine to make Postgres work, right? So companies that wanted this and needed this working together and separately support companies built around supporting systems. That's a super interesting question. I agree. I agree. And I'm super curious how

Superbase investors are feeling because they open everything. They, of course, are champions in growing attention of meme-style marketing. They're champions here. So people go to their Twitter and listen to them a lot. It's great. So probably they just are okay to open everything, but they know that they are able to drive traffic to their own SaaS, like pass or how to say, as a service offering where they can make money. But also like anyone can run Superbase, it means, right? Including Amazon. Right, SuperBase 2.

This I don't understand. Probably nobody understands. I don't know. This is a super interesting topic, less about self-hosted and so on, but it's interesting. And I would like to explore. I decided to open source everything as well. So we just released, we didn't announce, but it's already stamped, Database Lab Engine 3.4. But I planned to switch from AGPL to Apache 2.0 only in future version 4.0, which still like in alpha, soon will be in beta. This morning we discussed with the team, and I decided that we will announce 3.4 database lab engine,

DB lab engine right now. And in a few days, we will make 3.5 just to change license fully to Apache. And we will open source everything. I don't know if I fail in terms of business, but I like the openness and I like open source. And I know there are people who feel the same and would like to see new wave of open source rise. We know this concept like cloud aid open source, but I think things might change. Let's see. Yeah. I just remember we actually had a discussion about this on Postgres TV relatively recently. Yeah, yeah, yeah.

It was that conversation. So I'll link that up in the show notes as well. Right. Who knows what will happen? But I have a feeling that right now it feels like open source is losing to clouds and companies move away from open source. But this might be just a sign that we will have a new way for open source in the future because believers like some people like i'm going to be believer in open sources like i can i want to bet on open source fully i think they will develop good uis you know

good automation everything they do they will do just because they want like you know i want to live in the world where code as knowledge is shared freely i think we deserve this world not like companies who like hide everything so code should be shared i have to disagree a bit being a provider of a closed source tool but i think there's something to be said for platforms that are open being very very very very valuable and if we can collaborate on the what's in the middle what's the platform that's serving a lot of these things everyone can build on top of that whether that's open source closed source and people choose how which which components they want. I understand the purist thing, but I do think there's a separate argument here that's not

inherently bad. Let's discuss it another time. Sure, sounds good. Thank you, Nikolai. Thanks, everyone. And catch you next week. Thanks to our listeners. Don't forget to share with your colleagues and friends who work with Postgres and please provide some feedback and the likes as well, especially on, I don't know, like on YouTube, Twitter, LinkedIn,

everywhere you can see our podcast. Please support us. Thank you so much. Bye-bye.