WEBVTT NOTE This file was generated by Descript 00:00:00.038 --> 00:00:03.938 Michael: Hello, and welcome to Postgres FM, a new weekly show 00:00:03.938 --> 00:00:05.368 about all things PostgreSQL. 00:00:05.948 --> 00:00:09.428 I am Michael I'm from pgMustard, and this is my co-host Nikolay 00:00:09.728 --> 00:00:11.348 founder of Postgres AI. 00:00:11.618 --> 00:00:12.268 Hello Nikolay. 00:00:12.268 --> 00:00:12.938 How're you doing? 00:00:13.388 --> 00:00:14.768 Nikolay: Hello, doing great. 00:00:15.218 --> 00:00:15.758 How are you? 00:00:15.968 --> 00:00:18.728 I'm still, I'm still traveling, still traveling right now. 00:00:18.733 --> 00:00:20.048 And Prague prag is beautiful. 00:00:20.048 --> 00:00:23.498 So let's, let's talk about some Postgres stuff. 00:00:24.358 --> 00:00:27.263 Michael: Oh, so good, very jealous, but also I'm, I'm in the UK and 00:00:27.263 --> 00:00:28.973 it's about 28 degrees at the moment. 00:00:28.973 --> 00:00:30.893 So it feels like summer finally. 00:00:31.553 --> 00:00:37.163 Yes, so today I was keen to talk about hosting of Postgres. 00:00:37.163 --> 00:00:42.611 So specifically, when should people choose a managed Postgres service 00:00:42.671 --> 00:00:44.771 versus DIY or do it yourself? 00:00:44.921 --> 00:00:47.951 Should people even be considering do it yourself these days, if 00:00:47.951 --> 00:00:50.281 they opt for managed, what are the best options out there? 00:00:50.281 --> 00:00:51.031 That kind of thing. 00:00:51.511 --> 00:00:51.991 So, yeah. 00:00:52.041 --> 00:00:53.871 I'm really keen to hear your thoughts on this. 00:00:53.931 --> 00:00:55.191 What are you seeing at the moment? 00:00:55.701 --> 00:00:59.746 Nikolay: My thoughts are we should always go the DIY path. 00:00:59.926 --> 00:01:03.706 We should always compile kernel of Linux, and so on. 00:01:03.826 --> 00:01:07.686 I'm joking of course, but the opinion's changing actually, right? 00:01:07.686 --> 00:01:15.291 Because, if you are DBA back in 2005 to 10 and you see something which 00:01:15.341 --> 00:01:19.931 replaces part of your work, uh, probably you will, you will be very skeptical. 00:01:20.591 --> 00:01:20.861 Right? 00:01:21.251 --> 00:01:21.911 What do you think? 00:01:21.961 --> 00:01:22.591 Michael: Well, yeah. 00:01:22.641 --> 00:01:26.701 So I deal probably with more smaller companies, startups, generally. 00:01:27.826 --> 00:01:31.576 And I can't think of the last time I saw somebody starting a new project 00:01:31.966 --> 00:01:37.001 DIY, but I do hear and see about it a lot more in larger companies. 00:01:37.006 --> 00:01:40.121 And some of those startups that are getting big, they're starting to 00:01:40.511 --> 00:01:44.631 consider, maybe for cost reasons, maybe for a little bit more control. 00:01:45.001 --> 00:01:48.036 They're starting to consider taking things, if not completely 00:01:48.036 --> 00:01:52.696 DIY at least, you know, still on Amazon, but not RDS, for example. 00:01:53.746 --> 00:01:58.086 Nikolay: Have you seen ever like a company who started, like 10 or 15 years ago. 00:01:58.086 --> 00:02:00.806 And they started with self-managed Postgres and then 00:02:00.806 --> 00:02:02.416 moved to RDS or something. 00:02:02.476 --> 00:02:02.896 Michael: Yes. 00:02:02.901 --> 00:02:06.666 So I think I actually saw them blog about it recently, so I think it's 00:02:06.666 --> 00:02:12.871 okay to mention that the team at Auto Trader, which is a big, secondhand 00:02:12.871 --> 00:02:17.171 car, online dealership in the UK, I think they're in the process of, 00:02:17.171 --> 00:02:21.171 or maybe now have completed their migration to Google Cloud SQL, from 00:02:21.171 --> 00:02:26.061 what I believe were, if not completely self-hosted then self-managed databases. 00:02:26.606 --> 00:02:29.306 Nikolay: I saw a couple of examples as well, uh, including 00:02:29.306 --> 00:02:30.626 some very large companies. 00:02:30.626 --> 00:02:34.386 And, I've noticed that they just understand that, managing Postgres 00:02:34.406 --> 00:02:36.956 probably is very difficult. 00:02:37.406 --> 00:02:42.496 Also, I think it depends on how big your databases and workload, if you manage 00:02:42.496 --> 00:02:46.546 to split for example, to microservices and you have dozens of databases, it's 00:02:46.546 --> 00:02:53.021 easier for you to go to RDS because limits are quite far so, so, but if you 00:02:53.021 --> 00:02:57.951 have very heavily loaded huge database, probably it'll be challenging because, for 00:02:57.951 --> 00:03:04.231 example, discs on RDS, regular RDS, they are like network attached, EBS volumes. 00:03:04.261 --> 00:03:09.291 So if they're not local and so latency is a bit higher, of course. 00:03:10.131 --> 00:03:14.751 So, it's tricky, but I saw examples, the specifically microservice 00:03:14.781 --> 00:03:16.521 architecture and very big company. 00:03:16.941 --> 00:03:20.841 They decided by purpose to get rid of any self-managed, but 00:03:21.501 --> 00:03:23.421 as usual, it takes many years. 00:03:23.721 --> 00:03:25.671 So it's a combination usually. 00:03:26.541 --> 00:03:29.801 Michael: Well, so that's a good, like, is that almost a rule of thumb that 00:03:29.891 --> 00:03:35.456 if somebody's got either one or a lot of smaller databases, there's probably 00:03:35.516 --> 00:03:39.196 not a good, are there any good reasons if I've got one or lots of smaller 00:03:39.196 --> 00:03:42.136 databases to not use a managed service? 00:03:43.756 --> 00:03:49.796 Nikolay: Well, I think, if you consider some already grown company, you have many 00:03:49.796 --> 00:03:52.616 databases, probably like two big reasons. 00:03:52.621 --> 00:03:57.541 I see first is, to move, small databases to manage services and 00:03:57.691 --> 00:04:01.691 just not to think about backing up, replication of the follower about, 00:04:02.021 --> 00:04:04.511 but also there is another big reason. 00:04:04.621 --> 00:04:10.076 This reason understood usually by upper management, not by DBAs 00:04:10.076 --> 00:04:13.646 because DBAs usually think like, let's do everything yourself. 00:04:14.036 --> 00:04:15.836 Like, let's keep it in our hand. 00:04:15.886 --> 00:04:21.286 Yeah, let's have access to PGDATA and so on, or like process list and so on. 00:04:21.706 --> 00:04:27.916 But upper management thinks like it's, it's better to rely on, Amazon or Google 00:04:28.246 --> 00:04:33.946 engineers and their infrastructure in terms of backups and, uh, related 00:04:34.426 --> 00:04:41.296 like RPO RTO related service level objective objectives, instead of 00:04:41.596 --> 00:04:46.096 trying to hire a lot of good experts, it's very hard to find good experts 00:04:46.096 --> 00:04:48.646 and scale the process of their work. 00:04:49.036 --> 00:04:52.696 So this second reason, I think it's for bigger companies. 00:04:52.696 --> 00:04:53.656 It's very important. 00:04:53.746 --> 00:05:00.436 Uh that's why like, like RDS and others are growing. 00:05:00.556 --> 00:05:04.096 I think I don't, I don't have numbers, unfortunately, but I think, 00:05:04.126 --> 00:05:10.391 from, as you said, like, everyone is on managed already, but not 00:05:10.391 --> 00:05:11.681 everyone, actually, not everyone. 00:05:12.791 --> 00:05:16.621 And sometimes people go back actually sometimes, but not often. 00:05:17.876 --> 00:05:21.266 Michael: Yeah in well, could you give us, do you know any, any examples or 00:05:21.266 --> 00:05:22.856 the reasons why they went backwards. 00:05:23.416 --> 00:05:25.211 Nikolay: Well, the price is big reason. 00:05:25.216 --> 00:05:25.841 Of course. 00:05:25.841 --> 00:05:30.191 If you manage Postgres yourself, for example, on EC2 instances and you, you 00:05:30.196 --> 00:05:34.041 can have one year, three year contracts, there are ways to optimize the price and 00:05:34.611 --> 00:05:37.681 it's will be definitely, cheaper than RDS. 00:05:37.681 --> 00:05:42.206 So then you can do additional infrastructure optimization, in terms 00:05:42.226 --> 00:05:48.056 of backups and various clones, for non-production use and so on so it's it's 00:05:48.056 --> 00:05:53.211 of course, like much cheaper, like I would say roughly like up to two times cheaper, 00:05:53.721 --> 00:05:56.571 but cost is sometimes not a big driver. 00:05:56.931 --> 00:06:00.681 I think it will change by the way we are in the beginning of some crisis coming. 00:06:00.681 --> 00:06:05.976 So maybe reasons will like reasoning will start changing but, uh, also 00:06:06.216 --> 00:06:10.806 moving back sometimes like a weaker reason is, uh, pure technical. 00:06:10.806 --> 00:06:16.536 So to, to troubleshoot some weird things, it's not a fun when you go to RDS and 00:06:16.746 --> 00:06:21.426 say something like we have an issue and their engineers say it's a Postgres issue. 00:06:21.546 --> 00:06:26.066 You go to Postgres experts, even sometimes to, to Postgres mailing 00:06:26.066 --> 00:06:27.956 list or some various chats. 00:06:28.286 --> 00:06:31.436 And they say RDS is not Postgres. 00:06:32.216 --> 00:06:38.066 Work with RDS not fun to be between if very, very difficult incidents 00:06:38.126 --> 00:06:40.946 happen and you don't have full access. 00:06:40.946 --> 00:06:43.466 So I've been there a couple of times with my clients. 00:06:43.466 --> 00:06:44.576 It's like, it's not fun. 00:06:45.236 --> 00:06:50.936 so this is a technical reason to move back to and take full control, but you need 00:06:50.936 --> 00:06:54.176 to have very strong experts to do that. 00:06:54.176 --> 00:06:55.676 Michael: Really good point about the, about 00:06:55.706 --> 00:06:56.336 Nikolay: Oh, there is. 00:06:56.456 --> 00:06:56.546 Michael: and 00:06:57.376 --> 00:07:00.371 Nikolay: Third reason there is third reason as various extensions and 00:07:00.371 --> 00:07:02.831 capabilities that RDS doesn't offer. 00:07:03.311 --> 00:07:03.551 Right. 00:07:03.941 --> 00:07:05.471 Michael: This is the one I wanted to bring up. 00:07:05.471 --> 00:07:11.381 I think this is more of a reason to start on a DIY or maybe, maybe one of 00:07:11.386 --> 00:07:15.311 the only reasons to start on DIY is if you really want an extension that 00:07:15.341 --> 00:07:19.361 isn't supplied by the managed service part of it that you want to go with? 00:07:19.781 --> 00:07:23.356 I am seeing some of the newer ones really aggressively go after 00:07:23.356 --> 00:07:25.186 installing lots of the extensions. 00:07:25.486 --> 00:07:29.536 But if until a few years ago, a lot of them really didn't have 00:07:29.566 --> 00:07:31.156 even some of the contrib modules. 00:07:31.161 --> 00:07:36.016 I think as an example, I, I think Heroku still doesn't let people install 00:07:36.046 --> 00:07:38.176 auto_explain, which comes with Postgres. 00:07:38.926 --> 00:07:42.851 Nikolay: Heroku unfortunately, there were recently big discussions on Hacker News. 00:07:42.851 --> 00:07:46.936 So why Heroku has not been developed and it's a pity because it was a pioneer 00:07:46.936 --> 00:07:49.076 of managed Postgres many years ago. 00:07:49.076 --> 00:07:50.156 It was so great. 00:07:50.506 --> 00:07:55.181 But then they started to after acquisition by Salesforce, I guess they 00:07:55.181 --> 00:07:56.801 started to lag in terms of pricing. 00:07:56.801 --> 00:08:02.921 I remember helping several companies, at least two, migrate to RDS just because 00:08:02.921 --> 00:08:04.901 of pricing and also capabilities. 00:08:05.511 --> 00:08:06.541 I have currently. 00:08:07.386 --> 00:08:11.376 Three clients who want to migrate and they say, let's postpone a little bit 00:08:11.376 --> 00:08:15.946 implementation of, cloning stuff we Postgres AI are developing because we are 00:08:15.946 --> 00:08:17.961 in the process of migrating off Heroku. 00:08:18.471 --> 00:08:22.611 So, so I don't see anyone who is migrating to Heroku , unfortunately, but Heroku 00:08:22.611 --> 00:08:25.881 was great back to like 10 years ago. 00:08:26.586 --> 00:08:29.226 Michael: Well, I still think they have some features that others don't. 00:08:29.316 --> 00:08:31.656 So I think they, they come with better defaults. 00:08:31.661 --> 00:08:36.081 So once you upgrade off the smallest instance, they keep changing your various 00:08:36.086 --> 00:08:40.071 settings to keep up with your instance size in a better way, I think, than 00:08:40.071 --> 00:08:42.791 some of the bigger ones like, uh, RDS. 00:08:43.281 --> 00:08:47.546 I had a, a friend recently moved from Heroku to Crunchy Bridge, 00:08:47.551 --> 00:08:48.986 which is one of the newer ones. 00:08:49.046 --> 00:08:50.656 A lot of the team behind Heroku. 00:08:50.926 --> 00:08:53.686 I was really surprised by some of the defaults still there. 00:08:53.691 --> 00:08:56.986 And the, there was, not as good documentation, but 00:08:57.016 --> 00:08:58.636 everything else looks amazing. 00:08:59.036 --> 00:09:02.516 But he ended up migrating back to Heroku and upping his instance size. 00:09:02.516 --> 00:09:06.116 I think he thought some of the reliability was, was on the Heroku 00:09:06.116 --> 00:09:09.086 side, but it turned out it might have been something he was doing instead. 00:09:09.416 --> 00:09:13.356 So it was interesting to see somebody that does rely on some of 00:09:13.361 --> 00:09:17.756 the Heroku features, really valuing those and ending up migrating back. 00:09:17.996 --> 00:09:20.636 And the other thing I think they do that most of the others don't 00:09:20.636 --> 00:09:26.066 do nicely yet, at least is major version upgrades, mostly for you. 00:09:26.306 --> 00:09:29.656 Uh, now I think they require a little bit of downtime, but, I only just recently 00:09:29.656 --> 00:09:31.486 saw that added to Google Cloud SQL. 00:09:31.486 --> 00:09:34.306 So I thought that was quite a nice thing that they still do that others don't. 00:09:34.991 --> 00:09:38.851 Nikolay: Well, good thing here is that, the variety increases a lot 00:09:39.241 --> 00:09:41.461 and you touched Crunchy Bridge. 00:09:41.461 --> 00:09:47.221 So we should already add one more, set of players here, which are 00:09:47.221 --> 00:09:49.271 based on Kubernetes operators. 00:09:49.291 --> 00:09:49.501 Right. 00:09:50.161 --> 00:09:56.176 And I, like, I know Alexander Kukushkin the maintainer of Patroni not long ago, 00:09:56.206 --> 00:10:03.706 developed major upgrade automation for the building block of their operator. 00:10:03.711 --> 00:10:12.526 It's called Spilo so it's like container image for very ready to use in AWS. 00:10:12.976 --> 00:10:17.596 First of all, but not only I think, and, he managed to achieve good level of major 00:10:17.596 --> 00:10:19.746 upgrade automation with small downtime. 00:10:20.286 --> 00:10:21.966 So, it's improving. 00:10:22.386 --> 00:10:25.596 But I, I want to blame, manage services for one thing. 00:10:26.506 --> 00:10:31.151 They usually don't provide access to look at PGDATA and at least to have, 00:10:31.211 --> 00:10:33.581 uh, physical replication connection. 00:10:34.361 --> 00:10:34.661 Right. 00:10:34.901 --> 00:10:40.851 I remember like four, four years ago or so I met the founder of 00:10:40.881 --> 00:10:42.891 Aiven who is now big, very big. 00:10:43.011 --> 00:10:45.291 Uh, they raised a lot and they grow very fast. 00:10:45.901 --> 00:10:51.826 And, I asked him like, okay, very good, you are building similar, similar 00:10:51.826 --> 00:10:56.116 offering to RDS, but with more flexibility and more features probably and so on, 00:10:56.546 --> 00:11:00.506 can you provide, physical replication connection and access to PGDATA and so on? 00:11:00.776 --> 00:11:04.076 He said by default, no, but if you contact support, it's possible. 00:11:04.466 --> 00:11:05.186 Guess what? 00:11:05.186 --> 00:11:08.606 Uh, recently, their support answered. 00:11:08.696 --> 00:11:10.016 Of course, no it's not possible. 00:11:10.496 --> 00:11:12.956 So this, this whole is closed also. 00:11:13.316 --> 00:11:16.586 And lack of physical replication connection means 00:11:16.616 --> 00:11:18.356 some kind of vendor lock in. 00:11:18.356 --> 00:11:24.390 So if you want to migrate off managed service, you must use on the logical 00:11:24.390 --> 00:11:31.300 replication connection, which is quite tricky and complex has a lot of issues 00:11:31.600 --> 00:11:34.270 if you have a very heavy workload. 00:11:35.035 --> 00:11:37.555 Michael: And we're talking about, about big instances, right? 00:11:37.555 --> 00:11:38.875 Cause smaller ones. 00:11:38.875 --> 00:11:41.935 We still have the option of, dump and restore, I guess. 00:11:42.385 --> 00:11:46.190 Nikolay: Right, but, well, what does small mean today? 00:11:46.430 --> 00:11:49.700 Small today, for me, it's less than one terabyte already. 00:11:50.075 --> 00:11:50.315 Michael: Great. 00:11:51.170 --> 00:11:56.510 Nikolay: So I would not dump, uh, like, I, I, of course like when you do logical. 00:11:57.440 --> 00:12:00.320 Actually initialization is dump restore basically, right? 00:12:00.320 --> 00:12:01.940 So we need to do it anyway. 00:12:02.510 --> 00:12:04.880 Even for 10 terabyte database, we need to do it. 00:12:04.885 --> 00:12:07.540 And there are ways to speed it up, but, it's not fun. 00:12:08.110 --> 00:12:11.400 I would rather prefer physical copy of files. 00:12:12.900 --> 00:12:13.200 Michael: Awesome. 00:12:13.230 --> 00:12:15.270 Let's talk about upgrades another day, maybe. 00:12:15.630 --> 00:12:18.630 Um, it feels like a whole good topic and actually I'll put it 00:12:18.630 --> 00:12:21.730 in the show notes, but you did a really good panel with a few people. 00:12:21.735 --> 00:12:23.680 I think it was a Postgres Vision recently. 00:12:23.860 --> 00:12:24.820 Um, I enjoyed that, 00:12:24.835 --> 00:12:26.840 Nikolay: Yeah, it's interesting yesterday. 00:12:26.840 --> 00:12:32.420 They invited me to Postgres Europe conference to talk about upgrades again. 00:12:32.420 --> 00:12:35.180 And they also accepted database branching talk. 00:12:35.510 --> 00:12:40.970 But I want to say once again, it's my public position that, actually I already 00:12:40.975 --> 00:12:44.610 booked hotel to Berlin late October I'm going to come, it's very good, 00:12:44.850 --> 00:12:48.990 but I ask them, do they record talks? 00:12:49.170 --> 00:12:52.200 Do, do they have plans to publish it later? 00:12:52.205 --> 00:12:56.465 if they don't I probably will not come because this is my position. 00:12:56.465 --> 00:12:58.655 Everything should be recorded and published later. 00:12:58.865 --> 00:13:01.925 Like I understand this is a huge conference, 500 people. 00:13:02.435 --> 00:13:06.185 Some of them will probably come to my talk, but I want to 00:13:06.185 --> 00:13:08.315 have recorded session as well. 00:13:08.315 --> 00:13:12.005 And to be able to share and refer later to my materials, 00:13:12.065 --> 00:13:13.945 because for me, it's a huge trip. 00:13:14.365 --> 00:13:18.595 So that's why, like we talked today and this is good because if someone 00:13:18.600 --> 00:13:22.585 is interested in the comparison of managed versus non managed and 00:13:22.645 --> 00:13:25.315 Kubernetes, we can send a link, right? 00:13:25.532 --> 00:13:28.952 So, I must say all Postgres conference organizes, please 00:13:28.957 --> 00:13:30.932 record and publish share. 00:13:31.727 --> 00:13:34.537 Michael: And, uh, full disclosure, I'm not sure you knew this Nicolay, but I'm 00:13:34.552 --> 00:13:36.427 actually on the panel for the PGConf 00:13:37.142 --> 00:13:37.652 Nikolay: Yes. 00:13:37.712 --> 00:13:37.862 Yeah. 00:13:37.862 --> 00:13:38.972 I knew that, but I forgot. 00:13:39.002 --> 00:13:40.742 Yes okay. 00:13:41.657 --> 00:13:45.240 Michael: So yeah, I'm excited to see those, hopefully if you do come. 00:13:45.400 --> 00:13:49.103 Nikolay: So you also, can, pass my words to the organizers, right? 00:13:49.583 --> 00:13:50.333 Michael: Yeah, absolutely. 00:13:50.333 --> 00:13:53.273 And it's possibly worth giving a quick shout out to some of the work 00:13:53.273 --> 00:13:57.078 you've been doing on the Postgres TV channel to publish some of these talks. 00:13:57.078 --> 00:13:59.628 So some of these talks that were given that were not recorded in 00:13:59.628 --> 00:14:03.138 the past at different conferences, you've picked some of the better ones 00:14:03.198 --> 00:14:06.698 and, recorded them and put them on, remind me of the name of the series. 00:14:07.428 --> 00:14:10.548 Nikolay: It's it's called Postgres open talks because 00:14:10.788 --> 00:14:12.108 talks should be open as well. 00:14:12.108 --> 00:14:15.798 But like the idea of that series conflicts with my position to come to 00:14:15.798 --> 00:14:17.598 conferences that only recorded of course. 00:14:17.628 --> 00:14:22.098 But so if every conference starts to record and publish later and 00:14:22.098 --> 00:14:24.708 probably this series will be over, but I will be happy actually. 00:14:25.518 --> 00:14:28.248 Michael: That's a sign you really care about solving the problem isn't it. 00:14:28.248 --> 00:14:31.398 We're taking a definite tangent here, but I had the same experience with my 00:14:31.403 --> 00:14:36.508 browser extension for, redirecting people on the Postgres documentation nowadays. 00:14:36.778 --> 00:14:39.298 Yeah, well, yeah, but hopefully you won't need to soon. 00:14:40.153 --> 00:14:40.243 Nikolay: Right. 00:14:40.243 --> 00:14:43.063 Well, actually I should stop using, right, right, 00:14:43.633 --> 00:14:46.033 Michael: So, yeah, but I'm happy because I don't, I didn't 00:14:46.033 --> 00:14:47.653 want this extension to exist. 00:14:47.653 --> 00:14:49.993 I, I would much rather it worked first time. 00:14:50.093 --> 00:14:52.303 Nikolay: Yeah, Google search results are much better. 00:14:52.303 --> 00:14:55.813 I, I mean, we, we know the problem, but maybe our audience doesn't know the 00:14:55.813 --> 00:15:00.043 problem is that like, until very recently, if you search something related to 00:15:00.043 --> 00:15:03.703 Postgres, you saw some versions up to 7.4. 00:15:03.823 --> 00:15:06.593 So like some 7.3 and so on. 00:15:07.253 --> 00:15:09.113 Like very, very old and it was not fun. 00:15:09.213 --> 00:15:14.293 And people shared these links, very old thinking it's it's not old. 00:15:14.293 --> 00:15:17.293 And so like a lot of confusion, but it, it was recently solved. 00:15:17.323 --> 00:15:21.793 And I, I recently saw some example of not good occurrence, maybe should I should 00:15:21.913 --> 00:15:27.343 post it to the, the mailing list, but, uh, like 99%, it works very well right now. 00:15:28.258 --> 00:15:31.167 Michael: Sadly, I don't think there's much we can do on the Postgres 00:15:31.167 --> 00:15:35.337 side for, for specific bad examples other than let time play out. 00:15:35.397 --> 00:15:40.617 Um, but yeah, so the, the worst thing for me was sometimes I'd forget that 00:15:40.622 --> 00:15:43.767 it was an old version, read it and then not realize about a feature. 00:15:43.947 --> 00:15:46.737 Anyway, uh, sorry, probably should get back to hosting! 00:15:47.197 --> 00:15:49.777 Nikolay: We, we we've got off topic upgrades off topic, 00:15:50.007 --> 00:15:50.067 Michael: Yeah. 00:15:50.527 --> 00:15:54.437 Nikolay: Off topic conference and off topic search results in Google. 00:15:54.737 --> 00:15:54.857 Yeah. 00:15:55.007 --> 00:15:55.367 Okay. 00:15:55.637 --> 00:15:56.537 A lot of off topics. 00:15:57.407 --> 00:15:57.677 Michael: Yeah. 00:15:57.677 --> 00:16:04.197 So let's assume we don't need an extension that we can't get on a provider, we 00:16:04.202 --> 00:16:09.297 don't have a really experienced DBA team, and we're not expecting to have more 00:16:09.297 --> 00:16:11.367 than a terabyte of data anytime soon. 00:16:11.967 --> 00:16:16.327 What are you thinking in terms of, which, which managed services would you tend 00:16:16.332 --> 00:16:18.787 to lean towards, in what circumstances? 00:16:19.552 --> 00:16:23.477 Nikolay: Well, it depends on which cloud you use, maybe you're not on. 00:16:24.602 --> 00:16:29.402 In cloud on cloud sometimes like very, very rarely, but sometimes people 00:16:29.402 --> 00:16:32.917 don't use clouds, but if you are on cloud, you probably should just 00:16:32.917 --> 00:16:34.927 choose the offering they provide. 00:16:35.407 --> 00:16:36.727 But sometimes it's awful. 00:16:37.117 --> 00:16:41.397 Like a few years ago, I would not recommend Google Cloud SQL to anyone. 00:16:41.397 --> 00:16:47.127 They had only eight, uh, knobs to tune from from almost 300 setting 00:16:47.277 --> 00:16:52.047 parameters and was not flexible, not ready to, to, you cannot tune to you. 00:16:52.047 --> 00:16:55.827 Like it's not good, but I, I don't remember some other, 00:16:55.927 --> 00:16:59.402 problems , there offering had, but right now it's improving a lot. 00:16:59.812 --> 00:16:59.962 So 00:16:59.962 --> 00:17:00.852 Michael: Very quickly, right. 00:17:01.192 --> 00:17:04.732 Nikolay: Since, since we mentioned, yeah, since we mentioned, uh, Postgres TV, we 00:17:04.732 --> 00:17:13.067 had, Ilya Kosmodemiansky and I had great guest, Hannu Krosing who was, in the past 00:17:13.067 --> 00:17:19.702 was, Skype database architect developed a lot of things in Skype, and, he talked 00:17:19.732 --> 00:17:23.522 about, vacuum issues and was great talk. 00:17:23.522 --> 00:17:24.032 So if. 00:17:24.647 --> 00:17:29.297 If interested in vacuum issues in Postgres, uh, go check this 00:17:30.197 --> 00:17:31.797 presentation on postgres.tv. 00:17:32.427 --> 00:17:34.857 And, uh, he, he works at Google right now. 00:17:34.917 --> 00:17:39.987 So cloud SQL has very, very strong experts and it's improving. 00:17:39.987 --> 00:17:42.697 And they also recently released AlloyDB. 00:17:42.782 --> 00:17:42.867 Right. 00:17:42.867 --> 00:17:50.207 So it's like, it's very, also interesting, like among all, Postgres 00:17:50.502 --> 00:17:53.052 uh, offering, you can choose in cloud. 00:17:53.262 --> 00:17:57.882 They are like almost pure Postgres, like RDS Postgres, almost pure. 00:17:58.782 --> 00:18:03.012 Nobody except Amazon engineers can say, there are no patches. 00:18:03.017 --> 00:18:04.392 Of course there are some patches there. 00:18:04.662 --> 00:18:10.722 So, but there are also very different databases, like, uh, Aurora, which 00:18:11.082 --> 00:18:16.122 has different storage or recent NeonDB, which like open source of 00:18:16.122 --> 00:18:18.512 Aurora also with different storage. 00:18:19.257 --> 00:18:21.517 Uh, so we cannot say it's already Postgres. 00:18:21.537 --> 00:18:22.747 Like, it looks like Postgres. 00:18:22.767 --> 00:18:28.017 It feels like Postgres, but not always, but they're also much more different. 00:18:28.047 --> 00:18:30.027 Like AlloyDB, it's quite different. 00:18:30.032 --> 00:18:34.557 They have interesting idea to have, uh, column store, right. 00:18:34.562 --> 00:18:35.187 And memory. 00:18:35.757 --> 00:18:40.497 In addition to row stores or row store converted to column store to have 00:18:40.497 --> 00:18:45.577 very fast aggregates for analytical workloads, or we have also Yugabyte. 00:18:45.897 --> 00:18:49.477 Which is not Postgres at all, but kind of looks, looks like Postgres. 00:18:49.947 --> 00:18:53.787 So among all these options, it's hard to choose. 00:18:54.117 --> 00:18:54.387 Right? 00:18:54.942 --> 00:18:55.332 Michael: Right. 00:18:55.662 --> 00:18:57.972 I guess it depends so much on the use case. 00:18:58.032 --> 00:18:59.812 And I, I think you're right. 00:18:59.842 --> 00:19:04.822 I think if you don't need anything special and you're fully committed 00:19:04.822 --> 00:19:09.442 to a single cloud provider already, it makes sense by default to go 00:19:09.442 --> 00:19:12.412 with theirs, unless, you know, you read the fine print and there's a, a 00:19:12.412 --> 00:19:14.182 really good reason not to, or go on. 00:19:14.752 --> 00:19:20.332 Nikolay: If you, for example, on Google or Asia or I don't like, and 00:19:20.332 --> 00:19:26.002 you committed to be on this cloud, you still may think to use not their own 00:19:26.002 --> 00:19:30.902 Postgres managed service, but also, uh, offering from companies like Aiven 00:19:30.957 --> 00:19:33.082 or ScaleGrid because they work on all. 00:19:33.262 --> 00:19:34.172 So you will have. 00:19:34.702 --> 00:19:39.447 API and the UI are ready to work on any cloud, if you just, if you move 00:19:39.447 --> 00:19:42.172 or expand to other cloud providers. 00:19:42.172 --> 00:19:45.142 So it's also interesting, but you know what we should choose, 00:19:45.892 --> 00:19:47.242 we should choose Kubernetes. 00:19:47.692 --> 00:19:52.192 The only question is, I mean, Kubernetes, um, operators or 00:19:52.957 --> 00:19:54.977 products like, like StackGres. 00:19:55.657 --> 00:19:56.077 Why? 00:19:56.557 --> 00:20:00.367 Like, because this is the same, like managed, but more power you have access 00:20:00.367 --> 00:20:01.837 and everything, if you need to diagnose. 00:20:01.837 --> 00:20:05.257 And so on, the only question is when? 00:20:05.947 --> 00:20:07.717 Maybe not today, maybe tomorrow. 00:20:07.717 --> 00:20:08.047 Right? 00:20:08.047 --> 00:20:12.532 Because still they are, they are started a few years ago and they're still very 00:20:12.532 --> 00:20:21.562 young, but I'm sure in five years, a lot of users will prefer Kubernetes under 00:20:21.562 --> 00:20:27.062 their full control, compared to, fully managed by cloud provider, uh, services. 00:20:27.692 --> 00:20:30.902 Michael: Well, I think for people that are using Kubernetes themselves, 00:20:30.902 --> 00:20:35.832 which is a growing number, for their application side, I think those people, 00:20:35.837 --> 00:20:38.892 once they've built up that muscle and they, they understand it and they 00:20:38.892 --> 00:20:42.477 understand the, the sharp edges, um, Then. 00:20:42.477 --> 00:20:44.607 Yeah, I think it, I think it does make a lot of sense. 00:20:44.617 --> 00:20:46.087 I think there was a lot of fear. 00:20:46.207 --> 00:20:48.307 What's it FUD: fear uncertainty. 00:20:48.607 --> 00:20:48.907 I dunno. 00:20:48.907 --> 00:20:49.627 Is it denial? 00:20:49.777 --> 00:20:55.687 Uh, but I didn't see any good arguments against it and it does seem to really 00:20:55.692 --> 00:20:57.847 help in a few very specific ways. 00:20:58.942 --> 00:21:02.542 But equally, I don't see most small companies needing it. 00:21:02.572 --> 00:21:05.695 Like, I think there's like a scale where it becomes really useful when 00:21:05.695 --> 00:21:10.225 you need to provide a certain service level, um, maybe you have a really, 00:21:10.225 --> 00:21:14.815 really low tolerance for downtime or absolute zero data loss requirement. 00:21:14.820 --> 00:21:16.585 And that's really a, you know, that kind of. 00:21:17.140 --> 00:21:21.280 Uh, really high level thing that everyone thinks they need or want, but 00:21:21.460 --> 00:21:26.580 not everyone actually is willing to pay for maybe is the main criteria. 00:21:26.830 --> 00:21:30.840 But yeah, I don't see any reason why not, but I do think it won't be self-managed. 00:21:30.845 --> 00:21:33.810 I think a lot of people will then pay for somebody else to manage that 00:21:33.810 --> 00:21:39.570 for them, uh, still to not need that Kubernetes, uh, expertise in house, at 00:21:39.570 --> 00:21:41.190 least in the early days of a startup. 00:21:41.750 --> 00:21:45.205 Nikolay: Maybe, but with, this approach, Kubernetes based, maybe 00:21:45.205 --> 00:21:50.325 you can hire a vendor of this Kubernetes, uh, product, uh, Postgres. 00:21:50.685 --> 00:21:53.415 But, uh, with this approach, you can install anything. 00:21:54.805 --> 00:22:00.715 You have like Postgres is very well known for its extensibility, but fully 00:22:00.715 --> 00:22:03.235 managed offering, always limits this. 00:22:04.075 --> 00:22:07.795 For example, Timescale extension is available only on Timescale cloud. 00:22:08.755 --> 00:22:11.365 Michael: But that's, that's due to licensing, right? 00:22:11.395 --> 00:22:15.295 Nikolay: Among, among managed Postgres, it's not available on RDS and, and will 00:22:15.295 --> 00:22:20.455 never be available there because Timescale thinks it's, uh, a reason to, for users to 00:22:20.455 --> 00:22:23.195 go to their cloud offering instead of RDS. 00:22:23.740 --> 00:22:28.540 By the way, what do you think, uh, how successful will be this, uh, approach? 00:22:29.110 --> 00:22:31.990 Like we have some very good extension, very popular. 00:22:32.470 --> 00:22:36.270 We, we will have it on only on our managed service? 00:22:37.070 --> 00:22:41.470 Michael: So I saw, I think, the founder of OrioleDB gave a really good talk 00:22:41.650 --> 00:22:46.915 recently where he described some of some extensions are kind of normal extensions. 00:22:46.915 --> 00:22:48.385 They add a little bit of function. 00:22:48.415 --> 00:22:48.685 Yeah. 00:22:48.685 --> 00:22:51.475 So they add a little bit of functionality to Postgres that makes it 00:22:51.475 --> 00:22:52.825 a little bit better in a certain way. 00:22:53.035 --> 00:22:55.735 And he then also added a category of, yeah, I think he 00:22:55.735 --> 00:22:57.205 did call them super extensions. 00:22:57.205 --> 00:23:03.775 So Citus, Timescale, I think he included Oriole, um, basically extensions that 00:23:03.775 --> 00:23:08.155 are doing so much, they're changing things really fundamentally at certain 00:23:08.155 --> 00:23:12.460 levels and actually they change it so much they can almost be considered. 00:23:12.460 --> 00:23:15.280 They're not a fork because they are an extension, but they have 00:23:15.280 --> 00:23:17.080 some characteristics of a fork. 00:23:17.080 --> 00:23:19.020 Where do they play nicely together? 00:23:19.570 --> 00:23:22.890 Um, how, yeah how easily can you migrate between them? 00:23:23.308 --> 00:23:26.758 Nikolay: It's like not fork, but different database right already. 00:23:27.253 --> 00:23:28.363 Michael: Almost, yeah, exactly. 00:23:28.363 --> 00:23:29.473 Almost a different database. 00:23:29.533 --> 00:23:34.723 Um, so yeah, I, I think I can see why it would work for Timescale because 00:23:34.723 --> 00:23:38.233 if you really want their expertise, they are the best at supporting it. 00:23:38.263 --> 00:23:42.103 And, uh, going to their cloud makes a lot of sense, but that's a really 00:23:42.103 --> 00:23:44.473 good reason for picking DIY as well. 00:23:44.473 --> 00:23:47.893 If you really want the Timescale functionality and some of it, it seems 00:23:47.893 --> 00:23:52.243 incredibly good even for non-time series workloads, like think, did you see they 00:23:52.243 --> 00:23:54.193 did their skip scan implementation? 00:23:54.778 --> 00:23:56.818 That's super useful in loads of workloads. 00:23:56.818 --> 00:23:59.038 So there's, there's reasons to want that. 00:23:59.043 --> 00:24:02.788 And if you want it, but you aren't ready to go to Timescale as your managed service 00:24:02.793 --> 00:24:05.648 provider for some reason, you have to DIY. 00:24:05.938 --> 00:24:07.433 So yeah, I do think you're right. 00:24:07.533 --> 00:24:14.658 But I'm seeing actually a little bit more of a, an excitement around these services 00:24:14.658 --> 00:24:16.668 that abstract even more away from you. 00:24:16.758 --> 00:24:19.818 And they come, they come with, I think, uh, limitations at the moment. 00:24:19.823 --> 00:24:25.818 And they're very, very new, but services like Supabase or Neon looks exciting. 00:24:25.818 --> 00:24:29.748 But, I know it's not Postgres, but on the MySQL side, PlantScale. 00:24:30.438 --> 00:24:34.718 These services, I can see the excitement in the early startup CTO level. 00:24:35.303 --> 00:24:40.103 They're promising them that you start with this today and we'll scale with you. 00:24:40.413 --> 00:24:45.123 We can scale up, we can scale out and you don't have to handle any of that yourself. 00:24:45.123 --> 00:24:48.333 You just keep talking to us like, we're your database. 00:24:48.920 --> 00:24:52.600 There might be some hidden dark secrets that are, that are yet to come out of 00:24:52.600 --> 00:24:54.550 the, you know, the reality of that. 00:24:55.045 --> 00:24:58.555 But it seems super compelling to me as a, as a simple option of, I 00:24:58.555 --> 00:25:00.265 don't need super complex things. 00:25:01.008 --> 00:25:04.548 Nikolay: What do you think about security issues with the services? 00:25:04.553 --> 00:25:08.278 Because for example, if, if you are customer of Amazon 00:25:08.378 --> 00:25:09.743 you have trust with them. 00:25:09.743 --> 00:25:14.123 Like they don't access your data in RDS, although they, they could, right. 00:25:14.773 --> 00:25:20.703 Like it's, there is some trust, but if it's a smaller player, and they 00:25:20.710 --> 00:25:25.633 run your databases with your data inside their AWS account, for example, 00:25:26.293 --> 00:25:28.933 like how to achieve good trust here. 00:25:29.410 --> 00:25:31.300 Michael: Well, I think security is a really good point. 00:25:31.330 --> 00:25:32.830 I think reliability as well. 00:25:32.860 --> 00:25:35.560 You know, AWS, there's two angles. 00:25:35.590 --> 00:25:39.350 One, they've got a track record of good uptime, good reliability. 00:25:39.460 --> 00:25:43.570 And two, if you go down or if they go down and therefore your service goes 00:25:43.570 --> 00:25:45.700 down, half the Internet's down as well. 00:25:45.910 --> 00:25:50.260 So customers aren't that surprised that your service isn't running because 00:25:50.650 --> 00:25:54.315 nothing's, you know, their Spotify isn't working or their Netflix isn't working. 00:25:54.315 --> 00:25:57.155 So I think there's a few things you get with these big players that 00:25:57.155 --> 00:25:58.895 people underestimate a little bit. 00:25:59.555 --> 00:26:02.225 And with these new ones, they sometimes they're built on some 00:26:02.225 --> 00:26:06.725 really complex, um, infrastructure to handle some of this stuff. 00:26:07.620 --> 00:26:11.160 that does, that does fail and sometimes in very spectacular ways 00:26:11.340 --> 00:26:15.330 and could, can result in a lot more downtime than the normal few minutes. 00:26:15.330 --> 00:26:18.480 So I think complexity does come cost, uh, or, sorry. 00:26:18.840 --> 00:26:21.180 They're, they're taking away the complexity from you, but 00:26:21.185 --> 00:26:22.530 they're adding it on their side. 00:26:22.870 --> 00:26:24.055 And I, don't know. 00:26:24.145 --> 00:26:28.625 I don't know that I would trust her something that needed that myself. 00:26:28.768 --> 00:26:33.418 Nikolay: For me as a database performance expert, they add complexity because 00:26:33.718 --> 00:26:38.578 in, if I manage Postgres myself, I can install very useful extensions 00:26:38.608 --> 00:26:42.358 in addition, to pg_stat_statements, let's talk about performance, Uh, 00:26:42.358 --> 00:26:47.758 pg_stat_kcache and pg_wait_sampling, these extensions add two important 00:26:47.758 --> 00:26:49.888 dimensions to pg_stat_statements. 00:26:49.913 --> 00:26:54.953 One is physical, so you can see disk I/O, pg_stat_kcache, disk I/O and CPU, even 00:26:55.163 --> 00:26:59.843 system CPU, user CPU context switches and so on, and another pg_wait_sampling, 00:27:00.363 --> 00:27:04.743 it provides similar analysis like performance insights in AWS RDS. 00:27:05.313 --> 00:27:08.493 Without these two extensions, it's very hard to understand, for 00:27:08.498 --> 00:27:14.103 example, which query consumes a lot of CPU, but not very data intensive. 00:27:14.103 --> 00:27:16.563 Sometimes it happens or similar things. 00:27:17.013 --> 00:27:20.258 Pg_stat_statements sometimes cannot answer some questions. 00:27:20.258 --> 00:27:20.528 Right. 00:27:21.008 --> 00:27:26.138 And, uh, if you don't have performance insights, like, uh, like RDS has, 00:27:26.218 --> 00:27:27.633 sometimes you are very blind. 00:27:28.713 --> 00:27:34.623 So, so they add complexity in terms of query analysis and 00:27:34.833 --> 00:27:36.243 performance optimization to me. 00:27:36.963 --> 00:27:41.053 Because with these two extensions and proper monitoring, it makes very simple to 00:27:41.053 --> 00:27:48.253 perform top down analysis of workload and find, the worst queries . So agree or no? 00:27:48.875 --> 00:27:49.265 Michael: Yeah. 00:27:49.325 --> 00:27:51.995 Well, I think we're talking about different ends of the spectrum. 00:27:51.995 --> 00:27:54.035 I like, I think maybe you're right. 00:27:54.035 --> 00:27:57.245 That, that's the kind of thing that the CTO at a startup picking. 00:27:58.085 --> 00:28:03.005 Um, let's say, uh, let's pick on PlanetScale, cause it's not even Postgres. 00:28:03.335 --> 00:28:05.015 Let's say they pick PlanetScale today. 00:28:06.215 --> 00:28:09.695 That maybe they're not aware of that kind of limitation all the way down 00:28:09.695 --> 00:28:13.325 the line or that they're completely reliant on PlanetScale's tooling. 00:28:13.375 --> 00:28:17.425 Nikolay: I think PlanetScale is not good example because people choose 00:28:17.425 --> 00:28:22.205 PlanetScale of my, MySQL users, because they are also developers of Vitess. 00:28:22.230 --> 00:28:26.920 And, if you need to build very big system that that requires sharding, 00:28:26.975 --> 00:28:29.520 it's actually almost standard defacto. 00:28:29.640 --> 00:28:32.550 So you probably will go there because of that. 00:28:32.760 --> 00:28:35.690 Or, or use Vitess and that's it. 00:28:35.740 --> 00:28:36.430 It's interesting. 00:28:36.700 --> 00:28:40.630 It's very specific example and I I'm interested in that example, 00:28:40.630 --> 00:28:44.980 but it, it will move us away from our main topic right now. 00:28:45.603 --> 00:28:49.683 Michael: Well, what, um, how about, uh, Supabase then in terms of their promising 00:28:49.900 --> 00:28:52.160 Nikolay: for smaller projects also very specific. 00:28:52.450 --> 00:28:55.300 They, they like, they do very great thing. 00:28:55.450 --> 00:28:57.930 Um, but for smaller projects, mostly like, 00:28:57.930 --> 00:28:58.810 Michael: At the moment 00:28:59.650 --> 00:29:00.145 Nikolay: At the moment. 00:29:00.150 --> 00:29:00.415 Right. 00:29:00.655 --> 00:29:03.445 But, the, their main offering is. 00:29:04.120 --> 00:29:10.750 Like we provide you out of a box API authentication, uh, capabilities and 00:29:10.750 --> 00:29:18.700 this, uh, real time like, Firebase, like, uh, right think, but, but, uh, 00:29:19.110 --> 00:29:21.540 The question is like, what do you offer? 00:29:21.630 --> 00:29:26.640 If my database is 30 terabytes and I have 30,000 TPS, I need 00:29:26.640 --> 00:29:28.850 specific performance analysis tools. 00:29:29.210 --> 00:29:34.980 I need, to be sure that you will survive for example, five terabytes of WAL 00:29:35.000 --> 00:29:38.570 per day, backed up properly and so on. 00:29:38.900 --> 00:29:40.280 And this question is interesting. 00:29:40.280 --> 00:29:43.280 I'm not sure Supabase is ready for this scale yet. 00:29:43.658 --> 00:29:46.718 Michael: No, but who it, like, I'm thinking, looking through the ones 00:29:46.718 --> 00:29:50.618 I've got, I think EDB, for example, came out with a managed service 00:29:50.618 --> 00:29:55.228 recently and Crunchy, of course, both of those are Postgres consultancies 00:29:55.598 --> 00:29:57.608 turned into managed service providers. 00:29:58.658 --> 00:30:00.908 Are they the, would you, would you think about those? 00:30:00.908 --> 00:30:03.228 Do you think they might have some answers to this kind of thing? 00:30:04.545 --> 00:30:07.905 Nikolay: I I'm very negative today for EDB. 00:30:07.905 --> 00:30:12.495 I wish they, they provide better consulting still because I have couple 00:30:12.500 --> 00:30:17.385 of clients over last few years, not couple, several clients who, uh, 00:30:17.865 --> 00:30:22.215 suffered from their consulting, but it's good for me because, uh, they went to 00:30:22.215 --> 00:30:25.485 our small shop and we fixed problems. 00:30:25.785 --> 00:30:30.150 So I'm, I haven't checked their managed service. 00:30:30.690 --> 00:30:31.230 I don't know. 00:30:31.680 --> 00:30:33.450 No, no, no, no comments here. 00:30:33.510 --> 00:30:34.260 Maybe it's good. 00:30:34.800 --> 00:30:38.190 But again, like, it's, it's a very difficult choice, right? 00:30:38.190 --> 00:30:41.760 So like many, many, but RDS is growing. 00:30:41.760 --> 00:30:43.620 Like Google is interesting. 00:30:43.890 --> 00:30:48.055 Microsoft has a power of Citus, so it's a very interesting time we live 00:30:48.055 --> 00:30:52.375 in, but again, in in few years, most people will choose Kubernetes based. 00:30:52.375 --> 00:30:52.825 I think. 00:30:53.338 --> 00:30:54.328 Michael: You heard it here first. 00:30:55.258 --> 00:30:57.538 Um, I said you heard it here first. 00:30:57.538 --> 00:30:58.438 Probably not first. 00:30:58.558 --> 00:30:59.968 People have been talking about this for a while. 00:31:00.658 --> 00:31:01.078 Awesome. 00:31:01.288 --> 00:31:04.768 I know we could probably talk about this topic for quite a long time. 00:31:04.928 --> 00:31:07.318 Is there any last things you wanted to add before we wrap up? 00:31:08.778 --> 00:31:16.050 Nikolay: Uh, well, um, I think physical connection is a big limiting factor. 00:31:16.470 --> 00:31:20.090 And every company who wants to deal with managed Postgres should 00:31:20.090 --> 00:31:21.780 think about this, do they need it? 00:31:21.840 --> 00:31:25.200 And also low level on diagnostics capabilities. 00:31:25.680 --> 00:31:29.720 So if they're okay without it, it's a go for, for this managed service. 00:31:30.450 --> 00:31:35.995 I have many clients who work on RDS and other, managed services and I 00:31:35.995 --> 00:31:39.715 like helping them as well, because sometimes it's fun to deal with. 00:31:41.475 --> 00:31:43.400 Their support engineers. 00:31:43.550 --> 00:31:49.280 It's sometimes it's lengthy discussions, but it's specific kind of fun actually, I 00:31:49.280 --> 00:31:56.920 would say, but in general, I think we have like, EDB are called Big Animal, right? 00:31:57.580 --> 00:32:01.250 We have huge zoo of, animals of various kinds. 00:32:01.270 --> 00:32:01.570 Right. 00:32:02.110 --> 00:32:04.985 And, I definitely like, the specific, uh, breed. 00:32:05.945 --> 00:32:08.135 That is shaded with Kubernetes. 00:32:08.435 --> 00:32:14.075 So let's probably talk about this area some sometime soon as well. 00:32:14.665 --> 00:32:15.245 Michael: Sounds good. 00:32:16.183 --> 00:32:16.693 Wonderful. 00:32:16.933 --> 00:32:19.063 Well, thank you everyone for joining us. 00:32:19.113 --> 00:32:21.898 I'm gonna put a bunch of these links in our show notes. 00:32:22.018 --> 00:32:24.868 We welcome ideas, suggestions for future topics. 00:32:24.938 --> 00:32:25.238 And yeah. 00:32:25.358 --> 00:32:26.198 Thank you so much, Nikolay. 00:32:26.198 --> 00:32:27.338 I hope you have a good week. 00:32:28.030 --> 00:32:28.390 Nikolay: Thank you. 00:32:28.450 --> 00:32:32.080 I also want to thank everyone who provided feedback to Michael. 00:32:32.080 --> 00:32:34.810 Uh, and I wanted to say you can provide feedback to me as well. 00:32:34.990 --> 00:32:39.460 So like, but for Michael is also good and don't forget to subscribe 00:32:39.465 --> 00:32:44.050 and also share, please share this channel, this postgres.fm link 00:32:44.680 --> 00:32:46.330 and, and links to specific episodes. 00:32:46.430 --> 00:32:47.690 This will help us to grow. 00:32:49.160 --> 00:32:49.700 Thank you, Michael. 00:32:50.353 --> 00:32:50.653 Michael: Take care. 00:32:50.863 --> 00:32:51.253 Speak soon. 00:32:51.393 --> 00:32:51.613 Bye. 00:32:51.997 --> 00:32:52.267 Nikolay: Bye.