1 0:0:0,17999999 --> 0:0:3,62 Michael: Ho ho ho hello and welcome to Postgres.FM. 2 0:0:3,62 --> 0:0:6,8799996 My name is Michael I'm a founder of pgMustard and I'm joined as 3 0:0:6,8799996 --> 0:0:11,48 always by Nik from PostgresAI Merry Christmas Nik and happy 4 0:0:11,48 --> 0:0:12,16 new year. 5 0:0:12,7 --> 0:0:18,699999 Nikolay: Yeah, you too and to all our audience which yeah roughly 6 0:0:18,74 --> 0:0:22,46 as we just counted across all the platforms, roughly 10,000 7 0:0:22,54 --> 0:0:22,96 people. 8 0:0:22,96 --> 0:0:23,9 So it's impressive. 9 0:0:24,52 --> 0:0:27,54 Michael: Yeah, it's kind of wild, but yes, thank you everyone 10 0:0:27,68 --> 0:0:28,84 for another good year. 11 0:0:29,14 --> 0:0:29,64 Nikolay: Yeah. 12 0:0:30,48 --> 0:0:36,68 So obviously we wanted to do some overview of this year 2023 13 0:0:37,12 --> 0:0:37,86 for Postgres. 14 0:0:38,3 --> 0:0:43,22 I think it's a great year for Postgres because a lot of stuff, 15 0:0:43,48 --> 0:0:46,2 a lot happened and a lot is still happening. 16 0:0:47,06 --> 0:0:53,16 And vector of development of product and communities around it 17 0:0:53,16 --> 0:0:57,88 and companies and everything ecosystem it's it's astonishing 18 0:0:58,02 --> 0:0:58,52 right 19 0:0:59,059998 --> 0:1:1,82 Michael: yeah absolutely Feels like it's going from strength 20 0:1:1,82 --> 0:1:4,98 to strength and yeah, as you say another good year 21 0:1:5,8 --> 0:1:8,86 Nikolay: Yeah, so where to start let's maybe start with some 22 0:1:8,86 --> 0:1:10,46 technical topics first. 23 0:1:10,94 --> 0:1:15,36 Maybe Postgres 16 Obviously 1 of them and we had a whole episode 24 0:1:15,36 --> 0:1:17,78 about that and what do you remember? 25 0:1:18,24 --> 0:1:22,58 What are achievements of Postgres 16 which shine? 26 0:1:24,44 --> 0:1:28,68 Michael: Yeah good question I guess 1 thing we didn't have when 27 0:1:28,68 --> 0:1:31,88 Postgres 16 came out and we did the episode was a little bit 28 0:1:31,88 --> 0:1:32,58 of hindsight. 29 0:1:32,64 --> 0:1:34,44 We didn't know how it was going to go. 30 0:1:34,44 --> 0:1:37,84 With a major version, you're always a tiny bit worried there's 31 0:1:37,84 --> 0:1:40,12 going to be a big issue in it. 32 0:1:40,12 --> 0:1:42,32 And once you get through the release candidates and the beta 33 0:1:42,32 --> 0:1:44,96 without that, that either means there isn't a big issue or it 34 0:1:44,96 --> 0:1:47,06 hasn't been found in testing yet. 35 0:1:47,06 --> 0:1:50,98 So now with a bit of benefit of hindsight I think it's gone pretty 36 0:1:50,98 --> 0:1:51,7 well hasn't it? 37 0:1:51,7 --> 0:1:56,26 Like I mean touch wood it feels like not only has it gone down 38 0:1:56,26 --> 0:1:59,84 well but people have been reporting some performance improvements, 39 0:2:0,66 --> 0:2:2,06 people have actually been upgrading. 40 0:2:2,16 --> 0:2:6,54 I'm actually seeing people, in our case, submitting version 16 41 0:2:6,54 --> 0:2:7,84 query plans to the product. 42 0:2:7,84 --> 0:2:11,26 So they're using it on production and already looking into performance 43 0:2:11,28 --> 0:2:11,92 things with it. 44 0:2:11,92 --> 0:2:16,56 So they've not only upgraded, but have had it in production for 45 0:2:16,56 --> 0:2:17,24 a little bit. 46 0:2:17,24 --> 0:2:21,34 So yeah, it seems like people are upgrading which isn't always 47 0:2:21,34 --> 0:2:25,58 the case when a new major version first comes out and Seeing 48 0:2:25,58 --> 0:2:26,9 some wins, which is cool. 49 0:2:27,14 --> 0:2:31,04 Nikolay: Yeah, I also feel the pace of upgrades is improving 50 0:2:31,18 --> 0:2:35,38 from year to year I think managed Postgres providers say polish 51 0:2:35,38 --> 0:2:40,2 the procedure and make new Postgres available sooner than in 52 0:2:40,2 --> 0:2:40,9 previous years. 53 0:2:40,9 --> 0:2:43,7 So it's obviously being noticed, right? 54 0:2:43,93 --> 0:2:49,7 So, but in terms of Postgres 18, I remember things like in any 55 0:2:49,7 --> 0:2:54,34 overview somehow UUID version 7, native support of it made it 56 0:2:54,34 --> 0:2:58,8 to the short list of always mentioned things. 57 0:2:58,94 --> 0:3:6,14 And it's great because again, it started during Postgres TV hacking 58 0:3:6,14 --> 0:3:7,12 sessions online. 59 0:3:7,84 --> 0:3:9,28 I'm super proud of this. 60 0:3:9,28 --> 0:3:12,72 Like, you know, like finally it made it after a couple of years 61 0:3:12,72 --> 0:3:17,38 of waiting because of, like, waiting for RFC standard to be finalized. 62 0:3:17,64 --> 0:3:20,24 Postgres was very conservative compared to others. 63 0:3:20,46 --> 0:3:23,14 It's great that this thing made it. 64 0:3:23,3 --> 0:3:26,84 It's not a huge thing, but it's obviously very useful, helpful 65 0:3:26,84 --> 0:3:27,54 for people. 66 0:3:28,12 --> 0:3:30,3 Michael: Not a reason to upgrade though, right? 67 0:3:30,72 --> 0:3:31,16 Nikolay: No, no. 68 0:3:31,16 --> 0:3:34,46 Among reasons, I wanted to mention a specific one. 69 0:3:35,0 --> 0:3:40,32 I know we have customers who are working on upgrades sooner and 70 0:3:40,32 --> 0:3:43,74 already made a decision to upgrade much sooner than usually to 71 0:3:43,74 --> 0:3:48,5 Postgres 18 just because LockManager, lightweight lock contention 72 0:3:48,94 --> 0:3:50,04 is fully solved. 73 0:3:50,28 --> 0:3:53,52 And I have a series of articles exploring this in detail, showing 74 0:3:53,52 --> 0:3:57,26 benchmarks that you just raise, if you upgrade, you just raise 75 0:3:57,26 --> 0:4:0,58 max_locks_per_transaction parameter, which requires a restart, 76 0:4:0,58 --> 0:4:5,1 unfortunately, but it's easier than suffering, you know? 77 0:4:5,38 --> 0:4:8,8 Suffering from lightweight LockManager contention. 78 0:4:9,16 --> 0:4:10,76 And that's it, it's solved. 79 0:4:10,76 --> 0:4:15,8 So this work also took a few years to make it into final release 80 0:4:15,8 --> 0:4:18,9 and finally we have it and this is definitely one of the reasons 81 0:4:18,9 --> 0:4:19,86 to upgrade. 82 0:4:20,14 --> 0:4:23,58 Now if there are other reasons, I also noticed as we discussed 83 0:4:24,14 --> 0:4:24,64 AIO. 84 0:4:26,6 --> 0:4:27,16 That's a 85 0:4:27,16 --> 0:4:28,44 Michael: huge one for people. 86 0:4:28,86 --> 0:4:33,48 I actually haven't seen many, I think a few people have blogged 87 0:4:33,48 --> 0:4:36,22 kind of theoretically about the performance improvements that 88 0:4:36,22 --> 0:4:39,34 could be possible there, but I haven't seen anybody publish anything 89 0:4:39,34 --> 0:4:43,18 that they upgraded and saw a big improvement due to AIO, but 90 0:4:43,18 --> 0:4:47,4 I would say it has driven a lot of interest in the major version 91 0:4:47,4 --> 0:4:51,26 and it could it could be that it is proving really good for performance 92 0:4:51,76 --> 0:4:55,68 but but more than that it's like a good marketing feature like 93 0:4:55,68 --> 0:4:58,82 it has driven a lot of interest in the upgrade and people actually 94 0:4:58,82 --> 0:4:59,88 considering it. 95 0:5:0,14 --> 0:5:3,02 Nikolay: Yeah I saw it not in upgrade, but I saw it in... 96 0:5:3,54 --> 0:5:6,26 Well, it's actually my blog post... 97 0:5:6,4 --> 0:5:8,98 Maxim's and mine blog post about pgBackRest. 98 0:5:9,48 --> 0:5:12,6 And I suddenly noticed that before single-threaded pg_basebackup 99 0:5:13,26 --> 0:5:17,98 only could do 300-400 megabytes per second, but in Postgres 18 100 0:5:17,98 --> 0:5:21,34 it's gigabyte per second on fast disks so it was big surprise 101 0:5:21,34 --> 0:5:25,52 to me and it's also like 1 of the reasons I think should should 102 0:5:25,52 --> 0:5:29,18 be considered to upgrade sooner Oh, yeah, we can dive into technical 103 0:5:29,18 --> 0:5:33,3 details for another episode, but yeah, let's move on. 104 0:5:33,3 --> 0:5:34,12 What's next? 105 0:5:34,98 --> 0:5:40,4 What's what is big in 2025 on your opinion in terms of technical 106 0:5:40,4 --> 0:5:40,9 stuff 107 0:5:42,06 --> 0:5:45,26 Michael: on just the technical side that's an interesting question 108 0:5:45,66 --> 0:5:49,18 I've got a lot actually in and around the community, but on the 109 0:5:49,18 --> 0:5:55,26 technical side, I think 1 of the bigger things we saw was more 110 0:5:55,28 --> 0:5:58,38 efforts, actually maybe that's community still, do you consider 111 0:5:58,38 --> 0:6:2,8 kind of the efforts to empower and grow more hackers, like more 112 0:6:2,8 --> 0:6:5,92 actual Postgres developers, people working on the Postgres core 113 0:6:5,92 --> 0:6:8,8 base, do you consider that technical or more community? 114 0:6:8,86 --> 0:6:10,1 Nikolay: Well, it's less technical. 115 0:6:10,28 --> 0:6:15,76 Technical, if you mentioned the word hackers, let's use this 116 0:6:15,76 --> 0:6:17,94 word in a different meaning. 117 0:6:19,96 --> 0:6:22,5 Remember US treasury hack? 118 0:6:23,44 --> 0:6:24,14 Michael: Oh yeah. 119 0:6:25,26 --> 0:6:26,36 Nikolay: This is quite technical. 120 0:6:27,54 --> 0:6:31,22 There was a case when it was not so good, right? 121 0:6:31,78 --> 0:6:35,5 And Postgres obviously used everywhere, so vulnerabilities happen 122 0:6:35,5 --> 0:6:39,88 from time to time and it's obviously technical wise, Postgres 123 0:6:39,88 --> 0:6:45,54 has great process to fix, to issue new minor, set of minor releases 124 0:6:45,54 --> 0:6:50,82 which close vulnerability, but still due to very wide use of 125 0:6:50,82 --> 0:6:51,32 Postgres. 126 0:6:51,78 --> 0:6:57,1 I think this year Postgres made it to more technical media because 127 0:6:57,1 --> 0:6:57,72 of that. 128 0:6:57,72 --> 0:7:1,86 And it was mentioned in the context of, okay, There was like 129 0:7:1,86 --> 0:7:6,44 hackers from China hacked the US infrastructure and Postgres 130 0:7:6,44 --> 0:7:7,16 was involved. 131 0:7:7,58 --> 0:7:11,18 So this I think it's also kind of trend and it's slightly less 132 0:7:11,18 --> 0:7:14,94 technical but there is some technical aspect in it and obviously 133 0:7:15,24 --> 0:7:19,9 it means that you need to upgrade in terms of minor upgrades 134 0:7:19,9 --> 0:7:24,64 always, like patches should be applied promptly Because things 135 0:7:24,64 --> 0:7:27,78 happen, bad things happen, and it's better to keep Postgres up 136 0:7:27,78 --> 0:7:32,32 to date in terms of minor version Right, So this is what I just 137 0:7:32,32 --> 0:7:34,08 remember this this thing. 138 0:7:34,3 --> 0:7:34,64 Michael: Nice. 139 0:7:34,64 --> 0:7:36,26 I have 1 more technical 1. 140 0:7:36,3 --> 0:7:40,94 Yeah Feels like it was a big year for Announcements at least 141 0:7:40,94 --> 0:7:42,34 in the sharding space. 142 0:7:42,44 --> 0:7:51,48 We got at least 3 3 big new projects kicked off to try and shard 143 0:7:51,6 --> 0:7:53,64 Postgres specifically for OLTP 144 0:7:55,44 --> 0:7:56,18 Nikolay: Yes, exactly. 145 0:7:56,26 --> 0:8:0,74 So we we had episodes with PgDog, Lev Kokotov, PgDog. 146 0:8:1,52 --> 0:8:8,22 We have had episode with Sugu Multigres, which is developed 147 0:8:8,32 --> 0:8:9,44 inside Supabase. 148 0:8:10,84 --> 0:8:15,22 And yeah, these are 2 things which are purely open source, and 149 0:8:15,22 --> 0:8:18,16 there is a non-open source product, PlanetScale is developing, 150 0:8:18,16 --> 0:8:18,66 right? 151 0:8:19,16 --> 0:8:20,24 So, yeah. 152 0:8:20,24 --> 0:8:22,26 Michael: I think they've said they're gonna open source it, but 153 0:8:22,26 --> 0:8:23,82 it's all private at the moment. 154 0:8:24,52 --> 0:8:24,62 Nikolay: Yeah. 155 0:8:24,62 --> 0:8:25,12 Yeah. 156 0:8:25,16 --> 0:8:29,6 We have 2 open source things we can also, actually not we can, 157 0:8:29,7 --> 0:8:35,04 my team is already, my team has already tested in terms of latency 158 0:8:35,08 --> 0:8:37,54 overhead, almost all of them. 159 0:8:37,74 --> 0:8:39,38 Michael: Is Multigres testable already? 160 0:8:40,24 --> 0:8:43,1 Nikolay: I've heard kind of yes, I cannot say for sure. 161 0:8:44,16 --> 0:8:45,7 There is something there already. 162 0:8:46,56 --> 0:8:52,1 So I will let them announce all the things, but it's definitely 163 0:8:52,36 --> 0:8:53,9 being developed quite rapidly. 164 0:8:54,52 --> 0:8:56,6 You can go and check pull requests. 165 0:8:57,04 --> 0:8:59,6 What I like about open source is it's very transparent, right? 166 0:9:0,06 --> 0:9:4,92 So you know what's already happening in vector In which it's 167 0:9:4,92 --> 0:9:6,84 being developed in both cases. 168 0:9:8,04 --> 0:9:12,48 This is great power of open source Yeah, yeah 169 0:9:12,48 --> 0:9:17,0 Michael: true and it's yeah, it's Interesting like how they're 170 0:9:17,08 --> 0:9:19,76 choosing slightly different trade-offs and I think it will be 171 0:9:19,76 --> 0:9:23,56 fascinating in the coming years, kind of 3, 4 years time I'd 172 0:9:23,56 --> 0:9:27,26 be really interested to see who's using which systems, what are 173 0:9:27,26 --> 0:9:30,14 the trade-offs, like which kind of systems benefit most from 174 0:9:30,14 --> 0:9:32,76 1 approach versus the other, Does the license matter? 175 0:9:32,76 --> 0:9:35,28 I think PgDog and Multigres have gone different directions on 176 0:9:35,28 --> 0:9:36,64 the licensing front. 177 0:9:37,28 --> 0:9:37,76 Language. 178 0:9:37,76 --> 0:9:38,5 Yeah, exactly. 179 0:9:38,56 --> 0:9:41,2 So it will be interesting, but this felt like the big year. 180 0:9:41,2 --> 0:9:44,14 I think it was, I've written down, it was May that PgDog was 181 0:9:44,14 --> 0:9:45,04 first announced. 182 0:9:45,14 --> 0:9:48,28 June that Multigres was first announced and August that Neki 183 0:9:48,28 --> 0:9:49,18 was first announced. 184 0:9:49,31 --> 0:9:53,0 So quite short, you know, if you consider how long it's been 185 0:9:53,0 --> 0:9:56,76 since we had a new potential sharding solution and then 3 come 186 0:9:56,76 --> 0:9:59,54 along in a few months, it feels like the timing was right for 187 0:9:59,54 --> 0:10:0,56 that to happen now. 188 0:10:0,56 --> 0:10:4,24 Nikolay: So yeah, there are companies which do need it. 189 0:10:4,46 --> 0:10:8,68 And there is big demand, including companies who don't need it. 190 0:10:8,84 --> 0:10:12,62 This is like, yeah, with sharding, more people think they need 191 0:10:12,62 --> 0:10:14,0 it and actually need it. 192 0:10:14,1 --> 0:10:21,72 But it always was a weak side of Postgres ecosystem, lack of 193 0:10:21,82 --> 0:10:24,44 reliable and mature sharding solution. 194 0:10:24,78 --> 0:10:27,7 We had Citus, we had PgCat, we had SPQR. 195 0:10:28,66 --> 0:10:33,22 And none of them was publicly known to be used in big OLTP projects 196 0:10:33,26 --> 0:10:36,52 like huge huge scale like you know like for Vitess. 197 0:10:36,82 --> 0:10:40,18 Vitess we have GitHub, Slack and so on, Pinterest. 198 0:10:40,76 --> 0:10:42,44 Here we didn't have such stories. 199 0:10:42,44 --> 0:10:46,62 We still don't have such stories yet but I'm 100% sure we will 200 0:10:46,62 --> 0:10:50,04 have it soon, just because of this year's development. 201 0:10:50,42 --> 0:10:52,94 Michael: Yeah, the big projects that sharded Postgres, almost 202 0:10:52,94 --> 0:10:55,08 all of them seemed, or at least the ones that have talked about 203 0:10:55,08 --> 0:10:57,66 it publicly, did so application side. 204 0:10:58,08 --> 0:11:3,22 So they have sharded, but it's all on their own heads, basically, 205 0:11:3,46 --> 0:11:6,54 or, you know, using a framework, not a 206 0:11:7,08 --> 0:11:10,46 Nikolay: Oh, yeah, yeah, we had episode 100 terabyte of Postgres. 207 0:11:10,84 --> 0:11:11,66 It was great. 208 0:11:11,66 --> 0:11:17,0 And 2 or 3 guests, I think all the guests use basically application 209 0:11:17,06 --> 0:11:17,82 side sharding. 210 0:11:18,3 --> 0:11:18,8 Yeah. 211 0:11:18,82 --> 0:11:22,0 But at least 1 of them have good articles about this. 212 0:11:22,66 --> 0:11:23,86 I think Notion, right? 213 0:11:23,86 --> 0:11:24,36 Notion. 214 0:11:24,44 --> 0:11:25,78 Michael: And Figma did too. 215 0:11:25,92 --> 0:11:26,74 Nikolay: Okay, great. 216 0:11:27,1 --> 0:11:31,08 So, you can do sharding yourself, of course, right? 217 0:11:31,08 --> 0:11:33,04 But it's good to have some system. 218 0:11:33,94 --> 0:11:36,9 And obviously we are going to have multiple systems which will 219 0:11:36,9 --> 0:11:38,58 be used in big companies soon. 220 0:11:39,52 --> 0:11:41,8 Michael: I think the Vitess thing is really interesting as well 221 0:11:41,8 --> 0:11:45,82 though, because I think there's, you mentioned more people want 222 0:11:45,82 --> 0:11:47,28 sharding than need sharding. 223 0:11:47,42 --> 0:11:51,38 I think there is like a really attractive thing to early stage 224 0:11:51,38 --> 0:11:54,52 startups that, you know, having to tell all their investors they're 225 0:11:54,52 --> 0:11:57,28 going to be the biggest thing ever, probably have to believe 226 0:11:57,28 --> 0:11:58,14 that as well. 227 0:11:58,14 --> 0:12:0,06 So they want, and some of them, it is true, right? 228 0:12:0,06 --> 0:12:3,06 Like some of them are going to need, we talked about 1 last, 229 0:12:3,24 --> 0:12:6,74 last week where it was, they should have partitioned a year ago, 230 0:12:6,74 --> 0:12:8,32 but they only launched a year ago. 231 0:12:8,32 --> 0:12:11,12 So there are these startups that need a small database at the 232 0:12:11,12 --> 0:12:14,02 beginning, and they want, they're going to need sharding within 233 0:12:14,02 --> 0:12:17,06 a couple of years because they're going to scale that fast. 234 0:12:17,36 --> 0:12:21,6 So for them the story of, and it used to be let's say PlanetScale 235 0:12:21,6 --> 0:12:24,94 with Vitess or just Vitess in general, was you can start 236 0:12:24,94 --> 0:12:28,32 small with us and then we, you know, you can have a sharded setup 237 0:12:28,32 --> 0:12:28,86 when you're ready. 238 0:12:28,86 --> 0:12:31,2 It was the same story with Mongo many years ago. 239 0:12:31,2 --> 0:12:34,16 It was this kind of like, I'm going to grow for web scale. 240 0:12:34,16 --> 0:12:35,26 Do you remember that phrase? 241 0:12:35,32 --> 0:12:37,88 So it is really, yeah, it will be nice. 242 0:12:38,48 --> 0:12:41,6 And I think that kind of transitions onto 2 things I had on my 243 0:12:41,6 --> 0:12:41,92 list. 244 0:12:41,92 --> 0:12:47,04 1 was, I think MySQL's loss is Postgres' gain this year. 245 0:12:47,04 --> 0:12:50,72 I think there's been quite a few, like firstly PlanetScale coming 246 0:12:50,72 --> 0:12:53,8 into the Postgres ecosystem, but also I think there were some 247 0:12:53,8 --> 0:12:57,84 stories more recently around a lot of MySQL's team getting laid 248 0:12:57,84 --> 0:12:58,34 off. 249 0:12:58,48 --> 0:13:1,8 So I think momentum on that's been kind of shifting and slowing 250 0:13:1,8 --> 0:13:4,94 for a while since the Oracle acquisition, maybe longer. 251 0:13:5,46 --> 0:13:10,8 But I think Postgres is ready to take up the slack and the work 252 0:13:10,8 --> 0:13:14,22 on sharding is part of that story because I don't think we did 253 0:13:14,22 --> 0:13:19,4 have a good answer to Vitess until, well, and maybe arguably 254 0:13:19,44 --> 0:13:23,36 still don't, but it feels promising that 1, hopefully 1 of these 255 0:13:23,36 --> 0:13:26,54 3, if not more than 1 of these 3, proved to be good. 256 0:13:27,28 --> 0:13:29,14 Nikolay: Yeah, I agree with you. 257 0:13:29,14 --> 0:13:32,24 And that's why I actually mentioned the stories matter. 258 0:13:32,24 --> 0:13:36,54 So we have stories published about successful sharding of Postgres 259 0:13:36,54 --> 0:13:40,58 to great scale in DIY approach. 260 0:13:41,46 --> 0:13:44,72 But we need more like case studies. 261 0:13:44,72 --> 0:13:48,48 And I think I'm looking forward to next couple of years to hear 262 0:13:48,48 --> 0:13:51,92 about successful use of new sharding solutions. 263 0:13:53,1 --> 0:13:54,78 So it's going to be great. 264 0:13:55,24 --> 0:13:59,88 This is a great foundation this year, basically answer that Postgres 265 0:14:0,06 --> 0:14:4,64 won't be considered as very limited OLTP database system where 266 0:14:4,64 --> 0:14:7,84 you will be scared to hit some walls. 267 0:14:8,68 --> 0:14:11,18 All right, so this is a great year for this topic. 268 0:14:11,78 --> 0:14:12,98 I like it a lot. 269 0:14:13,78 --> 0:14:14,86 Okay, let's move on. 270 0:14:14,86 --> 0:14:17,18 Maybe I mentioned less technical stuff. 271 0:14:17,4 --> 0:14:23,1 I think there is a big movement in terms of startups and Postgres 272 0:14:23,1 --> 0:14:27,26 companies, pure Postgres companies and less pure, but also very 273 0:14:27,26 --> 0:14:28,54 Postgres related companies. 274 0:14:28,86 --> 0:14:32,2 For example, let's start from maybe like, there are bad news 275 0:14:32,2 --> 0:14:33,06 and good news. 276 0:14:34,54 --> 0:14:37,26 Bad news, I think, what do you think about Yugabyte? 277 0:14:37,36 --> 0:14:38,56 I think Yugabyte is struggling. 278 0:14:38,56 --> 0:14:45,2 It's not pure Postgres, but it showed some way to, also solid 279 0:14:45,2 --> 0:14:46,0 solution, right? 280 0:14:46,0 --> 0:14:49,44 But I think it's struggling. 281 0:14:49,54 --> 0:14:54,68 I see people like, left, many people, and I also think, the topic 282 0:14:54,68 --> 0:14:57,94 we just discussed, that's a native sharding solution will have 283 0:14:57,94 --> 0:15:2,24 multiple OLTP to achieve great scale and automation. 284 0:15:2,98 --> 0:15:7,32 They are going basically to say Yugabit is not needed anymore. 285 0:15:8,5 --> 0:15:10,68 Michael: Yeah, I honestly don't know. 286 0:15:11,0 --> 0:15:16,04 And I think when we said lots of people, more people want sharded 287 0:15:16,096 --> 0:15:18,42 than want, than need it. 288 0:15:18,42 --> 0:15:20,24 I think the same is true for distributed. 289 0:15:20,32 --> 0:15:24,68 I categorize them slightly differently in my mind, like sharded 290 0:15:24,68 --> 0:15:28,62 and distributed, and I think maybe the difference is the idea 291 0:15:28,62 --> 0:15:32,54 of writing to multiple primaries in different availability zones. 292 0:15:32,72 --> 0:15:36,9 It feels like it's this kind of like, you pay the you pay the 293 0:15:36,9 --> 0:15:41,34 tax on latency and for some it's 100% worth it. 294 0:15:41,78 --> 0:15:44,1 But for a lot it's not that trade off isn't worth it. 295 0:15:44,1 --> 0:15:47,74 And like I think a lot more people think they want multi master 296 0:15:47,78 --> 0:15:50,42 multi or whatever the I don't know what the appropriate phrase 297 0:15:50,42 --> 0:15:52,7 is for that I'm a bit multi primary 298 0:15:53,72 --> 0:15:57,84 Nikolay: not so much so is fine these days again I'm joking interesting 299 0:16:0,26 --> 0:16:4,6 Michael: yeah but yes so my main point is I think for the kind 300 0:16:4,6 --> 0:16:8,6 of financial institutions or big banks that need it, it's hugely 301 0:16:8,6 --> 0:16:11,98 valuable, but I think most companies don't need that and the 302 0:16:11,98 --> 0:16:13,52 trade-offs aren't worth it. 303 0:16:13,52 --> 0:16:15,32 But I have no idea how they're doing. 304 0:16:15,32 --> 0:16:18,34 And also it's kind of Postgres compatible, right? 305 0:16:18,42 --> 0:16:19,9 Do you consider it Postgres? 306 0:16:19,9 --> 0:16:21,28 Nikolay: Well, yeah, yeah, you're right. 307 0:16:21,28 --> 0:16:21,82 You're right. 308 0:16:21,82 --> 0:16:25,76 It's more Postgres compatible than CockroachDB, but it's definitely 309 0:16:25,76 --> 0:16:26,7 not pure Postgres. 310 0:16:27,18 --> 0:16:32,72 Anyway, I think solutions we just discussed are going to meet 311 0:16:32,72 --> 0:16:37,46 needs of people who start with just small 1 Postgres like more 312 0:16:37,46 --> 0:16:41,12 naturally, you know, like then migrating to other systems. 313 0:16:41,2 --> 0:16:45,42 Although at the same time, we must admit that, for example, AlloyDB 314 0:16:45,46 --> 0:16:46,04 feels good. 315 0:16:46,04 --> 0:16:51,66 I have customers who migrated to AlloyDB and actually I can mention 316 0:16:51,66 --> 0:16:55,32 Gadget for example, we had an episode with Gadget CTO, right, 317 0:16:55,32 --> 0:16:59,66 Harry, and we just found out that our monitoring system works 318 0:16:59,8 --> 0:17:4,08 well with AlloyDB and like AlloyDB also has bloat and so on things 319 0:17:4,08 --> 0:17:7,66 to take care of it's interesting so it feels like Postgres although 320 0:17:7,66 --> 0:17:13,44 there is a lot of rewritten also this year I think It's important 321 0:17:13,44 --> 0:17:18,78 to mention Amazon DSQL although it's not open source at all, 322 0:17:18,9 --> 0:17:23,22 but it also plays in the same area for enterprises. 323 0:17:23,62 --> 0:17:27,78 They are not limited, distributed, everything, multi-region, 324 0:17:28,1 --> 0:17:28,6 everything. 325 0:17:29,06 --> 0:17:32,84 And they are quite active in terms of development, I think, although 326 0:17:32,84 --> 0:17:34,14 it's not my area at all. 327 0:17:34,14 --> 0:17:38,9 Like I'm pure Postgres guy and I consider all these friends of 328 0:17:38,9 --> 0:17:41,98 Postgres so to speak, some of them open source, some are not. 329 0:17:42,28 --> 0:17:45,44 It's just like for me it's kind of it's great to have them around, 330 0:17:45,44 --> 0:17:51,1 but I think pure Postgres should be majority of in terms of choices. 331 0:17:52,08 --> 0:17:55,46 Michael: Yeah and well like each of the each of the hyperscalers 332 0:17:55,68 --> 0:17:58,86 has their version of this product right this kind of distributed 333 0:17:59,04 --> 0:18:2,32 Postgres compatible for whatever definition of Postgres compatible 334 0:18:2,32 --> 0:18:7,32 that they're going with this year But there has still been significant 335 0:18:8,24 --> 0:18:11,94 contributions from these hyperscalers to pure Postgres. 336 0:18:12,18 --> 0:18:16,88 And I think there's a kind of alternative timeline where we wouldn't 337 0:18:16,88 --> 0:18:21,66 be seeing the likes of AWS and Microsoft and even a little bit 338 0:18:21,66 --> 0:18:24,66 Google Cloud, but like lots and lots of companies, but including 339 0:18:24,66 --> 0:18:28,42 those hyperscalers actually contributing back to pure Postgres, 340 0:18:28,42 --> 0:18:30,9 not just making their own proprietary forks. 341 0:18:31,1 --> 0:18:36,52 So it's been quite, I really hope it continues, but this year 342 0:18:36,58 --> 0:18:39,44 it certainly feels like a lot of the contributions we got a lot 343 0:18:39,44 --> 0:18:42,54 of the improvements in Postgres 18, a lot of the community efforts 344 0:18:42,74 --> 0:18:43,98 came from these big companies. 345 0:18:43,98 --> 0:18:47,06 And I would include EDB in that as well in terms of big companies 346 0:18:47,08 --> 0:18:49,2 continuing to like invest in 347 0:18:49,2 --> 0:18:49,96 Nikolay: pure Postgres. 348 0:18:50,28 --> 0:18:53,2 Microsoft HorizonDB, this is fresh news. 349 0:18:53,32 --> 0:18:58,88 I already, I lost track for this enterprise attempt, like enterprise 350 0:18:58,94 --> 0:19:0,14 Postgres topic, right? 351 0:19:0,14 --> 0:19:1,66 Like so many options. 352 0:19:3,22 --> 0:19:8,36 I think Pure Postgres is a player in enterprise and it's going 353 0:19:8,36 --> 0:19:10,02 to stay as a player in enterprise. 354 0:19:10,26 --> 0:19:16,04 Although we have Aurora, AlloyDB, HorizonDB, DSQL, who else? 355 0:19:16,32 --> 0:19:17,62 EDB, everything. 356 0:19:17,78 --> 0:19:20,74 Michael: Yeah, but all of them also offer a separate product 357 0:19:20,74 --> 0:19:23,7 that is much, much closer to pure Postgres. 358 0:19:24,96 --> 0:19:25,32 Right. 359 0:19:25,32 --> 0:19:31,22 So AWS have RDS, Google have Cloud SQL, you know, if every actually 360 0:19:31,22 --> 0:19:34,64 always forget what Microsoft call theirs, but every single 1 361 0:19:34,64 --> 0:19:39,52 of them have 1 that looks just like Postgres. 362 0:19:39,96 --> 0:19:41,34 That acts just like Postgres. 363 0:19:42,12 --> 0:19:47,56 Yeah, it's something like for PostgreSQL or something. 364 0:19:48,34 --> 0:19:50,64 Nikolay: We have customers, but I don't even remember. 365 0:19:52,12 --> 0:19:54,9 With Microsoft, I touch Microsoft much less than others. 366 0:19:55,58 --> 0:19:58,3 Michael: Microsoft is good at a lot of things, but naming products 367 0:19:58,3 --> 0:19:59,56 is not 1 of them. 368 0:20:0,18 --> 0:20:2,98 Nikolay: Well, Google is a champion. 369 0:20:2,98 --> 0:20:3,58 Michael: Yeah, fair. 370 0:20:4,94 --> 0:20:8,32 Nikolay: So anyway, we have so many flavors of Postgres, right? 371 0:20:8,32 --> 0:20:11,68 And obviously there is an interesting competition in the area 372 0:20:11,68 --> 0:20:16,06 of Sharding and there is all this competition, which not started 373 0:20:16,06 --> 0:20:21,38 this year, it started much earlier, but now it's becoming Definitely 374 0:20:21,38 --> 0:20:24,4 like kind of red ocean in terms of enterprise policies topic, 375 0:20:24,4 --> 0:20:24,9 right? 376 0:20:25,32 --> 0:20:29,32 This is absolutely a red ocean every big company is playing there. 377 0:20:29,64 --> 0:20:31,96 Every big cloud company is playing there 378 0:20:31,96 --> 0:20:35,6 Michael: Yeah, that's an interesting point because if you're 379 0:20:35,6 --> 0:20:39,36 talking about it being highly, highly competitive, normally what 380 0:20:39,36 --> 0:20:44,38 you'd expect to see if that was the case would be prices starting 381 0:20:44,38 --> 0:20:45,06 to come down. 382 0:20:45,06 --> 0:20:47,5 And I don't think we've seen that. 383 0:20:47,5 --> 0:20:50,14 Like I still think they're charging quite a premium for it. 384 0:20:50,14 --> 0:20:54,22 So but if it was truly a red ocean, I don't know, maybe I'm not 385 0:20:54,22 --> 0:20:56,54 seeing the kind of enterprise contract negotiations. 386 0:20:56,72 --> 0:20:58,88 Maybe that's where the prices are coming down. 387 0:20:58,94 --> 0:20:59,1 — 388 0:20:59,1 --> 0:21:0,76 Nikolay: Well, yeah, Maybe you're right. 389 0:21:0,76 --> 0:21:4,64 I think there are segments there and in the segment of like big 390 0:21:4,64 --> 0:21:6,14 Postgres, enterprise Postgres. 391 0:21:7,92 --> 0:21:10,9 I think there are different methods to cut prices. 392 0:21:10,9 --> 0:21:15,26 They all like normal cloud ways, you know, like, like savings 393 0:21:15,26 --> 0:21:17,18 plans, saving plans and so on. 394 0:21:17,52 --> 0:21:18,02 Yeah. 395 0:21:18,7 --> 0:21:23,14 But they don't rush into going down in terms of prices for Postgres 396 0:21:23,16 --> 0:21:24,06 for 1 machine. 397 0:21:24,06 --> 0:21:25,38 Obviously, there is big premium. 398 0:21:26,32 --> 0:21:31,08 In terms of technical things trends this year, not touching AI 399 0:21:31,08 --> 0:21:33,22 yet, but maybe moving closer to it. 400 0:21:33,7 --> 0:21:40,4 I think branching is becoming, like, slowly, very slowly, it 401 0:21:40,4 --> 0:21:42,22 makes its way to being commodity. 402 0:21:42,34 --> 0:21:44,44 It's not yet there at all, like I think. 403 0:21:44,44 --> 0:21:48,44 And branching is still very rare. 404 0:21:48,92 --> 0:21:52,64 It's not, like, not everyone has it. 405 0:21:53,3 --> 0:21:53,76 — I feel 406 0:21:53,76 --> 0:21:55,96 Michael: like there's 2 trends, right? 407 0:21:55,96 --> 0:21:59,22 Like I feel like there's branching and there's also cloning and 408 0:21:59,22 --> 0:22:2,08 these are very kind of like similar topics and they're kind of 409 0:22:2,08 --> 0:22:6,88 being converged at and some, some platforms and some systems 410 0:22:6,94 --> 0:22:8,16 offer, offer cloning. 411 0:22:8,2 --> 0:22:9,52 Nikolay: Well, some 412 0:22:9,52 --> 0:22:12,48 Michael: platforms, some platforms offer thin cloning some, 413 0:22:12,5 --> 0:22:15,56 but mostly it's thick cloning, but that's still, that's still 414 0:22:16,22 --> 0:22:21,54 valuable for some amounts of experimentation and test runs. 415 0:22:21,6 --> 0:22:25,58 Nikolay: Yes, had always, since the very beginning. 416 0:22:27,04 --> 0:22:30,08 Michael: And Heroku even, Heroku even offered it. 417 0:22:30,08 --> 0:22:33,82 Nikolay: Right, But if it's thick, well, tooling is improving 418 0:22:33,82 --> 0:22:34,76 there for sure. 419 0:22:34,76 --> 0:22:39,78 But, I'm big fan of, you know, like I'm, I'm big fan of thin 420 0:22:39,78 --> 0:22:43,04 cloning and we have our own product, DBLab for database branching 421 0:22:43,04 --> 0:22:43,78 and thin cloning. 422 0:22:43,78 --> 0:22:49,44 And, I think is if before this year, Neon was there, DBLab was 423 0:22:49,44 --> 0:22:50,54 there and that's it. 424 0:22:50,74 --> 0:22:55,36 Now we see Timescale, Tigris data playing there. 425 0:22:55,38 --> 0:22:56,62 Michael: That happened this year. 426 0:22:57,04 --> 0:23:1,0 Nikolay: Understanding its role for AI and experiments is great. 427 0:23:1,0 --> 0:23:5,64 Like This is exactly how I see it for many years already. 428 0:23:6,6 --> 0:23:11,18 And their CTO Mike just posted yesterday an article how Replit 429 0:23:11,18 --> 0:23:12,68 is doing this similar thing. 430 0:23:12,9 --> 0:23:18,68 So experimentation at scale, like in isolated environments and 431 0:23:18,7 --> 0:23:21,96 to make it fast and cheap, you need copy on write. 432 0:23:22,28 --> 0:23:26,28 So this is the way you like basically you can have a lot of ideas 433 0:23:26,28 --> 0:23:28,34 how to improve your database. 434 0:23:28,86 --> 0:23:31,84 And not everything can be verified on thin cloning, but a lot 435 0:23:31,84 --> 0:23:36,18 of ideas can be verified and in the isolated Postgres instances 436 0:23:36,28 --> 0:23:37,86 and database branching is great. 437 0:23:37,9 --> 0:23:41,26 For example, definitely everything related to query optimization 438 0:23:42,18 --> 0:23:45,52 at macro level, we discussed it many times, working with plans, 439 0:23:45,52 --> 0:23:48,64 verifying ideas, this is absolutely needed. 440 0:23:49,24 --> 0:23:54,22 Think otherwise you become too slow, too expensive, and you are 441 0:23:54,22 --> 0:23:54,72 limited. 442 0:23:55,08 --> 0:23:58,86 And in the topic of self-driving Postgres, we actually, yesterday 443 0:23:58,94 --> 0:24:2,32 I noticed big trend, Like people started talking about autonomous 444 0:24:2,32 --> 0:24:3,82 Postgres and self-driving Postgres. 445 0:24:3,82 --> 0:24:9,28 We had, I have a post, someone from EDB mentioned something and 446 0:24:9,28 --> 0:24:10,22 I also posted. 447 0:24:10,58 --> 0:24:13,92 So this is part of autonomous Postgres for sure. 448 0:24:14,16 --> 0:24:17,86 Automated experimentation and branching is essential part of 449 0:24:17,86 --> 0:24:18,64 this vision. 450 0:24:18,86 --> 0:24:22,16 And we have pieces already when companies start implementing 451 0:24:22,24 --> 0:24:22,74 this. 452 0:24:24,26 --> 0:24:29,34 So this works at GitLab, DBLab for many years already so I'm 453 0:24:29,34 --> 0:24:34,2 happy this topic becomes more and more popular and future of 454 0:24:34,2 --> 0:24:38,98 self-driving Postgres also like it's still foggy But we have 455 0:24:38,98 --> 0:24:43,26 components which already becoming quite clear and we see how 456 0:24:43,26 --> 0:24:47,02 to achieve levels of automation very high levels of automation 457 0:24:48,22 --> 0:24:48,46 So 458 0:24:48,46 --> 0:24:49,3 Michael: did you see? 459 0:24:49,98 --> 0:24:53,94 In this on this topic area of like branching, thin cloning, and 460 0:24:53,94 --> 0:24:57,68 copy on write, did you see there was a recent post by Radim from 461 0:24:57,98 --> 0:25:2,38 Boring SQL talking about a feature in Postgres 18 that I'd missed 462 0:25:2,72 --> 0:25:7,7 that is like you can create database within Postgres and and 463 0:25:7,7 --> 0:25:11,96 specify a strategy and that can use if your file system supports 464 0:25:12,44 --> 0:25:16,8 Nikolay: yeah yeah yeah I actually I also missed I remember this 465 0:25:16,8 --> 0:25:22,0 discussion on hackers mailing list, but I somehow overlooked it. 466 0:25:22,0 --> 0:25:24,34 So it's already Postgres 18, are you sure? 467 0:25:24,34 --> 0:25:24,84 Michael: Yeah. 468 0:25:25,76 --> 0:25:26,26 Wow. 469 0:25:26,4 --> 0:25:29,44 I haven't verified myself, but this blog post says so, yeah. 470 0:25:30,06 --> 0:25:32,36 Nikolay: It has a limited scope of use. 471 0:25:32,36 --> 0:25:35,88 So I think if you control everything, all experimentation environments 472 0:25:35,92 --> 0:25:37,86 very well, you can definitely use it. 473 0:25:37,86 --> 0:25:40,6 So basically you have 1 single Postgres instance and each create 474 0:25:40,6 --> 0:25:41,1 database. 475 0:25:41,18 --> 0:25:44,28 If it's based on copy and write, it's fast and cheap. 476 0:25:44,44 --> 0:25:47,46 It brings you isolated logical database for experimentation, 477 0:25:48,1 --> 0:25:49,34 but it's not for everything. 478 0:25:49,34 --> 0:25:53,04 For example, in the case of DBLab, you can perform major upgrade 479 0:25:53,04 --> 0:25:53,7 of clone. 480 0:25:54,78 --> 0:25:54,84 Sure. 481 0:25:54,84 --> 0:25:55,46 And test. 482 0:25:55,76 --> 0:25:58,88 Here, it will be not possible because it's a single instance. 483 0:25:59,34 --> 0:26:4,74 Although, working with like ideas how to verify indexes, to tone 484 0:26:4,74 --> 0:26:6,58 tuning, this will work for sure. 485 0:26:6,58 --> 0:26:7,36 This is great. 486 0:26:7,36 --> 0:26:7,86 Michael: Yeah. 487 0:26:8,4 --> 0:26:8,9 Yeah. 488 0:26:9,62 --> 0:26:12,66 And baked into Postgres already, that's super cool. 489 0:26:12,66 --> 0:26:13,74 Nikolay: Yeah, well, that's cool. 490 0:26:13,74 --> 0:26:14,14 That's cool. 491 0:26:14,14 --> 0:26:17,26 I need to revisit this somehow, I overlooked as well. 492 0:26:18,54 --> 0:26:19,78 Great, great. 493 0:26:19,78 --> 0:26:23,8 I think what we like, what we see in the future, more tools which 494 0:26:23,8 --> 0:26:28,18 will automate experimentation for optimization, performance optimization, 495 0:26:28,84 --> 0:26:33,08 and instead of like throwing something to LLM and sitting with 496 0:26:33,08 --> 0:26:38,1 ideas which you don't know which of them are correct which are 497 0:26:38,1 --> 0:26:39,06 completely wrong. 498 0:26:39,62 --> 0:26:43,3 You will throw to some tool and LLM will generate ideas. 499 0:26:43,5 --> 0:26:46,18 Well, this is Actually already happening. 500 0:26:46,46 --> 0:26:49,8 We just don't have it connected to all the pieces, right? 501 0:26:49,96 --> 0:26:55,74 But we ideas are verified on close on thin clones, right? 502 0:26:55,9 --> 0:26:59,82 Yeah, and the user receives already ideas which were considered 503 0:26:59,82 --> 0:27:4,44 during brainstorm phase and then ideas which didn't work and 504 0:27:4,54 --> 0:27:9,22 ideas which worked best proposed for to apply in production. 505 0:27:9,92 --> 0:27:12,72 Michael: Yeah, I personally think this is something, this is 506 0:27:12,72 --> 0:27:15,92 a topic that has got a lot of legs for the coming years But I 507 0:27:15,92 --> 0:27:18,96 don't think we've seen yet that much like I don't think I think 508 0:27:18,96 --> 0:27:21,04 we've only seen the beginnings of this topic Yeah, 509 0:27:21,04 --> 0:27:24,78 Nikolay: and the pieces Some basically like building blocks we 510 0:27:24,78 --> 0:27:25,12 have. 511 0:27:25,12 --> 0:27:28,7 Yeah, the final like the whole solution is yet to be built. 512 0:27:28,7 --> 0:27:29,4 I agree 513 0:27:30,04 --> 0:27:33,24 Michael: Did you see much progress on the vector search side 514 0:27:33,24 --> 0:27:34,38 of things this year? 515 0:27:35,14 --> 0:27:38,92 Nikolay: Oh yeah, I remember I started here looking at turbopuffer. 516 0:27:40,16 --> 0:27:42,54 We found that we also had an episode. 517 0:27:43,58 --> 0:27:46,56 So it confirms it's a great successful year for Postgres, but 518 0:27:46,56 --> 0:27:51,14 also for PostgresFM podcast, because we had great episodes covering 519 0:27:51,76 --> 0:27:55,22 areas which are important for users, right? 520 0:27:55,68 --> 0:28:1,46 So, turbopuffer were great, and this approach with vectors in S3, 521 0:28:1,72 --> 0:28:5,34 and you know S3 also now has a vector type. 522 0:28:6,44 --> 0:28:11,88 I revisited recently and it's outside of Postgres, but I started 523 0:28:11,88 --> 0:28:16,5 looking at it because I noticed clients who come to us using 524 0:28:16,5 --> 0:28:18,68 Postgres, they use them. 525 0:28:19,02 --> 0:28:22,06 And also I noticed it's used in Cursor, so that's how I know 526 0:28:22,06 --> 0:28:22,86 there's turbopuffer. 527 0:28:23,44 --> 0:28:28,94 So a combination of Postgres plus turbopuffer, it's kind of like 528 0:28:28,94 --> 0:28:32,64 I saw trends similar to you know, like elastic, Postgres plus 529 0:28:32,64 --> 0:28:33,14 elastic. 530 0:28:33,82 --> 0:28:35,36 Similar, like something happening. 531 0:28:36,5 --> 0:28:39,44 And I thought like it's great like in terms of price and like 532 0:28:39,44 --> 0:28:40,58 technology is great. 533 0:28:41,32 --> 0:28:43,28 And S3 also has vectors now. 534 0:28:43,58 --> 0:28:48,56 But I think it's still to be understood use cases for all of 535 0:28:48,56 --> 0:28:52,26 these Approaches and pgvector is going to stay. 536 0:28:52,58 --> 0:28:54,12 I wish it was in core. 537 0:28:54,44 --> 0:28:57,56 I don't see how it's possible now But 538 0:28:57,56 --> 0:29:1,12 Michael: I've had conversations about it there I haven't I haven't 539 0:29:1,12 --> 0:29:3,74 been looking closely, but I might have missed them. 540 0:29:3,82 --> 0:29:6,8 Have there been conversations about doing something in core, 541 0:29:7,12 --> 0:29:8,46 like, formally? 542 0:29:10,08 --> 0:29:13,58 Nikolay: All beginnings of conversations were just interrupted. 543 0:29:13,7 --> 0:29:19,0 Like, this index type is not normal because it's answering different 544 0:29:19,0 --> 0:29:20,66 results, right? 545 0:29:20,66 --> 0:29:24,52 Because it's due to its approximate nature. 546 0:29:25,16 --> 0:29:29,4 Basically, it's not deterministic, right? 547 0:29:30,04 --> 0:29:31,54 And this brings new challenges. 548 0:29:32,36 --> 0:29:36,26 So to be considered as a core thing, but in my opinion, it must 549 0:29:36,26 --> 0:29:41,34 be in core to be developed properly and be considered as something 550 0:29:41,42 --> 0:29:42,48 like super standard. 551 0:29:42,56 --> 0:29:45,08 Although, pgvector is super standard thanks to all managed 552 0:29:45,08 --> 0:29:46,82 platforms supporting it as well. 553 0:29:47,08 --> 0:29:48,54 So all people start there. 554 0:29:48,54 --> 0:29:52,2 I wanted to say this, I don't see anyone who solved 1 billion 555 0:29:52,2 --> 0:29:53,46 vectors problem yet. 556 0:29:54,02 --> 0:29:59,4 All those who claim they solved it, I think they are lying. 557 0:30:0,56 --> 0:30:2,9 Michael: It's like the spacing, right? 558 0:30:2,9 --> 0:30:4,12 What do they call it? 559 0:30:4,44 --> 0:30:8,44 Nikolay: They say, you know it's bad, but you need to basically 560 0:30:8,44 --> 0:30:12,6 cluster, not cluster, partition it, right? 561 0:30:12,72 --> 0:30:15,14 So it's not 1 index, it's multiple indexes. 562 0:30:16,3 --> 0:30:20,78 Like key spaces, namespaces, you call it, use any word. 563 0:30:20,8 --> 0:30:23,32 But what it means is that you don't have a single index which 564 0:30:23,32 --> 0:30:28,76 supports good OLTP scale, OLTP latencies, meaning it's definitely 565 0:30:29,6 --> 0:30:35,78 much faster than 1 second for a single query and has covering 566 0:30:36,16 --> 0:30:37,16 1 billion vectors. 567 0:30:37,18 --> 0:30:38,38 Nobody does it. 568 0:30:38,5 --> 0:30:39,78 S3 including, right? 569 0:30:39,78 --> 0:30:43,94 S3 also like has maximum, I don't remember, 50 million or how 570 0:30:43,94 --> 0:30:47,72 many vectors in 1 index supports. 571 0:30:48,1 --> 0:30:53,04 So anyway, this is unsolved problem and it's unsolved, I think, 572 0:30:53,04 --> 0:30:55,14 everywhere, not inside Postgres ecosystem. 573 0:30:55,76 --> 0:30:57,28 So it's a big problem still. 574 0:30:57,54 --> 0:30:59,28 How to have a single index? 575 0:31:0,06 --> 0:31:1,78 Why do we need a single index? 576 0:31:2,26 --> 0:31:3,62 Maybe we don't need it. 577 0:31:3,62 --> 0:31:5,58 Maybe we can always split it. 578 0:31:5,58 --> 0:31:13,52 PgDog also showed how to combine sharding and pgvector, right? 579 0:31:13,52 --> 0:31:16,72 So you can have multiple Postgres instances and so on. 580 0:31:17,98 --> 0:31:23,54 Questions about price and so on also can pop up, but turbopuffer 581 0:31:23,56 --> 0:31:24,64 is not open source. 582 0:31:25,4 --> 0:31:29,44 Again, like, we have great open source tooling already and and 583 0:31:29,64 --> 0:31:32,98 if you combine with sharding maybe you are fine but I haven't 584 0:31:32,98 --> 0:31:36,7 seen a single 1 billion scale index which would work. 585 0:31:37,06 --> 0:31:38,04 Michael: — Why does it matter? 586 0:31:38,04 --> 0:31:42,38 Like, if I have a partition table, that's not, that doesn't have 587 0:31:42,38 --> 0:31:43,68 a single index on it. 588 0:31:43,68 --> 0:31:44,36 — Right. 589 0:31:44,88 --> 0:31:46,32 — So why does it matter? 590 0:31:46,42 --> 0:31:46,44 — 591 0:31:46,44 --> 0:31:46,94 Nikolay: Complexity. 592 0:31:47,44 --> 0:31:50,74 If you talk about regular indexes, having a few billion records 593 0:31:50,74 --> 0:31:52,62 in a table is not a problem at all. 594 0:31:52,74 --> 0:31:56,66 And latency will be amazing if you have index-only scan, or just 595 0:31:56,66 --> 0:31:57,48 index scan. 596 0:31:57,7 --> 0:32:2,66 If you don't have these rows filtered out, right? 597 0:32:2,8 --> 0:32:6,34 But when it comes to vectors, if you have 1 billion vectors 598 0:32:6,34 --> 0:32:11,92 and you try to cover it with single index, build time will be 599 0:32:11,92 --> 0:32:16,84 terrible for HNSW, latency will be terrible, so it's not OLTP. 600 0:32:17,28 --> 0:32:20,9 It cannot be, it doesn't meet OLTP standards, which we know like 601 0:32:20,9 --> 0:32:24,0 100, 200 milliseconds maximum because of human perception. 602 0:32:24,7 --> 0:32:26,26 Michael: Yeah, but not for search. 603 0:32:26,66 --> 0:32:27,68 Nikolay: For search including. 604 0:32:28,26 --> 0:32:28,78 Search is 605 0:32:28,78 --> 0:32:32,3 Michael: 1 of those use cases where people are willing to, okay 606 0:32:32,3 --> 0:32:32,78 fine. 607 0:32:32,78 --> 0:32:33,48 Nikolay: No, no, no. 608 0:32:33,48 --> 0:32:36,38 Are you okay if you Google something and you need to wait 10 609 0:32:36,38 --> 0:32:36,82 seconds? 610 0:32:36,82 --> 0:32:37,7 You're not okay. 611 0:32:39,4 --> 0:32:40,76 Michael: Yeah it's a good point actually. 612 0:32:40,76 --> 0:32:43,78 I think Google is probably the proof that search is important 613 0:32:43,78 --> 0:32:44,44 to be fast. 614 0:32:44,44 --> 0:32:44,76 Nikolay: Of course. 615 0:32:44,76 --> 0:32:45,6 Because That's what they've 616 0:32:45,6 --> 0:32:46,12 Michael: always focused 617 0:32:46,12 --> 0:32:46,4199 Nikolay: on. 618 0:32:46,4199 --> 0:32:47,58 People need it everywhere. 619 0:32:47,8201 --> 0:32:52,9 Like you have mobile app, you type something, you want to move 620 0:32:52,9 --> 0:32:53,76 it very fast. 621 0:32:54,64 --> 0:32:57,76 If it's below 100 milliseconds, it doesn't feel slow. 622 0:32:57,92 --> 0:32:58,68 That's great. 623 0:32:58,9 --> 0:33:2,56 So we have human perception, which defines what multi-piece. 624 0:33:3,14 --> 0:33:5,22 Michael: You don't need to convince me that performance matters 625 0:33:5,22 --> 0:33:7,74 and it's good, but I was just thinking that might 626 0:33:7,74 --> 0:33:7,98 Nikolay: be. 627 0:33:7,98 --> 0:33:9,9 Search is considered part of application. 628 0:33:10,04 --> 0:33:13,58 It's not like we have such system Okay, let's in some cases. 629 0:33:13,58 --> 0:33:19,94 Okay if it's some If it's a lawyer who needs to pull some lawsuits 630 0:33:20,86 --> 0:33:25,44 from history like Related to the topic they are working on right 631 0:33:25,44 --> 0:33:28,48 now They can wait a minute. 632 0:33:28,48 --> 0:33:33,34 No problem Or if it's Like bi report this actually means we overlooked 633 0:33:33,34 --> 0:33:38,56 1 trend as well Analytical thing right so yeah market iceberg 634 0:33:38,56 --> 0:33:43,48 and and DuckDB and how to bring all this and Postgres couple 635 0:33:43,48 --> 0:33:49,02 of a few companies played good game and And we are acquired 636 0:33:50,02 --> 0:33:53,96 Michael: Yeah, I would say this was huge news, I think, let's 637 0:33:53,96 --> 0:33:54,98 say last year. 638 0:33:55,08 --> 0:33:59,58 And then I think this year what happened as a result were possibly 639 0:33:59,64 --> 0:34:3,7 that 1 of the biggest analytic databases companies in the world 640 0:34:3,7 --> 0:34:7,22 acquired what was 1 of the most promising companies in this space. 641 0:34:7,78 --> 0:34:11,96 So that was, I actually, yeah I had that on my list to cover, 642 0:34:11,96 --> 0:34:14,66 I was thinking that's more community side of things, but I guess 643 0:34:14,66 --> 0:34:17,72 it's technical because it's it came about probably because of 644 0:34:17,72 --> 0:34:19,78 their progress on the analytics space. 645 0:34:20,64 --> 0:34:24,66 Nikolay: Yeah, so obviously Crunchy Data started to work with 646 0:34:24,72 --> 0:34:29,24 analytical side of Postgres, which was always considered weak 647 0:34:29,24 --> 0:34:34,64 and achieved had great achievements and got acquired for a quarter 648 0:34:34,64 --> 0:34:35,42 of 1,000,000,000. 649 0:34:35,94 --> 0:34:40,3 And Neon, although it's, they didn't play a lot with analytics. 650 0:34:40,38 --> 0:34:43,94 They did something with DugDB, as I saw, like, they tried here 651 0:34:43,94 --> 0:34:48,62 and there things, but still it was purely an OLTP thing, right? 652 0:34:49,62 --> 0:34:53,96 For, with branching and super fast point-in-time recovery and 653 0:34:53,96 --> 0:34:55,14 serverless, everything. 654 0:34:55,6 --> 0:34:58,22 And got acquired by Snowflake for 1,000,000,000. 655 0:34:59,54 --> 0:35:0,04 Michael: Databricks. 656 0:35:0,72 --> 0:35:2,06 Nikolay: Oh, Databricks, yes. 657 0:35:2,18 --> 0:35:5,66 Snowflake, Crunchy, Databricks, Neon, right. 658 0:35:6,48 --> 0:35:12,24 And they are, as we see, they both work to bring solutions which 659 0:35:12,24 --> 0:35:16,52 are combined, like analytics plus OLTP and everything. 660 0:35:17,78 --> 0:35:21,02 We could consider this also from a different angle, but this 661 0:35:21,02 --> 0:35:26,18 is also a game to conquer like enterprise Postgres topic, right? 662 0:35:26,4 --> 0:35:28,58 Just coming from a political perspective first. 663 0:35:29,18 --> 0:35:30,06 And it's interesting. 664 0:35:31,5 --> 0:35:35,56 I like what's happening, And I also like that some people don't 665 0:35:35,66 --> 0:35:41,24 like to be not in open source environment and more talents are 666 0:35:41,24 --> 0:35:41,74 available. 667 0:35:42,56 --> 0:35:43,3 Michael: Oh, interesting. 668 0:35:43,32 --> 0:35:45,12 Nikolay: To be higher because of these acquisitions. 669 0:35:45,18 --> 0:35:48,66 Yeah, of course it's natural because both Snowflake and Databricks, 670 0:35:49,4 --> 0:35:52,66 I don't consider them as pro open source companies at all. 671 0:35:53,68 --> 0:35:57,54 And we know Neon, I haven't checked for a few weeks, but Neon 672 0:35:57,9 --> 0:36:3,98 stopped showing any commits on GitHub since July, right? 673 0:36:4,08 --> 0:36:8,36 Michael: Yeah, that's the tricky thing with acquisitions like 674 0:36:8,36 --> 0:36:13,68 this, because if you read the posts about what the plan is and 675 0:36:13,68 --> 0:36:16,92 what they're announcing is going to happen, and then watch for 676 0:36:16,92 --> 0:36:19,74 5 years, quite often those things don't align. 677 0:36:19,82 --> 0:36:23,14 So it's really difficult to assess these things within, you know, 678 0:36:23,14 --> 0:36:26,76 6 months of them happening as to why did it happen? 679 0:36:26,94 --> 0:36:28,92 Is this a good thing for the community? 680 0:36:29,06 --> 0:36:30,7 Is it a bad thing for the community? 681 0:36:31,08 --> 0:36:32,24 It's really hard to tell. 682 0:36:32,24 --> 0:36:35,04 It could be the best thing ever, or it could be awful. 683 0:36:35,74 --> 0:36:39,86 And it's really hard to tell this close to it, which of those 684 0:36:39,86 --> 0:36:41,02 is gonna be the case. 685 0:36:41,4 --> 0:36:44,48 Nikolay: Yeah, in this context, I would like to mention also 686 0:36:44,48 --> 0:36:48,98 a couple of companies which I like what's happening as well. 687 0:36:49,9 --> 0:36:55,52 Like you can see like some negative sides, but you can see a 688 0:36:55,52 --> 0:36:57,2002 lot of positive sides in everywhere. 689 0:36:57,2002 --> 0:36:59,84 For example, Planescale came to Postgres ecosystem. 690 0:37:1,16 --> 0:37:5,72 And they resurrected the old topic, which some people tried to 691 0:37:7,04 --> 0:37:8,0 bring life into. 692 0:37:8,0 --> 0:37:10,28 It's let's use local NVMe disks. 693 0:37:10,52 --> 0:37:12,94 That's great, like absolutely great. 694 0:37:13,36 --> 0:37:17,42 And they also, like I like what they do a lot, in a lot of areas. 695 0:37:17,54 --> 0:37:20,14 I don't like their position with open source because I don't 696 0:37:20,14 --> 0:37:21,9 see what open source they produce at all. 697 0:37:21,9 --> 0:37:25,92 They just use Vitess, which was created before PlanetScale and 698 0:37:25,92 --> 0:37:26,66 that's it. 699 0:37:27,38 --> 0:37:29,12 Michael: And maintain it, I think, yeah. 700 0:37:29,38 --> 0:37:31,56 Nikolay: Well, yeah, yeah, that's, that's, that's of course, 701 0:37:31,56 --> 0:37:32,58 but what else? 702 0:37:33,54 --> 0:37:38,74 So anyway, but I like a lot what they do and they brought absolutely 703 0:37:39,14 --> 0:37:45,06 different, I think different kind of views at things which Postgres 704 0:37:45,06 --> 0:37:46,82 ecosystem somehow missed. 705 0:37:47,04 --> 0:37:52,4 So like it's kind of blood of MySQL ecosystem was merged 706 0:37:52,94 --> 0:37:54,94 to Postgres ecosystem and this is great. 707 0:37:54,94 --> 0:38:1,56 Like I've different points of view and so on and This feels really 708 0:38:1,56 --> 0:38:4,8 great and this year achievement, I think, in terms of Postgres 709 0:38:5,02 --> 0:38:6,04 ecosystem development. 710 0:38:6,54 --> 0:38:10,54 And another is, of course, Supabase, which is pure open source. 711 0:38:10,68 --> 0:38:14,16 They bet heavily on open source and Multi-model and OrioleDB 712 0:38:15,32 --> 0:38:16,2 and all things. 713 0:38:16,42 --> 0:38:21,06 And this is their, I think, strategy to do things open source. 714 0:38:21,22 --> 0:38:22,1 And their growth is... 715 0:38:22,1 --> 0:38:23,56 Well, and not just, I would 716 0:38:23,56 --> 0:38:26,44 Michael: say not just open source, but with permissive licenses 717 0:38:26,88 --> 0:38:30,6 Yeah, I think it's I think that's incredible is I think it's 718 0:38:30,6 --> 0:38:34,94 something that people don't really fully appreciate of how important 719 0:38:34,94 --> 0:38:37,88 it was for PostgreSQL to have a perm, not just an open source 720 0:38:37,88 --> 0:38:40,58 license, but a really permissive open source license. 721 0:38:41,12 --> 0:38:41,5 Nikolay: Yeah. 722 0:38:41,5 --> 0:38:42,84 Like Apache, MIT. 723 0:38:43,5 --> 0:38:44,0 Michael: Exactly. 724 0:38:44,38 --> 0:38:44,88 Exactly. 725 0:38:45,1 --> 0:38:45,6 And. 726 0:38:46,16 --> 0:38:47,56 Nikolay: Postgres license. 727 0:38:48,06 --> 0:38:48,56 Michael: Yeah. 728 0:38:48,72 --> 0:38:50,44 All of them extremely permissive. 729 0:38:50,5 --> 0:38:52,36 And, And I mean, they're not copy left. 730 0:38:52,36 --> 0:38:53,2 They're not AGPL. 731 0:38:53,2 --> 0:38:58,14 Like they're actively trying to encourage collaboration and allowing 732 0:38:58,14 --> 0:39:3,14 people to use it for commercial purposes is is you 733 0:39:3,14 --> 0:39:7,08 Nikolay: know, common misconception here at GPL and AGPL, they 734 0:39:7,08 --> 0:39:9,86 are more open source than these permissive licenses, right? 735 0:39:9,86 --> 0:39:11,54 But somehow people avoid them. 736 0:39:12,18 --> 0:39:16,16 Because they cannot build commercial cloud things on top of them. 737 0:39:16,5 --> 0:39:18,66 Michael: I'm not trying to get into an argument as to what's 738 0:39:18,66 --> 0:39:22,24 more or less open source, I'm saying that the fact that permissive 739 0:39:22,34 --> 0:39:23,26 I think is, 740 0:39:23,26 --> 0:39:23,68 Nikolay: is... 741 0:39:23,68 --> 0:39:24,64 Freedom, yeah. 742 0:39:25,08 --> 0:39:27,16 Michael: Yeah, and I think it's good for everybody, it's good 743 0:39:27,16 --> 0:39:27,74 for the rest 744 0:39:27,74 --> 0:39:28,14 Nikolay: of us. 745 0:39:28,14 --> 0:39:30,18 Unprotected freedom, this is how you can see it. 746 0:39:30,18 --> 0:39:34,12 Because somebody can clone and create commercial software based 747 0:39:34,12 --> 0:39:35,1 on that, easy. 748 0:39:35,5 --> 0:39:38,0 Michael: Well, and I think it's about betting on the long term. 749 0:39:38,0 --> 0:39:41,2 Like, I think it's about saying commercial things will come and 750 0:39:41,2 --> 0:39:44,24 go, but this will still be here. 751 0:39:44,24 --> 0:39:45,14 Nikolay: It's off topic, 752 0:39:45,14 --> 0:39:45,64 Michael: yes. 753 0:39:45,78 --> 0:39:46,44 I apologize. 754 0:39:46,78 --> 0:39:48,34 Nikolay: I wanted to credit them for that. 755 0:39:48,34 --> 0:39:49,0 Michael: To wrap it up, 756 0:39:49,0 --> 0:39:53,6 Nikolay: I just wanted to mention that Supabase growth is absolutely 757 0:39:54,14 --> 0:39:54,64 crazy. 758 0:39:55,36 --> 0:39:56,46 And why? 759 0:39:56,46 --> 0:40:3,56 Because a lot of tools which are also growing crazy, They basically 760 0:40:4,66 --> 0:40:8,5 bring a lot of development activities even from non-developers, 761 0:40:9,32 --> 0:40:10,38 vibe coding, right? 762 0:40:10,96 --> 0:40:13,62 Many platforms grow, grow, grow. 763 0:40:13,62 --> 0:40:19,06 And Postgres became, it's obvious this year, Postgres is default 764 0:40:19,14 --> 0:40:20,92 database for vibe coding. 765 0:40:21,06 --> 0:40:29,18 This is 100% Like as of end of 2025 it's so and Supabase growth 766 0:40:29,44 --> 0:40:33,54 and Neon mentioning that 80% or something of databases created 767 0:40:33,54 --> 0:40:37,54 are created because of vibe coding and AI agents and so on. 768 0:40:37,54 --> 0:40:38,66 Michael: On Neon yeah. 769 0:40:39,28 --> 0:40:40,44 What about Replit? 770 0:40:40,44 --> 0:40:43,82 I actually didn't finish reading the what did you see the post 771 0:40:43,92 --> 0:40:45,54 that Mike was responding to? 772 0:40:46,1 --> 0:40:47,6 Is that Postgres? 773 0:40:48,56 --> 0:40:52,96 Nikolay: Yeah well yeah it's Postgres yeah so Postgres everywhere. 774 0:40:53,46 --> 0:40:54,26 Michael: Yeah nice. 775 0:40:54,48 --> 0:40:58,38 I would say the thing about Supabase and PlanetScale and people 776 0:40:58,38 --> 0:41:1,4 like that, they're also amazing at marketing and I think that's 777 0:41:1,4 --> 0:41:5,28 underrated in the Postgres ecosystem in terms of being good for 778 0:41:5,28 --> 0:41:5,94 the project. 779 0:41:6,82 --> 0:41:10,12 They've kind of brought some of that energy of early MongoDB 780 0:41:10,38 --> 0:41:13,5 that people are actually excited to use it, developers want to 781 0:41:13,5 --> 0:41:15,54 use it, they think it's an easy thing to do. 782 0:41:15,54 --> 0:41:16,24 You know what I mean? 783 0:41:16,24 --> 0:41:20,28 It's that kind of like, it's cool all of a sudden. 784 0:41:20,28 --> 0:41:24,78 And I don't know if I've been here long enough that to remember 785 0:41:24,78 --> 0:41:27,1 the last time that it was actually cool so 786 0:41:27,1 --> 0:41:31,74 Nikolay: I don't know yeah let's mention friend Pashol who left 787 0:41:32,32 --> 0:41:37,6 Postgres world but he says not fully left also had an episode right 788 0:41:37,82 --> 0:41:41,68 yeah yeah and and joined MongoDB, so that's also interesting. 789 0:41:44,24 --> 0:41:47,22 Last time I used MongoDB was 12 years ago, I don't know. 790 0:41:47,22 --> 0:41:51,72 Last time I listened to them was 2018 in VLDB Los Angeles. 791 0:41:53,04 --> 0:41:55,46 Michael: But if you go back, if you look at startups that are 792 0:41:55,46 --> 0:41:59,06 12 years old, a lot of them will be on Mongo, like, or 11 years 793 0:41:59,06 --> 0:42:0,12 old, 10 years old. 794 0:42:0,12 --> 0:42:3,82 And I think we're going to see this, like, startups that started 795 0:42:3,82 --> 0:42:7,28 now, like last year, this year, next year, a lot of them are 796 0:42:7,28 --> 0:42:9,82 gonna be on Postgres, and I think that's really healthy for the 797 0:42:9,82 --> 0:42:10,32 ecosystem. 798 0:42:11,16 --> 0:42:12,48 Nikolay: Yeah, yeah, yeah. 799 0:42:12,78 --> 0:42:16,98 And also challenging because people don't realize what is it. 800 0:42:17,9 --> 0:42:18,4 Michael: Fair. 801 0:42:18,94 --> 0:42:19,16 Nikolay: What do 802 0:42:19,16 --> 0:42:20,64 Michael: you mean the vibe code is? 803 0:42:20,82 --> 0:42:24,62 Nikolay: Right, so I think there are challenges in the area of 804 0:42:25,2 --> 0:42:26,66 explaining basics. 805 0:42:27,56 --> 0:42:31,1 It's I think demand on understanding like simple basics like 806 0:42:31,86 --> 0:42:34,66 for us vacuum is basic but maybe it's not basics. 807 0:42:35,2 --> 0:42:39,74 Relational things are basics like sometimes I see different platforms 808 0:42:39,8 --> 0:42:43,18 go at different levels there some people like Supabase they 809 0:42:43,18 --> 0:42:46,28 expose whole Postgres you can play with tables and so on. 810 0:42:46,28 --> 0:42:50,04 Some like Gadget, for example, they expose concept of indexes, 811 0:42:50,1 --> 0:42:52,96 but they don't let you to connect to Postgres directly. 812 0:42:52,96 --> 0:42:55,06 So more like vibe side. 813 0:42:55,32 --> 0:42:57,28 So different levels here. 814 0:42:57,74 --> 0:42:58,64 It's so cool. 815 0:42:59,38 --> 0:43:4,02 You can choose how deep you can go, but if you go and you don't 816 0:43:4,02 --> 0:43:8,68 understand, you need, I think, demand for good education of relational 817 0:43:8,68 --> 0:43:12,28 databases and Postgres is growing because of all these activities. 818 0:43:13,26 --> 0:43:16,96 And on 1 hand, on another hand, demand for good maintenance, 819 0:43:17,22 --> 0:43:21,66 operational tools and practices and Methodologies also growing 820 0:43:21,66 --> 0:43:25,12 because imagine how many databases are created now every day 821 0:43:25,16 --> 0:43:25,68 a year ago. 822 0:43:25,68 --> 0:43:31,02 It was much much less right Postgres Like number of databases 823 0:43:31,2 --> 0:43:33,06 is exploding this year. 824 0:43:33,34 --> 0:43:33,84 Literally. 825 0:43:33,9 --> 0:43:34,82 Do you think, but 826 0:43:34,82 --> 0:43:37,32 Michael: don't you think their shelf life is also reducing? 827 0:43:37,36 --> 0:43:37,68 Like, 828 0:43:37,68 --> 0:43:39,68 Nikolay: of course, most of them won't survive. 829 0:43:40,16 --> 0:43:40,66 Yeah. 830 0:43:40,68 --> 0:43:46,08 We're just experimenting, wipe coding, like throwing out later, 831 0:43:46,08 --> 0:43:47,46 but some of them will survive. 832 0:43:48,34 --> 0:43:51,96 They need a path for good health. 833 0:43:52,54 --> 0:43:57,76 That's why I think self-driving is also a new trend which is 834 0:43:57,76 --> 0:44:3,42 going to stay and It's great to have examples of previous attempts 835 0:44:3,82 --> 0:44:6,86 as Oracle Autonomous, we can learn from them. 836 0:44:7,8 --> 0:44:8,36 And others. 837 0:44:8,36 --> 0:44:9,24 Yeah, okay. 838 0:44:9,44 --> 0:44:14,48 We'll definitely discuss this topic not once in future, I'm quite 839 0:44:14,48 --> 0:44:14,98 sure. 840 0:44:15,78 --> 0:44:20,82 Well, again, like trend is obvious trend started here in 2025 841 0:44:22,44 --> 0:44:26,26 Michael: Okay Wait, well, but yeah I think that it would be interesting 842 0:44:26,26 --> 0:44:29,44 to see how important it turns out to be in 2026 My opinion is 843 0:44:29,44 --> 0:44:33,84 actually that the ones that survive can then be given a bit more 844 0:44:33,84 --> 0:44:34,34 attention. 845 0:44:34,4 --> 0:44:38,48 So like, it's gonna be not that, I think it's still difficult 846 0:44:38,48 --> 0:44:42,04 to get a business up and running and to a huge scale. 847 0:44:42,04 --> 0:44:44,8 The ones that do it are still incredible and they're still not 848 0:44:44,8 --> 0:44:45,48 that many. 849 0:44:45,48 --> 0:44:48,74 I don't see that there's gonna be tens of thousands more of those 850 0:44:48,74 --> 0:44:53,0 really successful huge companies But they might get there quicker 851 0:44:53,0 --> 0:44:56,0 and with fewer technical resources in the beginning So they'll 852 0:44:56,0 --> 0:44:58,94 need support for sure But I don't see the argument that there's 853 0:44:58,94 --> 0:45:1,26 going to be a board of magnitude more them. 854 0:45:1,28 --> 0:45:2,98 Nikolay: My team feels it really well. 855 0:45:3,56 --> 0:45:8,94 Regular, imagine enterprises, regular startups, they are different, 856 0:45:8,94 --> 0:45:9,44 right? 857 0:45:9,94 --> 0:45:13,88 And there is new breed AI startups. 858 0:45:14,2 --> 0:45:15,88 These guys move really fast. 859 0:45:16,5 --> 0:45:18,74 They like database expertise even more. 860 0:45:19,02 --> 0:45:22,94 They are very often very smart, but they are different from regular 861 0:45:22,94 --> 0:45:26,76 startups and I feel it just from perspective how we how like 862 0:45:26,76 --> 0:45:28,52 work with databases organized. 863 0:45:28,9 --> 0:45:32,42 So this trend will only grow in the future, it started this year 864 0:45:32,42 --> 0:45:37,54 I think, We noticed it this year, but it will not disappear. 865 0:45:37,54 --> 0:45:39,1 I think this is something new. 866 0:45:39,38 --> 0:45:42,34 Michael: And you don't think they'll hire, like, you think they 867 0:45:42,34 --> 0:45:45,54 won't hire for those, like, specialties once they grow? 868 0:45:46,1 --> 0:45:48,42 Nikolay: I think they will, but they move so fast. 869 0:45:49,9 --> 0:45:53,0 You can hire but then what like it's too late. 870 0:45:53,24 --> 0:45:57,9 Like you mentioned this case about partitioning right with regular 871 0:45:57,9 --> 0:46:1,28 methods this new hire with absolutely great knowledge will come 872 0:46:1,28 --> 0:46:2,72 but it will be too late. 873 0:46:3,1 --> 0:46:5,22 It already should be done a year ago. 874 0:46:6,02 --> 0:46:7,36 Michael: But it's not too late. 875 0:46:9,24 --> 0:46:12,84 Success generally brings enough money to solve these problems. 876 0:46:13,38 --> 0:46:16,04 Like hire a good consultancy to help out. 877 0:46:16,48 --> 0:46:17,2 Nikolay: I'm not joking. 878 0:46:17,2 --> 0:46:20,1 I heard let's migrate to a different database system maybe. 879 0:46:20,98 --> 0:46:23,32 Michael: Okay, so you think for Postgres is survival? 880 0:46:23,32 --> 0:46:24,12 Nikolay: It's a challenge. 881 0:46:24,14 --> 0:46:24,64 Yeah, yeah. 882 0:46:24,64 --> 0:46:30,56 So like, if database cannot scale without like, too much attention 883 0:46:30,6 --> 0:46:35,42 and too much manual work, it won't survive its hyper growth. 884 0:46:35,82 --> 0:46:38,2 We had this term hyper scalers. 885 0:46:38,44 --> 0:46:43,04 AI is going to bring new level of hyper scaling. 886 0:46:44,12 --> 0:46:46,02 So we need to adjust. 887 0:46:46,62 --> 0:46:47,68 Thank you so much. 888 0:46:47,9 --> 0:46:54,04 Let's keep, let's say happy Christmas, happy new year to everyone. 889 0:46:54,96 --> 0:47:0,06 And let's continue new year with all these trends and good Postgres 890 0:47:0,06 --> 0:47:3,36 health, good Postgres tools, good open source. 891 0:47:3,82 --> 0:47:9,16 It's great to be in this ecosystem and this community in broader 892 0:47:9,16 --> 0:47:9,66 meaning. 893 0:47:10,44 --> 0:47:14,28 And I really enjoy making this podcast with you, Michael, and 894 0:47:14,28 --> 0:47:17,5 also happy new year and Merry Christmas. 895 0:47:18,18 --> 0:47:19,26 Michael: Absolutely, likewise. 896 0:47:19,48 --> 0:47:20,24 Thank you everybody. 897 0:47:20,24 --> 0:47:21,1 Thank you Nik.