1 00:00:00,060 --> 00:00:02,360 Michael: Hello and welcome to Postgres.FM, a weekly show about 2 00:00:02,360 --> 00:00:03,420 all things PostgreSQL. 3 00:00:03,420 --> 00:00:05,860 I am Michael, founder of pgMustard, and as usual, I'm joined 4 00:00:05,860 --> 00:00:07,680 by Nikolay, founder of Postgres.AI. 5 00:00:07,680 --> 00:00:08,420 Hey, Nikolay. 6 00:00:08,940 --> 00:00:09,740 Nikolay: Hi, Michael. 7 00:00:10,440 --> 00:00:13,940 Michael: And we have a special guest today, Franck Pachot, who 8 00:00:13,940 --> 00:00:18,100 is a developer advocate now at MongoDB, formerly at YugabyteDB, 9 00:00:18,480 --> 00:00:21,980 which is a distributed PostgreSQL database, also an AWS Data 10 00:00:21,980 --> 00:00:24,400 Hero, and Oracle Certified Master. 11 00:00:24,960 --> 00:00:26,540 So, welcome, Franck. 12 00:00:27,100 --> 00:00:27,600 Franck: Hi. 13 00:00:28,260 --> 00:00:28,760 Thanks. 14 00:00:28,940 --> 00:00:30,140 Thanks for having me there. 15 00:00:30,580 --> 00:00:32,560 Nikolay: And former Postgres blogger. 16 00:00:33,520 --> 00:00:34,020 Franck: Yeah. 17 00:00:34,460 --> 00:00:34,960 Nikolay: No? 18 00:00:34,980 --> 00:00:35,740 Or yes? 19 00:00:36,300 --> 00:00:37,120 Franck: Oh, yeah, yeah. 20 00:00:37,120 --> 00:00:40,760 I will continue to blog about all databases, it's just that it 21 00:00:40,760 --> 00:00:42,540 depends on the time I have. 22 00:00:42,700 --> 00:00:43,260 Nikolay: Sounds good. 23 00:00:43,260 --> 00:00:48,400 So I saw you are going to give a talk at some Postgres conference 24 00:00:48,400 --> 00:00:49,440 in India, right? 25 00:00:49,440 --> 00:00:51,400 PGConf India, I don't remember the name. 26 00:00:51,760 --> 00:00:53,660 So still planning to do it, right? 27 00:00:54,340 --> 00:00:54,840 Franck: Yeah. 28 00:00:55,080 --> 00:00:56,460 And also Germany. 29 00:00:56,580 --> 00:00:58,120 I just got the acceptance. 30 00:01:00,900 --> 00:01:01,820 Nikolay: I'm very curious. 31 00:01:02,600 --> 00:01:07,680 During daytime, you work using JSONs and these weird queries, 32 00:01:09,140 --> 00:01:10,620 right, chains of something. 33 00:01:11,420 --> 00:01:15,980 And then at weekend or something you present SQL talks. 34 00:01:16,120 --> 00:01:19,400 How is it going to be played in your mind? 35 00:01:19,400 --> 00:01:20,360 I'm very curious. 36 00:01:22,360 --> 00:01:24,180 Franck: It's all about databases. 37 00:01:24,680 --> 00:01:26,820 I mean, it's all the same. 38 00:01:27,700 --> 00:01:28,600 Nikolay: All the same. 39 00:01:29,640 --> 00:01:33,860 Franck: Yeah, you can do data modeling, document data modeling 40 00:01:33,860 --> 00:01:34,540 on Postgres. 41 00:01:34,560 --> 00:01:35,740 You can do it on Oracle. 42 00:01:35,740 --> 00:01:37,320 You can do it on MongoDB. 43 00:01:37,580 --> 00:01:43,840 You can normalize your data on SQL databases, on NoSQL databases. 44 00:01:44,440 --> 00:01:46,380 The concepts are all the same. 45 00:01:46,380 --> 00:01:51,020 Of course, there are little differences, like how NULLs are undulied, 46 00:01:51,020 --> 00:01:54,920 for example, or how you join or you don't join, but yeah. 47 00:01:54,920 --> 00:01:56,080 Nikolay: NULLs, let's postpone. 48 00:01:56,140 --> 00:01:57,340 It's a special topic. 49 00:01:57,340 --> 00:01:58,820 It's not for the start. 50 00:01:59,480 --> 00:01:59,980 Okay. 51 00:02:00,160 --> 00:02:06,240 I remember a series of blog posts from Michael Stonebraker about 52 00:02:06,600 --> 00:02:11,120 criticizing document databases for lack of normalization and 53 00:02:11,120 --> 00:02:11,820 so on. 54 00:02:12,010 --> 00:02:17,000 So you are saying now that it's totally possible to apply normalization 55 00:02:17,160 --> 00:02:18,560 in document database. 56 00:02:19,340 --> 00:02:20,900 Is this what you're trying to say? 57 00:02:20,900 --> 00:02:22,700 Or maybe I'm getting wrong. 58 00:02:24,840 --> 00:02:30,100 Franck: I've also changed my mind probably because for 2 reasons. 59 00:02:30,100 --> 00:02:32,360 First, the applications have changed. 60 00:02:32,860 --> 00:02:39,040 I think the normalized model was really good for those monolithic 61 00:02:39,220 --> 00:02:44,420 databases where all use cases with the enterprise information 62 00:02:44,600 --> 00:02:48,340 system in 1 database running all use cases. 63 00:02:48,440 --> 00:02:53,940 And then you need a normalized way to structure the data that 64 00:02:53,940 --> 00:02:57,540 is shared by the whole company and all kinds of users. 65 00:02:58,500 --> 00:03:00,120 Today, it's a bit different. 66 00:03:00,340 --> 00:03:02,940 You have multiple services, multiple microservices. 67 00:03:03,220 --> 00:03:05,640 They might have different databases. 68 00:03:06,780 --> 00:03:10,740 And then the concern of normalization may be different. 69 00:03:10,740 --> 00:03:15,540 For example, if you consume data only to read it and not update 70 00:03:15,580 --> 00:03:17,940 it, you can denormalize a bit more. 71 00:03:17,960 --> 00:03:22,500 So that's 1 reason and I think the main reason is also the applications 72 00:03:22,700 --> 00:03:23,740 have changed. 73 00:03:24,360 --> 00:03:30,660 Today in application programming languages you use documents 74 00:03:31,020 --> 00:03:37,400 in nested structure, objects, object graphs, looks like more 75 00:03:37,840 --> 00:03:42,460 like documents so it's easier to move it to applications. 76 00:03:43,620 --> 00:03:47,360 Nikolay: I don't get it because we had documents for forever. 77 00:03:47,620 --> 00:03:53,700 For example, Codd designed relational model originally dealing 78 00:03:53,700 --> 00:03:55,320 with banking systems, right? 79 00:03:56,780 --> 00:04:02,760 In 60s, 70s, and it was not convenient to have nesting at that 80 00:04:02,760 --> 00:04:03,260 point. 81 00:04:03,820 --> 00:04:08,040 Before rational model, we know there were what's the name like 82 00:04:08,240 --> 00:04:13,660 net and I forgot names, but basically closer to... 83 00:04:14,280 --> 00:04:17,000 Franck: Hierarchical models and network models. 84 00:04:17,220 --> 00:04:18,160 Nikolay: Yeah, yeah, yeah, exactly. 85 00:04:18,820 --> 00:04:25,740 And the idea was it's really inconvenient when we keep a document 86 00:04:25,960 --> 00:04:31,160 as a whole and we need to split it into pieces and basically 87 00:04:31,160 --> 00:04:32,360 divide and conquer, right? 88 00:04:32,360 --> 00:04:36,160 We split into pieces and that's how we get flexibility and start 89 00:04:36,160 --> 00:04:36,660 working. 90 00:04:36,900 --> 00:04:40,640 And we had documents at that time as well, like invoices or transactions 91 00:04:42,740 --> 00:04:45,080 like between financial institutions and so on. 92 00:04:45,440 --> 00:04:50,360 So I don't see the big change, just amount of data and so on, 93 00:04:50,360 --> 00:04:50,820 right? 94 00:04:50,820 --> 00:04:55,580 And I don't fully understand why the idea of microservices or 95 00:04:55,580 --> 00:05:00,320 something you, as I understand, you are bringing, like when we 96 00:05:00,320 --> 00:05:02,540 have many, many databases, many services. 97 00:05:02,900 --> 00:05:04,640 Why is it changing this? 98 00:05:04,640 --> 00:05:06,860 Because in my head, it's vice versa. 99 00:05:06,860 --> 00:05:13,440 If we have many services, we do need to structure and split into 100 00:05:14,380 --> 00:05:17,620 more atomic pieces of our data, right? 101 00:05:17,620 --> 00:05:22,320 And the article I mentioned, it's called "Schema Later Considered 102 00:05:22,340 --> 00:05:22,840 Harmful." 103 00:05:24,840 --> 00:05:29,400 After my post, actually, this is why I named my sub-transactions 104 00:05:29,760 --> 00:05:32,380 blog post also considered harmful. 105 00:05:33,080 --> 00:05:38,720 And some folks mentioned on Hacker News mentioned that there 106 00:05:38,720 --> 00:05:42,420 is an article considered harmful, considered harmful, harmful, 107 00:05:43,280 --> 00:05:45,320 considered harmful titles considered harmful. 108 00:05:45,360 --> 00:05:48,940 So it's basically like not a good way to name articles, but the 109 00:05:48,940 --> 00:05:50,280 blog post is quite good. 110 00:05:50,280 --> 00:05:55,840 Like if schema design, normalization still makes sense. 111 00:05:55,840 --> 00:05:59,180 If you don't do it, you deal with bad consequences later. 112 00:05:59,700 --> 00:06:00,860 So please let 113 00:06:00,860 --> 00:06:01,400 Franck: me understand. 114 00:06:01,400 --> 00:06:03,740 Yeah, but it depends on your use case. 115 00:06:04,020 --> 00:06:09,180 And also something I've been working on relational databases 116 00:06:09,300 --> 00:06:14,360 where you normalized, but basically, when I learned databases 117 00:06:14,680 --> 00:06:17,280 at university, it was all about normalization. 118 00:06:17,720 --> 00:06:21,620 And then when you start to work, you hear people talking about 119 00:06:21,620 --> 00:06:23,320 denormalizing everything. 120 00:06:24,120 --> 00:06:29,240 And of course, you just need to think about the access patterns. 121 00:06:29,800 --> 00:06:31,580 Nikolay: Yeah, Let me just add this. 122 00:06:31,640 --> 00:06:34,900 Sorry for interrupting, but let me just add, I totally agree. 123 00:06:34,900 --> 00:06:38,680 If we over-normalize, then we deal with very simple fact that 124 00:06:38,680 --> 00:06:40,980 you cannot create 1 index on 2 tables. 125 00:06:44,500 --> 00:06:47,960 You won't, Because, for example, filtering on 1 table, filtering 126 00:06:47,960 --> 00:06:50,420 on another table, you want a single index scan. 127 00:06:50,640 --> 00:06:54,780 Definitely, this is what we do also. 128 00:06:54,920 --> 00:06:59,160 My team and I, we do, during consulting practice, we say, okay, 129 00:06:59,160 --> 00:07:01,080 here we do need to normalize. 130 00:07:02,320 --> 00:07:07,120 But my point is, if you take Mongo and other document databases, 131 00:07:07,900 --> 00:07:10,740 they just provoke you to avoid normalization at all. 132 00:07:10,920 --> 00:07:13,340 In relational data systems, we can... 133 00:07:13,440 --> 00:07:14,340 Is it OK? 134 00:07:14,340 --> 00:07:15,140 Am I wrong? 135 00:07:16,120 --> 00:07:19,800 Franck: Yeah, for me, you are wrong. 136 00:07:20,860 --> 00:07:26,040 And I think that's also 1 reason MongoDB was interested to have 137 00:07:26,040 --> 00:07:30,980 a developer advocate coming from SQL databases, is that users 138 00:07:31,360 --> 00:07:36,300 tend to think that they have to denormalize everything and to 139 00:07:36,300 --> 00:07:39,260 put everything in 1 document, which is wrong. 140 00:07:40,120 --> 00:07:46,780 The idea in MongoDB is to put together what you insert together 141 00:07:46,800 --> 00:07:53,040 or what you query together, but in different documents if you 142 00:07:53,040 --> 00:07:54,180 query differently. 143 00:07:55,080 --> 00:08:00,300 Just to take an example, another entry system, you don't want 144 00:08:00,300 --> 00:08:03,540 to put together the customers and the orders because you don't 145 00:08:03,540 --> 00:08:09,400 want 1 document per customer where you just add orders that can 146 00:08:09,400 --> 00:08:11,540 be a lot every year. 147 00:08:11,600 --> 00:08:16,500 But the orders themselves, the orders and the other items which 148 00:08:16,500 --> 00:08:21,440 we usually put in 2 tables in SQL databases just because they 149 00:08:21,440 --> 00:08:22,780 have different cardinalities. 150 00:08:23,860 --> 00:08:27,780 That's something you can put in a single document, because you 151 00:08:27,780 --> 00:08:30,520 insert an order with all the items. 152 00:08:30,860 --> 00:08:34,680 You have nobody who will just update 1 item of the order and 153 00:08:34,680 --> 00:08:36,100 you query them together. 154 00:08:36,780 --> 00:08:38,360 Of course, it depends on the system. 155 00:08:38,360 --> 00:08:45,200 If you're in a system that analyzes the order lines for marketing 156 00:08:45,220 --> 00:08:49,060 purpose, buy the product and you don't care about the customer 157 00:08:49,060 --> 00:08:51,780 or the other, then maybe the modeling is different. 158 00:08:51,780 --> 00:08:54,180 And this is where different use cases are. 159 00:08:54,520 --> 00:08:58,280 But it's not about putting everything in 1 document. 160 00:08:59,440 --> 00:09:03,940 And that's also why it's good to do some design reviews? 161 00:09:04,120 --> 00:09:07,440 Because it's easy for a developer to start and put everything 162 00:09:07,440 --> 00:09:12,260 in 1 document, just moving what they have in Java to the database, 163 00:09:12,400 --> 00:09:16,280 but still needs design and still need to think about what you 164 00:09:16,280 --> 00:09:21,440 embed, like denormalize, or what you reference, like you would 165 00:09:21,440 --> 00:09:24,060 reference with foreign keys in a secure database? 166 00:09:25,440 --> 00:09:26,400 Nikolay: OK, I hear you. 167 00:09:26,400 --> 00:09:27,940 I think I understand you. 168 00:09:28,620 --> 00:09:33,660 But still, You say users have this tendency to think. 169 00:09:34,020 --> 00:09:39,900 For example, user Michael Stonebraker says that he noticed that 170 00:09:40,680 --> 00:09:45,100 maybe it's possible to normalize, of course, but in relational 171 00:09:45,140 --> 00:09:49,360 databases there is a big tendency to normalize first and then 172 00:09:49,360 --> 00:09:51,100 denormalize when needed. 173 00:09:52,160 --> 00:09:56,180 In document store databases, there is the opposite tendency. 174 00:09:56,980 --> 00:10:00,520 Avoid normalization first and then normalize when we have pain. 175 00:10:01,400 --> 00:10:04,640 The whole article called "Schema Later Considered Harmful." 176 00:10:04,640 --> 00:10:10,360 I think, as I understand this article, it's about that the relational 177 00:10:10,520 --> 00:10:15,360 approach, direction of movement is more beneficial in general 178 00:10:15,360 --> 00:10:17,040 case than opposite. 179 00:10:17,040 --> 00:10:17,980 What do you think? 180 00:10:19,060 --> 00:10:24,960 Franck: Yeah, but remember that relational databases were made 181 00:10:24,960 --> 00:10:29,340 at a time where we were designing the data before looking at 182 00:10:29,340 --> 00:10:30,260 the use cases. 183 00:10:31,160 --> 00:10:36,020 The normalization and the data model doesn't care about the use 184 00:10:36,020 --> 00:10:36,520 cases. 185 00:10:37,340 --> 00:10:39,060 You just model the data. 186 00:10:39,200 --> 00:10:44,440 You have orders, multiple order items, an order belongs to a 187 00:10:44,440 --> 00:10:44,940 customer. 188 00:10:45,400 --> 00:10:50,320 You do a static model of your data, and then you bring the application 189 00:10:50,440 --> 00:10:55,760 use cases, and you can optimize them with indexes, but you don't 190 00:10:55,760 --> 00:10:58,120 change the data model for the use cases. 191 00:10:58,780 --> 00:11:03,840 But this is not really how applications are developed today. 192 00:11:04,460 --> 00:11:10,080 Today, applications come with a main use case and rent fast access 193 00:11:10,080 --> 00:11:11,300 for this use case. 194 00:11:11,820 --> 00:11:15,680 For another use case, they just check if they can do it on the 195 00:11:15,680 --> 00:11:19,940 same database, or maybe do some event streaming, put that in 196 00:11:19,940 --> 00:11:21,860 another database and doing elsewhere. 197 00:11:23,000 --> 00:11:24,260 That really has changed. 198 00:11:24,720 --> 00:11:31,040 Today, even applications that run on SQL databases, I see people 199 00:11:31,640 --> 00:11:35,580 starting a data model, knowing the access patterns. 200 00:11:38,040 --> 00:11:39,740 And then maybe you can denormalize. 201 00:11:40,120 --> 00:11:43,740 For example, it's okay to denormalize something that is not updated. 202 00:11:45,060 --> 00:11:49,200 The big danger to denormalize something that may be updated is 203 00:11:49,200 --> 00:11:53,940 that you have to update in multiple places, which is a risk of 204 00:11:53,940 --> 00:11:57,900 inconsistency if you forget 1, and which is also a performance 205 00:11:58,040 --> 00:12:01,080 issue, especially when you distribute, then you have distributed 206 00:12:01,160 --> 00:12:03,020 transactions at multiple places. 207 00:12:03,620 --> 00:12:09,020 But data that you do not update, and there is a lot of data that 208 00:12:09,020 --> 00:12:11,760 we don't update, we just add a new version of it. 209 00:12:11,760 --> 00:12:17,420 For example, a customer is creating a new order, you will not 210 00:12:17,420 --> 00:12:18,500 update the order. 211 00:12:18,820 --> 00:12:24,380 If we add a new item, that will be a new order, but the existing 212 00:12:24,380 --> 00:12:26,020 order has been validated. 213 00:12:26,180 --> 00:12:28,780 You don't update this data later. 214 00:12:29,240 --> 00:12:32,860 Usually you have a timestamp, And even if you change something, 215 00:12:32,860 --> 00:12:34,540 then you just add the new version. 216 00:12:34,540 --> 00:12:36,940 So the applications have changed. 217 00:12:36,940 --> 00:12:39,740 And I'm not saying that 1 is better than the other. 218 00:12:39,740 --> 00:12:44,980 But when we listen to the developers, we see that they don't 219 00:12:44,980 --> 00:12:49,020 want to build this ERD diagram. 220 00:12:50,220 --> 00:12:51,340 That was never true. 221 00:12:51,340 --> 00:12:52,580 So that's also something. 222 00:12:53,040 --> 00:12:56,060 Nikolay: Nobody does that anymore, building ERD diagrams. 223 00:12:56,400 --> 00:13:01,480 Or only our AI system does, but it's just a side function for 224 00:13:01,480 --> 00:13:01,980 it. 225 00:13:02,140 --> 00:13:06,220 But I don't understand why we cannot do it on relational databases 226 00:13:06,340 --> 00:13:08,080 and still have all the good stuff. 227 00:13:08,080 --> 00:13:13,400 Because we have JSON, let's just put it there and so on. 228 00:13:14,680 --> 00:13:18,240 Franck: And It's very good to mix both. 229 00:13:18,240 --> 00:13:22,620 I've seen a lot of applications on Oracle, on Postgres, on Yugabyte, 230 00:13:23,680 --> 00:13:29,040 where it's a mix where you have tables with Columns because they 231 00:13:29,040 --> 00:13:33,420 are updated because you went indexes on it, and you have a bunch 232 00:13:33,420 --> 00:13:37,040 of metadata information that you put in a JSON. 233 00:13:37,540 --> 00:13:39,560 And that's also perfectly valid. 234 00:13:40,120 --> 00:13:45,220 Nikolay: And so what does Mongo bring here, if we have it already? 235 00:13:46,080 --> 00:13:48,900 Franck: I think the API is very different. 236 00:13:49,440 --> 00:13:50,140 Nikolay: Of course. 237 00:13:50,500 --> 00:13:51,000 Franck: Yeah. 238 00:13:51,260 --> 00:13:53,260 With MongoDB, you can really... 239 00:13:54,560 --> 00:13:56,880 You have your object graph in the application. 240 00:13:57,340 --> 00:14:01,100 In JavaScript, it's even easier, but in Java, in whatever, in 241 00:14:01,100 --> 00:14:05,460 Python, and you just communicate with the Database those documents 242 00:14:05,600 --> 00:14:07,880 and they are stored as documents. 243 00:14:09,180 --> 00:14:13,020 The big problem with SQL databases or so something that has changed 244 00:14:13,420 --> 00:14:17,960 when Application have changed at the time where everything was 245 00:14:17,960 --> 00:14:23,860 done in the Database, stored procedures or pre-compiled procedures 246 00:14:24,060 --> 00:14:26,500 or whatever, then that was okay. 247 00:14:26,820 --> 00:14:32,300 But with object-oriented programming, you had this mismatch and 248 00:14:32,300 --> 00:14:36,940 you need an object-relational mapping to map from 1 to the other 249 00:14:36,940 --> 00:14:44,240 if you don't want to do a bunch of queries in text strings and 250 00:14:44,240 --> 00:14:45,220 through JDBC. 251 00:14:46,160 --> 00:14:54,140 So, what MongoDB brings at that point is an API that really fits 252 00:14:54,520 --> 00:14:58,340 with the programming language and then it stores it as documents 253 00:14:58,940 --> 00:15:02,260 rather than mapping that to relational tables. 254 00:15:02,860 --> 00:15:06,740 Nikolay: Yes, this is what HDB and HQL are trying to solve. 255 00:15:06,740 --> 00:15:12,600 They try to reinvent SQL to have this, what you describe. 256 00:15:13,180 --> 00:15:18,720 Yeah, but you mentioned OOP and ER. 257 00:15:19,020 --> 00:15:22,320 I think this is in the past already, both. 258 00:15:22,440 --> 00:15:24,660 No, I'm joking, I'm joking. 259 00:15:25,600 --> 00:15:26,140 So for me 260 00:15:26,140 --> 00:15:26,600 Franck: it's like... 261 00:15:26,600 --> 00:15:29,240 Then what do you use today if you... 262 00:15:30,060 --> 00:15:32,820 I mean, applications are built with objects? 263 00:15:33,700 --> 00:15:38,520 Nikolay: Well, I personally am a big fan of things what guys 264 00:15:38,520 --> 00:15:45,560 like Hasura, Supabase, others do with thin layer providing APIs 265 00:15:46,080 --> 00:15:50,040 right away without the need to write this middleware. 266 00:15:51,600 --> 00:15:55,520 It's great, this serves better than object-relational mapping. 267 00:15:55,520 --> 00:15:58,440 But people do object-relational mapping, but at the same time, 268 00:15:58,440 --> 00:16:03,840 I doubt a lot of guys who create projects, they do actual OOP 269 00:16:03,840 --> 00:16:05,440 with patterns and so on. 270 00:16:05,560 --> 00:16:08,800 It's kind of like somehow not cool anymore. 271 00:16:08,940 --> 00:16:09,840 It's my perception. 272 00:16:11,240 --> 00:16:14,200 I'm far from actual application programming lately. 273 00:16:14,200 --> 00:16:18,000 Franck: But it's also this old debate where do you put your business 274 00:16:18,060 --> 00:16:18,560 logic? 275 00:16:19,540 --> 00:16:23,680 Ideally in a SQL database, you put it in the database because 276 00:16:23,680 --> 00:16:27,320 data is processed there, but then you are constrained to specific 277 00:16:27,440 --> 00:16:27,940 languages. 278 00:16:29,100 --> 00:16:30,160 Nikolay: Well, right. 279 00:16:30,480 --> 00:16:37,360 But if you put it to application, you also have dependency on 280 00:16:37,360 --> 00:16:38,900 this language you chose. 281 00:16:38,900 --> 00:16:39,820 It's the same. 282 00:16:41,180 --> 00:16:47,920 To me, the question about where to put logic became much easier 283 00:16:47,920 --> 00:16:52,900 to understand since like 10 years ago when Angular and React, 284 00:16:52,900 --> 00:16:57,980 they obtained, gained popularity and a lot of logic and actually 285 00:16:57,980 --> 00:17:01,080 Web 2.0, how many years ago already? 286 00:17:01,080 --> 00:17:02,780 Like 20 years ago, right? 287 00:17:02,920 --> 00:17:06,840 All these shifted a lot of client-oriented logic to clients, 288 00:17:07,060 --> 00:17:08,500 to front-end, right? 289 00:17:08,760 --> 00:17:13,700 And this gave space to have logic closer to data, like constraints 290 00:17:14,060 --> 00:17:18,680 and what we usually do with triggers, some dependencies, propagation 291 00:17:18,820 --> 00:17:20,040 of changes or something. 292 00:17:20,860 --> 00:17:23,360 It gives opportunity to keep it in database where it should be 293 00:17:23,360 --> 00:17:27,260 because otherwise, if you don't do it closer to database, at 294 00:17:27,260 --> 00:17:31,420 some point when company grows, project grows, you add some other 295 00:17:32,120 --> 00:17:37,800 tools or application layers or something called, and you need 296 00:17:37,800 --> 00:17:40,780 to re-implement the same logic in different places. 297 00:17:41,140 --> 00:17:43,860 And there is no strong guarantee that it will be well maintained. 298 00:17:43,860 --> 00:17:44,620 Yeah, but the 299 00:17:44,620 --> 00:17:49,080 Franck: problem is just, I totally agree, and there are very 300 00:17:49,080 --> 00:17:52,860 successful database-centric applications. 301 00:17:54,060 --> 00:17:59,560 But what developers want, they want to use Java, not PL/pgSQL 302 00:18:00,060 --> 00:18:01,100 and not PL/SQL. 303 00:18:02,280 --> 00:18:08,460 And just because try to hire a SQL developer or a PL/pgSQL developer, 304 00:18:08,680 --> 00:18:12,600 that will be more difficult than hiring a team of Java developers. 305 00:18:13,620 --> 00:18:14,120 Nikolay: Right. 306 00:18:14,440 --> 00:18:14,940 Right. 307 00:18:15,300 --> 00:18:16,900 Michael wanted to ask something. 308 00:18:17,720 --> 00:18:20,280 Michael: I don't know if this is a change of topic, but I think 309 00:18:20,280 --> 00:18:23,600 it's on the same path, which is around developer experience. 310 00:18:23,600 --> 00:18:27,800 And I know it's a subjective term, but I do think when, at least 311 00:18:27,800 --> 00:18:30,320 when Mongo went into the market, but I think NoSQL databases 312 00:18:30,320 --> 00:18:32,480 in general, they promised a few things. 313 00:18:32,480 --> 00:18:35,660 1 was a really good getting started experience, a very quick, 314 00:18:35,760 --> 00:18:40,120 easy, you don't have to think much type, no schema to worry about, 315 00:18:40,380 --> 00:18:41,540 and just get started. 316 00:18:41,660 --> 00:18:44,840 And that's good for some things and not so good in other ways. 317 00:18:45,040 --> 00:18:46,880 But it also promised a couple of other things. 318 00:18:46,880 --> 00:18:50,860 And I think we can learn a lot from these things in terms of 319 00:18:50,860 --> 00:18:51,980 why was it popular? 320 00:18:52,060 --> 00:18:54,240 Like, why did Mongo take off? 321 00:18:54,240 --> 00:18:56,740 Why was NoSQL so popular for so long? 322 00:18:56,980 --> 00:19:01,580 It also promised kind of infinite, or at least horizontal scalability. 323 00:19:01,960 --> 00:19:04,200 And that's something we've historically struggled with. 324 00:19:04,200 --> 00:19:07,600 I know you worked on distributed SQL, but it's something we've 325 00:19:07,600 --> 00:19:10,500 historically struggled with in the SQL world. 326 00:19:10,680 --> 00:19:14,700 And then, yeah, I think that combination of things seemed really 327 00:19:14,700 --> 00:19:15,480 interesting to me. 328 00:19:15,480 --> 00:19:20,020 And I wondered if you had opinions on what is it about that developer 329 00:19:20,020 --> 00:19:22,280 experience that really resonated with people? 330 00:19:23,440 --> 00:19:27,080 Franck: For me, that's really developer experience where MongoDB 331 00:19:28,080 --> 00:19:30,560 is really, was really successful. 332 00:19:31,580 --> 00:19:35,720 The scalability, I don't really know because I didn't use MongoDB 333 00:19:35,820 --> 00:19:40,700 at that time, and then I've seen scalability in SQL databases. 334 00:19:41,120 --> 00:19:45,140 The scalability comes from the data model where you can have 335 00:19:45,140 --> 00:19:46,660 an easy sharding key. 336 00:19:46,700 --> 00:19:47,200 Yeah. 337 00:19:47,300 --> 00:19:51,140 As soon as you have an easy sharding key, you can distribute 338 00:19:51,200 --> 00:19:54,660 that on mostly all databases today. 339 00:19:54,960 --> 00:19:59,440 On Postgres, you have multiple options like Citus, like Aurora, 340 00:19:59,760 --> 00:20:02,700 Limitless, where If you have a sharding key, you can distribute. 341 00:20:03,080 --> 00:20:05,080 I don't think it's really the point today. 342 00:20:05,080 --> 00:20:07,300 The point is really develop your experience. 343 00:20:07,300 --> 00:20:13,620 As you say, it's easy to start and it's easy to integrate to 344 00:20:13,620 --> 00:20:15,320 your programming language also. 345 00:20:15,320 --> 00:20:20,860 Not having something else to learn, a different language, but 346 00:20:20,860 --> 00:20:25,160 also a different behavior, thinking about what you need to look, 347 00:20:25,160 --> 00:20:30,380 thinking about foreign keys, thinking about performance when 348 00:20:30,380 --> 00:20:32,860 you read from multiple tables. 349 00:20:33,400 --> 00:20:37,800 But it's also, the easy to start is also a problem. 350 00:20:37,800 --> 00:20:42,860 And basically I'm working in the DevRel team where most of the 351 00:20:42,860 --> 00:20:49,640 job is helping users, developers to do some proper data modeling 352 00:20:49,640 --> 00:20:50,140 design. 353 00:20:50,940 --> 00:20:53,860 Because it's easy to start, which is good when you start a proof 354 00:20:53,860 --> 00:20:58,080 of concept, but at some point like in any database, you need 355 00:20:58,080 --> 00:20:59,120 to do some design. 356 00:20:59,440 --> 00:21:03,840 And the more easy it is to start, the more difficult it is to 357 00:21:03,840 --> 00:21:07,120 realize that, okay, we are not in a proof of concept anymore, 358 00:21:07,120 --> 00:21:08,500 we'll put that in production. 359 00:21:08,740 --> 00:21:12,020 It's an application that will evolve in the coming years. 360 00:21:12,040 --> 00:21:14,160 And then we need to look at the design. 361 00:21:14,160 --> 00:21:20,140 And this is one of the major activity in the DevRel team. 362 00:21:20,420 --> 00:21:24,440 It's not like being developer advocate for Yugabyte was really 363 00:21:24,440 --> 00:21:27,740 about awareness because it's a new database, so you just need 364 00:21:28,140 --> 00:21:29,540 to let people know it. 365 00:21:29,540 --> 00:21:31,620 MongoDB, people know it. 366 00:21:31,640 --> 00:21:36,760 You just need to make them successful with maybe a bit more complex 367 00:21:36,780 --> 00:21:39,940 use cases and do some data modeling. 368 00:21:41,500 --> 00:21:46,320 Nikolay: So I have a question about how your personal experience 369 00:21:46,640 --> 00:21:49,300 and this decision you made, obviously, recently. 370 00:21:50,500 --> 00:21:54,660 It feels like you switched teams, like in soccer or football. 371 00:21:55,960 --> 00:21:56,460 Right? 372 00:21:56,980 --> 00:22:03,700 So my question was, any, like, transfer cost? 373 00:22:04,660 --> 00:22:07,440 Franck: Ah, that's a very good question. 374 00:22:07,580 --> 00:22:09,740 So let me explain how it was. 375 00:22:10,200 --> 00:22:15,280 I was really happy at Yugabyte, about the team, about the colleagues, 376 00:22:15,280 --> 00:22:16,240 about the product. 377 00:22:16,440 --> 00:22:19,180 I was really not looking for another job. 378 00:22:19,300 --> 00:22:22,860 And when other companies contacted me, I was like, oh, sorry, 379 00:22:22,960 --> 00:22:24,520 I'm happy where I am. 380 00:22:24,640 --> 00:22:29,180 And when MongoDB contacted me, it was more by curiosity, like 381 00:22:29,240 --> 00:22:33,980 why an SQL databases is interested by my experience. 382 00:22:34,940 --> 00:22:38,600 And this is why I started discussions by curiosity. 383 00:22:39,340 --> 00:22:43,920 And then this is where I realized that it was really an interesting 384 00:22:43,940 --> 00:22:48,800 approach that's helping users on document databases with the 385 00:22:48,800 --> 00:22:53,040 knowledge of SQL databases, being able to discuss with those 386 00:22:53,040 --> 00:22:56,940 who use Postgres, who use MongoDB, who have a new use case, they 387 00:22:56,940 --> 00:23:00,440 want to know if they can do it on both or one is better than the 388 00:23:00,440 --> 00:23:00,940 other. 389 00:23:01,380 --> 00:23:02,380 That was interesting. 390 00:23:03,420 --> 00:23:07,040 And I was like, OK, I should think about that. 391 00:23:07,640 --> 00:23:11,440 And then, of course, there is an offer that was interesting enough 392 00:23:11,440 --> 00:23:14,340 to say, OK, why waiting, just going there? 393 00:23:14,340 --> 00:23:18,300 But I could have the same offer from Yugabyte. 394 00:23:19,020 --> 00:23:22,700 So it's not really what makes the decision. 395 00:23:23,400 --> 00:23:28,300 Maybe it just push you to say, why not now rather than waiting 396 00:23:28,580 --> 00:23:30,040 6 months or 1 year? 397 00:23:30,300 --> 00:23:33,700 But no, the point was really learning something new. 398 00:23:33,700 --> 00:23:35,960 I really like learning something new. 399 00:23:36,040 --> 00:23:40,340 And all the content I create is me about learning. 400 00:23:41,820 --> 00:23:42,940 Nikolay: Yeah, well, yeah. 401 00:23:43,100 --> 00:23:46,080 My first reaction was, of course, I became very upset. 402 00:23:46,760 --> 00:23:52,860 And I started to think, is it like sudden change of your views 403 00:23:54,120 --> 00:24:00,460 or maybe you slowly became more unsatisfied with state of relational 404 00:24:00,460 --> 00:24:02,300 and SQL world and so on. 405 00:24:02,300 --> 00:24:07,160 So I asked our AI assistant, and as you know, we have all your 406 00:24:07,160 --> 00:24:08,000 blog posts. 407 00:24:08,420 --> 00:24:12,800 So I asked to research among blog posts where you talked about 408 00:24:12,800 --> 00:24:18,960 NoSQL and SQL, and to my surprise, it said you had such posts 409 00:24:18,960 --> 00:24:22,000 in the past and it's not a sudden change of views. 410 00:24:22,080 --> 00:24:25,620 So the result from AI was it's not a sudden change of views. 411 00:24:25,680 --> 00:24:31,580 But when I start, I asked to dig deeper, It was obvious that 412 00:24:31,980 --> 00:24:37,160 maybe the key reason was nulls in your past blog posts. 413 00:24:38,500 --> 00:24:41,980 The key criticism point was how null behavior. 414 00:24:42,440 --> 00:24:44,340 And I was going to raise this. 415 00:24:44,340 --> 00:24:47,400 I did it during the weekend and I was going to discuss this but 416 00:24:47,400 --> 00:24:51,420 as I already tweeted or x'd I don't know how to say it. 417 00:24:51,420 --> 00:24:55,120 Yesterday, what happened yesterday in the morning, my team made 418 00:24:55,120 --> 00:24:59,480 mistake and I actually I looked at that merge request myself 419 00:25:00,140 --> 00:25:05,100 so it was not null safe operation leading to nasty bug, which 420 00:25:05,220 --> 00:25:09,340 led to multiple companies receiving emails from us, actually 421 00:25:09,340 --> 00:25:12,020 a few emails from us, with wrong data. 422 00:25:12,360 --> 00:25:17,100 And it was because of just comparison, not involving three-value 423 00:25:17,160 --> 00:25:17,660 logic. 424 00:25:18,400 --> 00:25:21,540 And I was beaten by this so many times. 425 00:25:21,540 --> 00:25:26,660 I had a startup where I was stuck, my own startup, I was stuck 426 00:25:26,660 --> 00:25:29,160 7 months without growth. 427 00:25:29,700 --> 00:25:34,320 Although I knew there should be growth, but there is no growth 428 00:25:34,600 --> 00:25:39,880 and then I almost gave up and then I digged deeper into the code 429 00:25:39,880 --> 00:25:44,220 and found this bug again not null safe comparison we fixed it 430 00:25:44,220 --> 00:25:48,500 and in a few weeks we had 80,000 registrations per day. 431 00:25:49,600 --> 00:25:51,640 I almost gave up on that startup. 432 00:25:51,880 --> 00:25:57,180 This was like all nothing kind of, you know, it's just, it's 433 00:25:57,180 --> 00:26:01,740 distinct from or distinct like or coalesce, you can fix it in 434 00:26:01,920 --> 00:26:02,780 multiple ways. 435 00:26:02,860 --> 00:26:07,200 But if you overlook it's just a single line of problem that which 436 00:26:07,200 --> 00:26:09,500 can cost you a lot of money and time. 437 00:26:09,960 --> 00:26:14,020 And like maybe whole startup can depend on it as in my story. 438 00:26:14,020 --> 00:26:18,980 So I'm definitely with you in the criticism of null and not in 439 00:26:19,240 --> 00:26:20,780 with null values, right? 440 00:26:21,820 --> 00:26:26,820 Franck: I'm not really criticizing it because I love the free 441 00:26:26,820 --> 00:26:27,760 value logic. 442 00:26:28,140 --> 00:26:32,380 I love nulls because I think I understand it. 443 00:26:32,980 --> 00:26:34,300 Nikolay: I also think I understand. 444 00:26:34,300 --> 00:26:35,580 I also love exactly. 445 00:26:36,220 --> 00:26:36,980 Yeah, yeah, yeah. 446 00:26:37,860 --> 00:26:40,680 Franck: But it took me 20 years to understand it. 447 00:26:40,680 --> 00:26:44,180 And then I can understand that a developer who already has a 448 00:26:44,180 --> 00:26:49,300 lot of things to learn, do not want to spend time on something 449 00:26:49,300 --> 00:26:50,880 that looks like mathematics. 450 00:26:53,040 --> 00:26:53,820 Nikolay: It's good. 451 00:26:54,020 --> 00:26:57,240 It's kind of like I kind of came from academia, right? 452 00:26:57,500 --> 00:27:01,780 And I learned quickly during my university time because I had 453 00:27:01,780 --> 00:27:06,580 a very good professor, a big specialist in databases, and I quickly 454 00:27:06,580 --> 00:27:07,340 learned it. 455 00:27:07,540 --> 00:27:11,600 But it took me 20 years to stop liking it because I see reality 456 00:27:11,740 --> 00:27:15,760 says nobody, nobody, like everyone steps on this rake all the 457 00:27:15,760 --> 00:27:16,980 time, including myself. 458 00:27:17,920 --> 00:27:19,460 Franck: Yeah, you need to be pragmatic. 459 00:27:19,780 --> 00:27:25,080 But also, you can also solve all problems in SQL databases. 460 00:27:25,580 --> 00:27:27,020 Just don't use NULL. 461 00:27:27,400 --> 00:27:29,780 Just set all columns, not null. 462 00:27:30,040 --> 00:27:30,860 And that works. 463 00:27:30,920 --> 00:27:32,580 And you were talking about normalization. 464 00:27:33,900 --> 00:27:36,000 Just normalize a bit more. 465 00:27:36,260 --> 00:27:41,420 If you are tempted to put a NULL in a column, then it's probably 466 00:27:41,520 --> 00:27:44,700 because this column belongs to another table. 467 00:27:45,040 --> 00:27:48,200 And then it will not be a NULL, it will be the absence of a row 468 00:27:48,200 --> 00:27:49,340 in another table. 469 00:27:51,200 --> 00:27:58,040 Just go forward, full normalization, and do not allow any NULL, 470 00:27:58,260 --> 00:27:59,620 and that will work. 471 00:27:59,760 --> 00:28:00,400 I mean, 472 00:28:00,860 --> 00:28:01,840 Nikolay: It will work, but 473 00:28:01,840 --> 00:28:03,160 Franck: you will not have those errors. 474 00:28:03,160 --> 00:28:05,320 Maybe you will have some performance issues. 475 00:28:05,420 --> 00:28:05,920 Nikolay: Exactly. 476 00:28:06,820 --> 00:28:08,700 Performance issues will be inevitable. 477 00:28:10,260 --> 00:28:13,340 Franck: I see NULL like denormalization. 478 00:28:14,060 --> 00:28:16,040 It's a shortcut that is easy. 479 00:28:16,040 --> 00:28:21,900 It's so easy just to say, okay, let's put a NULL because it doesn't 480 00:28:21,900 --> 00:28:22,740 have a value. 481 00:28:23,400 --> 00:28:26,980 If it doesn't have a value, it should not have a row in the table. 482 00:28:28,260 --> 00:28:28,760 Nikolay: Yeah. 483 00:28:29,040 --> 00:28:36,620 I also remember, like, imagine you have CTO or some leader who 484 00:28:36,620 --> 00:28:37,660 understands NULLs. 485 00:28:38,380 --> 00:28:42,180 Imagine all those poor application developers who write Java, 486 00:28:42,180 --> 00:28:50,040 JavaScript, doesn't matter, PHP code, Ruby code, and this CTO 487 00:28:50,160 --> 00:28:55,520 with this understanding of NULLs in SQL constantly putting pressure 488 00:28:55,580 --> 00:28:59,320 like you again you used it wrong in your code and I was this 489 00:28:59,320 --> 00:29:03,620 person and right now I'm like I think just NULLs is 490 00:29:03,620 --> 00:29:03,920 Franck: a good 491 00:29:03,920 --> 00:29:09,320 Nikolay: concept but the world says please no it just doesn't 492 00:29:09,320 --> 00:29:12,520 work well So that's why I say I don't like them. 493 00:29:12,520 --> 00:29:14,120 Franck: I will take another analogy. 494 00:29:14,440 --> 00:29:17,060 I think the best editor is VI. 495 00:29:18,040 --> 00:29:18,940 Because I also 496 00:29:18,940 --> 00:29:19,340 Nikolay: agree to 497 00:29:19,340 --> 00:29:20,240 Franck: learn it. 498 00:29:20,380 --> 00:29:22,440 Yeah, we had to learn it 499 00:29:22,440 --> 00:29:23,500 Nikolay: inside TMAX. 500 00:29:23,560 --> 00:29:25,840 Franck: It was hard to learn it, we had to learn it. 501 00:29:25,840 --> 00:29:28,800 But when you know it, you are very efficient with it. 502 00:29:28,980 --> 00:29:33,580 But I can understand that a junior today do not want to learn 503 00:29:33,640 --> 00:29:34,940 all those VI commands. 504 00:29:36,040 --> 00:29:37,060 Same for null. 505 00:29:37,240 --> 00:29:42,140 I mean, if you learn it and if you spend all your life doing 506 00:29:42,160 --> 00:29:44,640 SQL, then, yeah, it's good. 507 00:29:45,060 --> 00:29:46,960 But that's not the reality. 508 00:29:47,660 --> 00:29:52,440 Nikolay: Yeah, so back to Monga, and let's talk a little bit 509 00:29:52,440 --> 00:29:58,380 about the alternative and if we go out of SQL world, but stay 510 00:29:58,380 --> 00:30:03,060 inside databases, what's happening to nulls and empty values, 511 00:30:03,080 --> 00:30:04,900 unknown values and so on. 512 00:30:05,540 --> 00:30:08,080 Zeros, empty strings. 513 00:30:08,860 --> 00:30:11,620 Should it be considered all the same or no? 514 00:30:15,020 --> 00:30:17,540 Franck: In SQL, for me in SQL it's easy. 515 00:30:17,560 --> 00:30:21,440 A null is a value that exists, but you just don't know the value. 516 00:30:24,220 --> 00:30:28,280 Your top manager has a salary, but you don't know it. 517 00:30:28,840 --> 00:30:33,280 So if you have to put all salaries in a database, then you will 518 00:30:33,280 --> 00:30:33,960 have a null. 519 00:30:33,960 --> 00:30:37,120 And maybe you will put it 1 day, just because you don't know 520 00:30:37,120 --> 00:30:39,360 it yet at the time where you insert. 521 00:30:40,080 --> 00:30:44,980 The problem is that null is used for other things, for something 522 00:30:45,060 --> 00:30:46,220 that doesn't exist. 523 00:30:46,220 --> 00:30:49,540 You know, when in Excel we say NA, doesn't apply. 524 00:30:50,580 --> 00:30:56,200 And if you use this as doesn't apply in JVa script, you're just 525 00:30:56,200 --> 00:30:59,860 trying to store it and have the same logic when you query the 526 00:30:59,860 --> 00:31:00,360 database. 527 00:31:00,860 --> 00:31:02,540 So MongoDB does that. 528 00:31:02,780 --> 00:31:05,040 It's very similar to not exist. 529 00:31:05,080 --> 00:31:08,880 You have those documents where you can declare an attribute or 530 00:31:08,880 --> 00:31:09,380 not. 531 00:31:09,960 --> 00:31:14,440 And in most cases, if it's not there, it's similar to null. 532 00:31:15,240 --> 00:31:19,300 And if you want to say explicitly it exists but I don't know 533 00:31:19,300 --> 00:31:24,740 the value, then add something else, like a boolean that says, 534 00:31:24,740 --> 00:31:26,540 okay, we don't know it. 535 00:31:28,700 --> 00:31:29,200 Nikolay: Yeah. 536 00:31:29,280 --> 00:31:32,120 By the way, You mentioned you like it, it's a good concept, but 537 00:31:32,120 --> 00:31:37,120 I'm thinking, so many caveats, for example, if you take null 538 00:31:37,120 --> 00:31:40,940 value and do plus 1, it will be also null, like unknown, remains 539 00:31:40,940 --> 00:31:44,020 unknown, because we don't know what we're using. 540 00:31:44,340 --> 00:31:44,700 If you 541 00:31:44,700 --> 00:31:48,000 Franck: don't know a value, then you can add 1 and you still 542 00:31:48,000 --> 00:31:49,100 don't know the value. 543 00:31:49,540 --> 00:31:52,800 Nikolay: If you say at the same time if you use aggregate sum 544 00:31:53,360 --> 00:31:56,620 it's not like that it uses 0 instead of now right? 545 00:31:58,580 --> 00:32:01,880 Franck: Yeah because you sum the use it's defined as summing 546 00:32:01,880 --> 00:32:03,820 the known values. 547 00:32:03,820 --> 00:32:05,880 Nikolay: You cannot explain this, it's not logical. 548 00:32:05,900 --> 00:32:13,160 It's just as is, because sum is just plus 1 argument, plus different, 549 00:32:13,480 --> 00:32:17,440 just a sequence of plus operations, right? 550 00:32:18,620 --> 00:32:18,900 Franck: But... 551 00:32:18,900 --> 00:32:21,400 Depends on how you define the aggregation. 552 00:32:22,300 --> 00:32:24,940 If it's even the sum of the known value... 553 00:32:26,680 --> 00:32:32,760 Nikolay: If we have 3 rows, salary, like $1, $2, and NULL dollars, 554 00:32:32,780 --> 00:32:33,680 NULL, right? 555 00:32:33,680 --> 00:32:34,180 Yeah. 556 00:32:34,200 --> 00:32:40,380 If we just perform explicit summarization, the result will be 557 00:32:40,380 --> 00:32:40,880 NULL. 558 00:32:40,960 --> 00:32:43,660 But if we use sum, we should be the same result. 559 00:32:43,660 --> 00:32:44,760 It will be not the same. 560 00:32:44,760 --> 00:32:45,740 It will be 3. 561 00:32:47,500 --> 00:32:50,460 Franck: Depends on how you define it, but SQL defines that as 562 00:32:50,460 --> 00:32:53,040 the sum of the values that you know. 563 00:32:54,840 --> 00:32:55,400 Nikolay: I apologize. 564 00:32:55,400 --> 00:32:55,840 It gives 565 00:32:55,840 --> 00:32:58,520 Franck: you an idea, and it makes sense. 566 00:32:58,520 --> 00:33:03,660 I mean, if you have 1000000 rows and you ask for a sum, you probably 567 00:33:03,720 --> 00:33:07,540 don't run an unknown just because 1 is not known. 568 00:33:07,540 --> 00:33:11,500 At least you know the sum of the existing ones. 569 00:33:12,100 --> 00:33:14,440 Nikolay: Let me apologize and explain what's happening here. 570 00:33:14,440 --> 00:33:19,660 I just flipped the board and made you defend the SQL world, which 571 00:33:19,660 --> 00:33:23,300 is interesting because it shows that you have courage to become 572 00:33:23,300 --> 00:33:24,520 specialist in both worlds. 573 00:33:24,520 --> 00:33:25,380 This is interesting. 574 00:33:27,440 --> 00:33:33,220 Franck: For me, I changed the company and I help different users, 575 00:33:33,380 --> 00:33:37,460 but I did not change what I think about databases. 576 00:33:37,720 --> 00:33:40,840 I mean, I've been working a lot with Oracle, I still think it's 577 00:33:40,840 --> 00:33:43,860 a very good database, but I can understand that people want to 578 00:33:43,860 --> 00:33:47,380 move out of it, and it's probably not because of the features. 579 00:33:47,720 --> 00:33:51,380 I like Postgres, but I also think that there is something else 580 00:33:51,380 --> 00:33:54,560 to do in the storage and to distribute it. 581 00:33:54,640 --> 00:33:59,020 I like YugabyteDB, but I also understand that some people may 582 00:33:59,020 --> 00:34:00,960 want to use something else. 583 00:34:01,360 --> 00:34:02,380 Same for MongoDB. 584 00:34:04,020 --> 00:34:08,160 I just want to help users when I can help them. 585 00:34:08,560 --> 00:34:13,980 And also something, especially on Twitter, but we see a lot of 586 00:34:13,980 --> 00:34:18,200 people comparing databases like MySQL is better than Postgres 587 00:34:18,220 --> 00:34:21,220 or Postgres is better than MySQL or whatever. 588 00:34:21,820 --> 00:34:25,360 And what I always say is that the best database is the 1 that 589 00:34:25,360 --> 00:34:26,080 you know. 590 00:34:26,500 --> 00:34:31,720 If you know how to administrate better SQL server on Windows, 591 00:34:31,720 --> 00:34:34,400 then that's probably the best database for you. 592 00:34:35,440 --> 00:34:36,680 It's not for me. 593 00:34:37,060 --> 00:34:43,220 And if you are more successful with the NULL behavior in document 594 00:34:43,260 --> 00:34:46,580 databases, then probably you should use document databases. 595 00:34:47,440 --> 00:34:52,360 So my goal is just to have people be successful and use the right 596 00:34:52,360 --> 00:34:54,660 database depending on what they know. 597 00:34:55,240 --> 00:35:02,840 The worst that you can do is work with MongoDB and do the same 598 00:35:02,840 --> 00:35:06,480 design as you did on the SQL database or the opposite. 599 00:35:07,300 --> 00:35:10,940 Putting everything in document in Postgres just because you have 600 00:35:10,940 --> 00:35:14,600 learned MongoDB first, that will probably not be good. 601 00:35:14,600 --> 00:35:18,340 You need to understand how it works, read an execution plan in 602 00:35:18,340 --> 00:35:21,220 both case, understand how the indexes are used. 603 00:35:23,400 --> 00:35:26,720 Michael: I kind of agree for products where you're the only user 604 00:35:26,720 --> 00:35:31,520 like if I'm choosing between iOS and Android or we were talking 605 00:35:31,520 --> 00:35:35,000 before the call about macOS or Windows if I'm the only person 606 00:35:35,000 --> 00:35:38,940 affected I understand choosing what I know best, but I feel like 607 00:35:38,940 --> 00:35:43,020 with databases we're often choosing for a team for an organization 608 00:35:43,260 --> 00:35:47,880 for a company And it's not just what I know best, even if I'm 609 00:35:47,880 --> 00:35:50,920 the tech lead or, you know, even if I am the decision maker, 610 00:35:50,920 --> 00:35:53,600 I need to factor in what do my team know best? 611 00:35:53,600 --> 00:35:55,080 What can we hire most easily? 612 00:35:55,080 --> 00:35:56,420 What's easiest to operate? 613 00:35:56,460 --> 00:35:59,480 Or how long will this project last? 614 00:35:59,480 --> 00:36:02,480 Is it a proof of concept project or is it our main system you 615 00:36:02,480 --> 00:36:06,240 know it's a bunch of other factors I think are really important 616 00:36:06,400 --> 00:36:09,020 and do you think you brought up use cases at the beginning I 617 00:36:09,020 --> 00:36:12,140 think that's like super important because we often do know the 618 00:36:12,140 --> 00:36:15,040 use cases we often do know the access patterns so picking the 619 00:36:15,040 --> 00:36:19,120 1 that is best for that makes more sense to me than like which 620 00:36:19,120 --> 00:36:23,000 1 I know best personally but I do take your point that if you 621 00:36:23,000 --> 00:36:26,140 if you take that as like an organization which 1 do you operationally 622 00:36:26,180 --> 00:36:29,760 know best as an organization like that it does still fit but 623 00:36:29,760 --> 00:36:32,300 I do think there's some subtle difference there what do you think 624 00:36:35,320 --> 00:36:39,200 Franck: I think that there are a lot of use cases that can be 625 00:36:39,200 --> 00:36:41,780 successful on many databases. 626 00:36:42,940 --> 00:36:48,120 Of course, there are some special cases that are really put at 627 00:36:48,980 --> 00:36:53,040 the maximum throughput needed, where you have really to define 628 00:36:53,720 --> 00:36:55,580 the right technology for it. 629 00:36:55,900 --> 00:36:58,700 But let's say you have time series. 630 00:36:59,800 --> 00:37:03,060 Time series coming from IoT and you have queries on them. 631 00:37:03,340 --> 00:37:08,300 Of course, you can use a time series database, but you can also 632 00:37:08,560 --> 00:37:12,180 do it on Postgres with a time series extension or not. 633 00:37:12,440 --> 00:37:16,260 And you can also do it on a document database. 634 00:37:16,840 --> 00:37:21,420 If you do it correctly, I think you have a lot of choices for 635 00:37:21,420 --> 00:37:22,620 many use cases. 636 00:37:23,040 --> 00:37:31,220 And finally, the enterprises that need a specific database because 637 00:37:31,320 --> 00:37:37,160 of the very high scale of it, they finally build their own database 638 00:37:38,460 --> 00:37:44,300 or they trick the 1 database to use it freely like their own 639 00:37:44,300 --> 00:37:44,800 database. 640 00:37:45,360 --> 00:37:48,340 But I think you really have the choice. 641 00:37:48,820 --> 00:37:52,540 Many use cases, you can do that on Postgres, you can do that 642 00:37:52,540 --> 00:37:56,760 on Yuga, but you can do that on Oracle, you can do that on MongoDB, 643 00:37:56,920 --> 00:37:58,760 you can do that on DynamoDB. 644 00:37:59,440 --> 00:38:04,120 But if you do it in a database where you don't know exactly how 645 00:38:04,120 --> 00:38:09,440 NULL works or how the isolation, the ACID properties, the locks 646 00:38:09,440 --> 00:38:15,080 are working, then you can also be successful on any database 647 00:38:15,300 --> 00:38:20,320 for many use cases, but you can also be very bad in any database 648 00:38:21,580 --> 00:38:22,780 if you don't care. 649 00:38:22,780 --> 00:38:26,700 So it's more about the people, I totally agree, not your personal 650 00:38:26,800 --> 00:38:28,940 choice, about the people. 651 00:38:28,940 --> 00:38:33,780 And I remember discussions when I was doing consulting, I remember 652 00:38:33,800 --> 00:38:38,960 discussing with a customer for something where it would have 653 00:38:38,960 --> 00:38:43,580 made sense to use stored procedure and they were growing all 654 00:38:43,580 --> 00:38:45,800 microservices, Java, all that. 655 00:38:46,160 --> 00:38:51,880 And they just told me, yeah, but if we do it in SQL, PL/SQL was 656 00:38:51,880 --> 00:38:57,180 on Oracle at that time, we are 4 in the team who can do that 657 00:38:57,180 --> 00:38:58,480 and maintain that. 658 00:38:58,660 --> 00:39:02,580 And then if any problem is there, we are 4 to be on call. 659 00:39:02,760 --> 00:39:08,000 If we do it in Java, we have 200 developers in India, we have 660 00:39:08,000 --> 00:39:09,900 200 developers in US. 661 00:39:09,960 --> 00:39:13,220 If there is a problem during the night, they will manage it. 662 00:39:13,480 --> 00:39:17,060 So the good choice, Even if it's not the best for performance, 663 00:39:17,120 --> 00:39:20,180 for design, for whatever, the good choice is is also something 664 00:39:20,220 --> 00:39:24,100 where you can sleep and have a team that can manage it. 665 00:39:24,520 --> 00:39:27,840 Nikolay: Well, right now, AI can help you fix bugs, tests, and 666 00:39:27,840 --> 00:39:28,540 so on. 667 00:39:29,600 --> 00:39:30,060 Oh, yeah. 668 00:39:30,060 --> 00:39:31,300 It's easier, right? 669 00:39:31,460 --> 00:39:34,960 I have a couple of questions from friends, and I think you know 670 00:39:34,960 --> 00:39:37,060 them, but I'm not going to reveal names. 671 00:39:38,300 --> 00:39:41,980 First question, is MongoDB adding SQL to the product? 672 00:39:45,060 --> 00:39:45,220 I don't 673 00:39:45,220 --> 00:39:48,060 Franck: think this is in the roadmap at all. 674 00:39:48,480 --> 00:39:51,260 And I don't think people are asking for that. 675 00:39:51,900 --> 00:39:55,580 Let's look at another SQL database, DynamoDB. 676 00:39:56,980 --> 00:40:01,500 When DynamoDB added the SQL syntax on top of it using PartiQL, 677 00:40:02,840 --> 00:40:04,100 it was never used. 678 00:40:05,440 --> 00:40:11,720 And the main reason was that users were afraid of it because 679 00:40:11,720 --> 00:40:17,620 with the API that, with the document API, they know what happens. 680 00:40:18,040 --> 00:40:22,040 The big difference, I mentioned the API, but there is a big difference 681 00:40:22,060 --> 00:40:23,820 between NoSQL and SQL. 682 00:40:23,820 --> 00:40:29,740 In SQL, you have a declarative language where you don't know 683 00:40:29,760 --> 00:40:34,400 how the data is accessed until you read the execution plan. 684 00:40:36,420 --> 00:40:39,680 Which is good because you have an application that is independent 685 00:40:39,820 --> 00:40:44,580 of the physical data model, but it's also more difficult because 686 00:40:44,580 --> 00:40:49,180 the developer has no idea how it works in production before looking 687 00:40:49,180 --> 00:40:50,420 at the execution plan. 688 00:40:50,900 --> 00:40:54,820 And when looking at the execution plan, the developer may have 689 00:40:54,820 --> 00:40:59,700 to work a long time to understand why the bad execution plan 690 00:40:59,700 --> 00:41:00,460 is chosen. 691 00:41:00,660 --> 00:41:03,680 Is it because of statistics, not good index, whatever, it's kind 692 00:41:03,680 --> 00:41:04,380 of complex. 693 00:41:05,160 --> 00:41:11,300 With the NoSQL APIs, you code the data access. 694 00:41:11,860 --> 00:41:13,400 So it depends on the database. 695 00:41:13,420 --> 00:41:16,200 For example, in DynamoDB, if you want to use an index, you have 696 00:41:16,200 --> 00:41:17,380 to query the index. 697 00:41:17,860 --> 00:41:21,480 In MongoDB, you have this data independence where you query on 698 00:41:21,480 --> 00:41:24,900 the collection, and if the index can be used, it can be used. 699 00:41:25,160 --> 00:41:27,840 But you control the data that is accessed. 700 00:41:27,840 --> 00:41:31,360 For example, when you design your documents, You design something 701 00:41:33,820 --> 00:41:38,480 that is joined when you insert it, not at run time, where a query 702 00:41:38,480 --> 00:41:42,280 planner will decide if it starts with 1 table or another table. 703 00:41:42,980 --> 00:41:44,840 And it has some good and bad. 704 00:41:45,440 --> 00:41:49,340 I remember in consulting, spending a long time with developers, 705 00:41:50,500 --> 00:41:55,020 looking at the execution plan and they know their data and they 706 00:41:55,020 --> 00:41:59,060 know their access pattern and they immediately tell me, of course, 707 00:41:59,060 --> 00:42:01,100 that's not the right execution plan. 708 00:42:01,100 --> 00:42:04,580 We must start with this table and then look up into this 1. 709 00:42:05,020 --> 00:42:05,920 Okay, perfect. 710 00:42:06,340 --> 00:42:11,260 I can use an int pg_hint_plan, for example, in Postgres to validate 711 00:42:11,260 --> 00:42:13,940 that it's a better execution plan. 712 00:42:14,120 --> 00:42:15,580 And then the developer is happy. 713 00:42:15,580 --> 00:42:16,340 Yeah, perfect. 714 00:42:16,340 --> 00:42:17,200 I want that. 715 00:42:17,220 --> 00:42:20,140 And then they're like, okay, but it's not finished. 716 00:42:20,600 --> 00:42:25,200 Now, we need to figure out how to get the right execution plan 717 00:42:25,200 --> 00:42:26,540 without the hint. 718 00:42:27,440 --> 00:42:32,220 And with consulting, people were paying the day just to get the 719 00:42:32,220 --> 00:42:36,220 right execution plan that they know initially was the best 1. 720 00:42:36,760 --> 00:42:41,740 With an OSQL API, you are closer to what happens physically and 721 00:42:41,740 --> 00:42:44,580 then you have more control on that and some developers prefer 722 00:42:44,580 --> 00:42:45,080 that. 723 00:42:46,500 --> 00:42:50,440 Nikolay: Next question was, what do you think Postgres can or 724 00:42:50,440 --> 00:42:51,800 should learn from MongoDB? 725 00:42:52,080 --> 00:42:53,260 Maybe this, right? 726 00:42:53,940 --> 00:42:55,340 Is it possible to... 727 00:42:55,460 --> 00:42:56,560 Michael: I have 1 more. 728 00:42:57,880 --> 00:43:00,180 I think they do major upgrades really well. 729 00:43:01,100 --> 00:43:01,800 Franck: Oh, yes. 730 00:43:02,780 --> 00:43:03,260 Well... 731 00:43:03,260 --> 00:43:05,260 Michael: But we can learn that from a lot of databases. 732 00:43:07,200 --> 00:43:11,920 Nikolay: Yeah, previous question was because I had like maybe 733 00:43:11,920 --> 00:43:17,060 outdated knowledge that many NoSQL systems implemented some dialect 734 00:43:17,080 --> 00:43:20,960 of SQL, for example, Cassandra with CQL, right? 735 00:43:21,980 --> 00:43:23,040 Franck: Yeah, but they... 736 00:43:23,480 --> 00:43:24,220 Nikolay: Not used. 737 00:43:24,520 --> 00:43:27,440 Franck: It's only syntax, it's not SQL, it's not a declarative 738 00:43:27,620 --> 00:43:29,000 language, it's just syntax. 739 00:43:29,440 --> 00:43:30,700 I don't see the point. 740 00:43:32,900 --> 00:43:33,200 Nikolay: If you 741 00:43:33,200 --> 00:43:36,340 Franck: have an API that is integrated with your programming 742 00:43:36,340 --> 00:43:41,380 language, why do you want to write a string in Java that you 743 00:43:41,380 --> 00:43:43,760 send to the database if you don't have to? 744 00:43:44,280 --> 00:43:48,060 In SQL, You have to do that because you have this data independence 745 00:43:48,240 --> 00:43:49,700 and very different language. 746 00:43:50,140 --> 00:43:52,080 But I don't really see the point. 747 00:43:52,540 --> 00:43:53,980 But I forgot what you mentioned. 748 00:43:54,340 --> 00:43:58,180 Nikolay: Yeah, I said vice versa what Postgres could learn from. 749 00:43:59,280 --> 00:44:00,860 Michael answered upgrades. 750 00:44:01,160 --> 00:44:03,400 I concur with you, definitely. 751 00:44:04,900 --> 00:44:06,300 Franck: But that is related. 752 00:44:07,540 --> 00:44:12,500 In SQL databases, in relational databases, to have this data 753 00:44:12,500 --> 00:44:15,860 independence, logical and physical data independence, where you 754 00:44:15,860 --> 00:44:20,360 query, in SQL databases, you query a logical model. 755 00:44:20,900 --> 00:44:22,380 We were talking about normalization. 756 00:44:22,900 --> 00:44:24,500 This is the logical model. 757 00:44:24,560 --> 00:44:27,100 Maybe physically everything is stored in 1 table. 758 00:44:27,100 --> 00:44:31,620 You don't really care from the relational SQL point of view. 759 00:44:31,800 --> 00:44:35,860 But then to map the logical model to the physical model, you 760 00:44:35,860 --> 00:44:37,700 need a catalog, a dictionary. 761 00:44:38,300 --> 00:44:43,380 And this is what is difficult during upgrades, because you need 762 00:44:43,380 --> 00:44:46,920 to change the catalog and the catalog is shared. 763 00:44:47,400 --> 00:44:50,980 You can short the data, you can distribute the data, but the 764 00:44:50,980 --> 00:44:55,620 catalog must be shared because they must use the same dictionary. 765 00:44:56,400 --> 00:45:01,820 And that's easier with a NoSQL database because you have much 766 00:45:01,820 --> 00:45:06,220 less to share about the metadata, because the catalog is in the 767 00:45:06,220 --> 00:45:06,720 application. 768 00:45:07,400 --> 00:45:12,100 The schema, we were talking about schemaless or schema on read 769 00:45:12,100 --> 00:45:12,820 or on write. 770 00:45:12,820 --> 00:45:16,820 The big difference is that Most of the schema is in the application. 771 00:45:16,960 --> 00:45:19,780 And then if you upgrade the application, you have a new version 772 00:45:20,080 --> 00:45:23,180 of the application, it knows the new schema. 773 00:45:23,260 --> 00:45:26,660 And the 2 versions can work together if you take care that when 774 00:45:26,660 --> 00:45:29,280 you read a document, you know how to read it. 775 00:45:30,660 --> 00:45:31,500 Michael: Great answer. 776 00:45:32,100 --> 00:45:33,340 Nikolay: Yeah, last question. 777 00:45:33,420 --> 00:45:38,400 What do you think about systems which are built on top of Postgres, 778 00:45:38,600 --> 00:45:42,680 like FerretDB and DocumentDB recently released by Microsoft? 779 00:45:45,040 --> 00:45:45,980 Franck: That's a good point. 780 00:45:46,920 --> 00:45:52,860 So, beyond the funny thing that DocumentDB is an AWS database, 781 00:45:54,400 --> 00:45:58,940 but the name belongs to Microsoft because before putting a MongoDB 782 00:45:59,460 --> 00:46:03,780 like API on Cosmos DB, it was called DocumentDB. 783 00:46:04,940 --> 00:46:09,720 So, Microsoft did that multiple times, put it in Cosmos DB to 784 00:46:09,720 --> 00:46:11,500 see if it will be more popular. 785 00:46:11,980 --> 00:46:13,940 So first, it's a mess. 786 00:46:15,440 --> 00:46:20,400 Different API, similar, you don't know the name where it comes 787 00:46:20,400 --> 00:46:25,880 from, but I really like what the FerretDB people are doing. 788 00:46:26,400 --> 00:46:32,440 And for me, as a developer advocate, I really like that there 789 00:46:32,440 --> 00:46:35,040 is a MongoDB API on multiple databases. 790 00:46:35,380 --> 00:46:38,260 In Oracle, you can also have a MongoDB API. 791 00:46:39,280 --> 00:46:44,540 The more you make it popular, the more you help users to use 792 00:46:44,540 --> 00:46:48,460 another API without changing the database, that's perfect. 793 00:46:48,840 --> 00:46:52,100 From a marketing point of view, I don't think it's a big problem 794 00:46:52,360 --> 00:46:56,420 either, because it's not only about the API. 795 00:46:56,880 --> 00:47:02,980 What I think that the big customers of MongoDB like with MongoDB 796 00:47:03,380 --> 00:47:08,000 is that they have in front a company that is doing only 1 thing. 797 00:47:08,920 --> 00:47:11,060 The company is doing only MongoDB. 798 00:47:11,960 --> 00:47:16,220 It's not like Oracle that has a database, but also another database 799 00:47:16,400 --> 00:47:19,420 and cloud and manage service and software. 800 00:47:19,640 --> 00:47:21,240 MongoDB is doing only MongoDB. 801 00:47:21,700 --> 00:47:28,780 So if they use MongoDB on MongoDB, they have hundreds of people 802 00:47:28,780 --> 00:47:30,060 doing support on it. 803 00:47:30,060 --> 00:47:35,140 Nikolay: I cannot agree here because I remember MongoDB company, 804 00:47:35,380 --> 00:47:37,860 it's called Mongo or MongoDB, sorry... 805 00:47:37,860 --> 00:47:41,260 So I remember they also did some Postgres when they first released 806 00:47:41,260 --> 00:47:42,140 BI connector. 807 00:47:42,840 --> 00:47:43,980 Remember this story? 808 00:47:44,640 --> 00:47:45,280 They used Postgres. 809 00:47:45,280 --> 00:47:46,220 Franck: I have no idea. 810 00:47:46,980 --> 00:47:52,120 Nikolay: To be able to use Tableau and other systems for data 811 00:47:52,120 --> 00:47:55,740 analysis, BI and so on. 812 00:47:56,320 --> 00:48:01,120 They needed to make some bridge to SQL world and they used Postgres 813 00:48:01,120 --> 00:48:01,820 for that. 814 00:48:02,220 --> 00:48:02,980 It was very interesting. 815 00:48:02,980 --> 00:48:03,980 Franck: I have no idea. 816 00:48:04,120 --> 00:48:08,560 My point was more like, you can do some MongoDB on Percona, you 817 00:48:08,560 --> 00:48:13,580 can do some MongoDB on Oracle, you can do some MongoDB for FerretDB 818 00:48:14,540 --> 00:48:15,320 on Azure. 819 00:48:16,020 --> 00:48:17,180 And that can work. 820 00:48:17,180 --> 00:48:20,840 But if you are a big customer and want support, you probably 821 00:48:21,960 --> 00:48:25,580 want support from the original 1. 822 00:48:26,400 --> 00:48:31,500 Nikolay: I hear you speaking as a member of this team, new member 823 00:48:31,500 --> 00:48:37,400 of this team, but I also have like my must have a note that MongoDB 824 00:48:37,440 --> 00:48:38,900 is not pure open source. 825 00:48:40,240 --> 00:48:42,540 Franck: It is not pure open source, yeah. 826 00:48:42,540 --> 00:48:46,120 Nikolay: Well, FerretDB is Apache 2.0, which is pure open source. 827 00:48:46,120 --> 00:48:47,420 So this is 1 of... 828 00:48:47,440 --> 00:48:48,120 Franck: Yeah, yeah, yeah. 829 00:48:48,120 --> 00:48:50,640 Of course, I'm a big fan of open source. 830 00:48:50,640 --> 00:48:54,640 I would prefer that it is open source, but I can also understand. 831 00:48:55,960 --> 00:48:58,980 You know why they had to change the license? 832 00:48:59,040 --> 00:49:01,420 Because AWS was taking everything. 833 00:49:01,720 --> 00:49:05,780 And finally, today AWS is a major partner. 834 00:49:05,860 --> 00:49:08,620 So it was probably a good move. 835 00:49:09,180 --> 00:49:11,340 Probably today it could be open source. 836 00:49:11,420 --> 00:49:16,220 But yeah, I can understand given the history that they want to 837 00:49:16,220 --> 00:49:17,760 protect the managed service. 838 00:49:18,260 --> 00:49:20,900 Nikolay: Open source is eating commercial software, clouds are 839 00:49:20,900 --> 00:49:22,320 eating open source software. 840 00:49:22,540 --> 00:49:27,840 Yeah, you remember this sequence of fish picture, right? 841 00:49:27,980 --> 00:49:31,560 Yeah, okay, I think no more questions from me. 842 00:49:31,560 --> 00:49:34,240 It was very super interesting and yeah, enjoy. 843 00:49:34,240 --> 00:49:35,260 Thank you for coming. 844 00:49:36,380 --> 00:49:37,420 Franck: Thank you very much. 845 00:49:37,420 --> 00:49:41,980 I really like also what you do, how you can come with so many 846 00:49:41,980 --> 00:49:44,580 different topics on every week. 847 00:49:45,600 --> 00:49:49,340 I think you never missed a week for us. 848 00:49:49,960 --> 00:49:51,880 So yeah, that's really nice. 849 00:49:52,360 --> 00:49:52,860 Nikolay: Great. 850 00:49:53,940 --> 00:49:55,400 Michael: Really kind of you, Franck. 851 00:49:55,460 --> 00:49:56,420 Thank you for joining. 852 00:49:56,780 --> 00:49:57,480 Franck: Thank you. 853 00:49:58,320 --> 00:49:59,440 Nikolay: Have a great week.