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.
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.
