Michael: Hello and welcome to Postgres.FM, a weekly show about
all things PostgreSQL.
I am Michael, founder of pgMustard, and as usual, I'm joined
by Nikolay, founder of Postgres.AI.
Hey, Nikolay.
Nikolay: Hi, Michael.
Michael: And we have a special guest today, Franck Pachot, who
is a developer advocate now at MongoDB, formerly at YugabyteDB,
which is a distributed PostgreSQL database, also an AWS Data
Hero, and Oracle Certified Master.
So, welcome, Franck.
Franck: Hi.
Thanks.
Thanks for having me there.
Nikolay: And former Postgres blogger.
Franck: Yeah.
Nikolay: No?
Or yes?
Franck: Oh, yeah, yeah.
I will continue to blog about all databases, it's just that it
depends on the time I have.
Nikolay: Sounds good.
So I saw you are going to give a talk at some Postgres conference
in India, right?
PGConf India, I don't remember the name.
So still planning to do it, right?
Franck: Yeah.
And also Germany.
I just got the acceptance.
Nikolay: I'm very curious.
During daytime, you work using JSONs and these weird queries,
right, chains of something.
And then at weekend or something you present SQL talks.
How is it going to be played in your mind?
I'm very curious.
Franck: It's all about databases.
I mean, it's all the same.
Nikolay: All the same.
Franck: Yeah, you can do data modeling, document data modeling
on Postgres.
You can do it on Oracle.
You can do it on MongoDB.
You can normalize your data on SQL databases, on NoSQL databases.
The concepts are all the same.
Of course, there are little differences, like how NULLs are undulied,
for example, or how you join or you don't join, but yeah.
Nikolay: NULLs, let's postpone.
It's a special topic.
It's not for the start.
Okay.
I remember a series of blog posts from Michael Stonebraker about
criticizing document databases for lack of normalization and
so on.
So you are saying now that it's totally possible to apply normalization
in document database.
Is this what you're trying to say?
Or maybe I'm getting wrong.
Franck: I've also changed my mind probably because for 2 reasons.
First, the applications have changed.
I think the normalized model was really good for those monolithic
databases where all use cases with the enterprise information
system in 1 database running all use cases.
And then you need a normalized way to structure the data that
is shared by the whole company and all kinds of users.
Today, it's a bit different.
You have multiple services, multiple microservices.
They might have different databases.
And then the concern of normalization may be different.
For example, if you consume data only to read it and not update
it, you can denormalize a bit more.
So that's 1 reason and I think the main reason is also the applications
have changed.
Today in application programming languages you use documents
in nested structure, objects, object graphs, looks like more
like documents so it's easier to move it to applications.
Nikolay: I don't get it because we had documents for forever.
For example, Codd designed relational model originally dealing
with banking systems, right?
In 60s, 70s, and it was not convenient to have nesting at that
point.
Before rational model, we know there were what's the name like
net and I forgot names, but basically closer to...
Franck: Hierarchical models and network models.
Nikolay: Yeah, yeah, yeah, exactly.
And the idea was it's really inconvenient when we keep a document
as a whole and we need to split it into pieces and basically
divide and conquer, right?
We split into pieces and that's how we get flexibility and start
working.
And we had documents at that time as well, like invoices or transactions
like between financial institutions and so on.
So I don't see the big change, just amount of data and so on,
right?
And I don't fully understand why the idea of microservices or
something you, as I understand, you are bringing, like when we
have many, many databases, many services.
Why is it changing this?
Because in my head, it's vice versa.
If we have many services, we do need to structure and split into
more atomic pieces of our data, right?
And the article I mentioned, it's called "Schema Later Considered
Harmful."
After my post, actually, this is why I named my sub-transactions
blog post also considered harmful.
And some folks mentioned on Hacker News mentioned that there
is an article considered harmful, considered harmful, harmful,
considered harmful titles considered harmful.
So it's basically like not a good way to name articles, but the
blog post is quite good.
Like if schema design, normalization still makes sense.
If you don't do it, you deal with bad consequences later.
So please let
Franck: me understand.
Yeah, but it depends on your use case.
And also something I've been working on relational databases
where you normalized, but basically, when I learned databases
at university, it was all about normalization.
And then when you start to work, you hear people talking about
denormalizing everything.
And of course, you just need to think about the access patterns.
Nikolay: Yeah, Let me just add this.
Sorry for interrupting, but let me just add, I totally agree.
If we over-normalize, then we deal with very simple fact that
you cannot create 1 index on 2 tables.
You won't, Because, for example, filtering on 1 table, filtering
on another table, you want a single index scan.
Definitely, this is what we do also.
My team and I, we do, during consulting practice, we say, okay,
here we do need to normalize.
But my point is, if you take Mongo and other document databases,
they just provoke you to avoid normalization at all.
In relational data systems, we can...
Is it OK?
Am I wrong?
Franck: Yeah, for me, you are wrong.
And I think that's also 1 reason MongoDB was interested to have
a developer advocate coming from SQL databases, is that users
tend to think that they have to denormalize everything and to
put everything in 1 document, which is wrong.
The idea in MongoDB is to put together what you insert together
or what you query together, but in different documents if you
query differently.
Just to take an example, another entry system, you don't want
to put together the customers and the orders because you don't
want 1 document per customer where you just add orders that can
be a lot every year.
But the orders themselves, the orders and the other items which
we usually put in 2 tables in SQL databases just because they
have different cardinalities.
That's something you can put in a single document, because you
insert an order with all the items.
You have nobody who will just update 1 item of the order and
you query them together.
Of course, it depends on the system.
If you're in a system that analyzes the order lines for marketing
purpose, buy the product and you don't care about the customer
or the other, then maybe the modeling is different.
And this is where different use cases are.
But it's not about putting everything in 1 document.
And that's also why it's good to do some design reviews?
Because it's easy for a developer to start and put everything
in 1 document, just moving what they have in Java to the database,
but still needs design and still need to think about what you
embed, like denormalize, or what you reference, like you would
reference with foreign keys in a secure database?
Nikolay: OK, I hear you.
I think I understand you.
But still, You say users have this tendency to think.
For example, user Michael Stonebraker says that he noticed that
maybe it's possible to normalize, of course, but in relational
databases there is a big tendency to normalize first and then
denormalize when needed.
In document store databases, there is the opposite tendency.
Avoid normalization first and then normalize when we have pain.
The whole article called "Schema Later Considered Harmful."
I think, as I understand this article, it's about that the relational
approach, direction of movement is more beneficial in general
case than opposite.
What do you think?
Franck: Yeah, but remember that relational databases were made
at a time where we were designing the data before looking at
the use cases.
The normalization and the data model doesn't care about the use
cases.
You just model the data.
You have orders, multiple order items, an order belongs to a
customer.
You do a static model of your data, and then you bring the application
use cases, and you can optimize them with indexes, but you don't
change the data model for the use cases.
But this is not really how applications are developed today.
Today, applications come with a main use case and rent fast access
for this use case.
For another use case, they just check if they can do it on the
same database, or maybe do some event streaming, put that in
another database and doing elsewhere.
That really has changed.
Today, even applications that run on SQL databases, I see people
starting a data model, knowing the access patterns.
And then maybe you can denormalize.
For example, it's okay to denormalize something that is not updated.
The big danger to denormalize something that may be updated is
that you have to update in multiple places, which is a risk of
inconsistency if you forget 1, and which is also a performance
issue, especially when you distribute, then you have distributed
transactions at multiple places.
But data that you do not update, and there is a lot of data that
we don't update, we just add a new version of it.
For example, a customer is creating a new order, you will not
update the order.
If we add a new item, that will be a new order, but the existing
order has been validated.
You don't update this data later.
Usually you have a timestamp, And even if you change something,
then you just add the new version.
So the applications have changed.
And I'm not saying that 1 is better than the other.
But when we listen to the developers, we see that they don't
want to build this ERD diagram.
That was never true.
So that's also something.
Nikolay: Nobody does that anymore, building ERD diagrams.
Or only our AI system does, but it's just a side function for
it.
But I don't understand why we cannot do it on relational databases
and still have all the good stuff.
Because we have JSON, let's just put it there and so on.
Franck: And It's very good to mix both.
I've seen a lot of applications on Oracle, on Postgres, on Yugabyte,
where it's a mix where you have tables with Columns because they
are updated because you went indexes on it, and you have a bunch
of metadata information that you put in a JSON.
And that's also perfectly valid.
Nikolay: And so what does Mongo bring here, if we have it already?
Franck: I think the API is very different.
Nikolay: Of course.
Franck: Yeah.
With MongoDB, you can really...
You have your object graph in the application.
In JavaScript, it's even easier, but in Java, in whatever, in
Python, and you just communicate with the Database those documents
and they are stored as documents.
The big problem with SQL databases or so something that has changed
when Application have changed at the time where everything was
done in the Database, stored procedures or pre-compiled procedures
or whatever, then that was okay.
But with object-oriented programming, you had this mismatch and
you need an object-relational mapping to map from 1 to the other
if you don't want to do a bunch of queries in text strings and
through JDBC.
So, what MongoDB brings at that point is an API that really fits
with the programming language and then it stores it as documents
rather than mapping that to relational tables.
Nikolay: Yes, this is what HDB and HQL are trying to solve.
They try to reinvent SQL to have this, what you describe.
Yeah, but you mentioned OOP and ER.
I think this is in the past already, both.
No, I'm joking, I'm joking.
So for me
Franck: it's like...
Then what do you use today if you...
I mean, applications are built with objects?
Nikolay: Well, I personally am a big fan of things what guys
like Hasura, Supabase, others do with thin layer providing APIs
right away without the need to write this middleware.
It's great, this serves better than object-relational mapping.
But people do object-relational mapping, but at the same time,
I doubt a lot of guys who create projects, they do actual OOP
with patterns and so on.
It's kind of like somehow not cool anymore.
It's my perception.
I'm far from actual application programming lately.
Franck: But it's also this old debate where do you put your business
logic?
Ideally in a SQL database, you put it in the database because
data is processed there, but then you are constrained to specific
languages.
Nikolay: Well, right.
But if you put it to application, you also have dependency on
this language you chose.
It's the same.
To me, the question about where to put logic became much easier
to understand since like 10 years ago when Angular and React,
they obtained, gained popularity and a lot of logic and actually
Web 2.0, how many years ago already?
Like 20 years ago, right?
All these shifted a lot of client-oriented logic to clients,
to front-end, right?
And this gave space to have logic closer to data, like constraints
and what we usually do with triggers, some dependencies, propagation
of changes or something.
It gives opportunity to keep it in database where it should be
because otherwise, if you don't do it closer to database, at
some point when company grows, project grows, you add some other
tools or application layers or something called, and you need
to re-implement the same logic in different places.
And there is no strong guarantee that it will be well maintained.
Yeah, but the
Franck: problem is just, I totally agree, and there are very
successful database-centric applications.
But what developers want, they want to use Java, not PL/pgSQL
and not PL/SQL.
And just because try to hire a SQL developer or a PL/pgSQL developer,
that will be more difficult than hiring a team of Java developers.
Nikolay: Right.
Right.
Michael wanted to ask something.
Michael: I don't know if this is a change of topic, but I think
it's on the same path, which is around developer experience.
And I know it's a subjective term, but I do think when, at least
when Mongo went into the market, but I think NoSQL databases
in general, they promised a few things.
1 was a really good getting started experience, a very quick,
easy, you don't have to think much type, no schema to worry about,
and just get started.
And that's good for some things and not so good in other ways.
But it also promised a couple of other things.
And I think we can learn a lot from these things in terms of
why was it popular?
Like, why did Mongo take off?
Why was NoSQL so popular for so long?
It also promised kind of infinite, or at least horizontal scalability.
And that's something we've historically struggled with.
I know you worked on distributed SQL, but it's something we've
historically struggled with in the SQL world.
And then, yeah, I think that combination of things seemed really
interesting to me.
And I wondered if you had opinions on what is it about that developer
experience that really resonated with people?
Franck: For me, that's really developer experience where MongoDB
is really, was really successful.
The scalability, I don't really know because I didn't use MongoDB
at that time, and then I've seen scalability in SQL databases.
The scalability comes from the data model where you can have
an easy sharding key.
Yeah.
As soon as you have an easy sharding key, you can distribute
that on mostly all databases today.
On Postgres, you have multiple options like Citus, like Aurora,
Limitless, where If you have a sharding key, you can distribute.
I don't think it's really the point today.
The point is really develop your experience.
As you say, it's easy to start and it's easy to integrate to
your programming language also.
Not having something else to learn, a different language, but
also a different behavior, thinking about what you need to look,
thinking about foreign keys, thinking about performance when
you read from multiple tables.
But it's also, the easy to start is also a problem.
And basically I'm working in the DevRel team where most of the
job is helping users, developers to do some proper data modeling
design.
Because it's easy to start, which is good when you start a proof
of concept, but at some point like in any database, you need
to do some design.
And the more easy it is to start, the more difficult it is to
realize that, okay, we are not in a proof of concept anymore,
we'll put that in production.
It's an application that will evolve in the coming years.
And then we need to look at the design.
And this is one of the major activity in the DevRel team.
It's not like being developer advocate for Yugabyte was really
about awareness because it's a new database, so you just need
to let people know it.
MongoDB, people know it.
You just need to make them successful with maybe a bit more complex
use cases and do some data modeling.
Nikolay: So I have a question about how your personal experience
and this decision you made, obviously, recently.
It feels like you switched teams, like in soccer or football.
Right?
So my question was, any, like, transfer cost?
Franck: Ah, that's a very good question.
So let me explain how it was.
I was really happy at Yugabyte, about the team, about the colleagues,
about the product.
I was really not looking for another job.
And when other companies contacted me, I was like, oh, sorry,
I'm happy where I am.
And when MongoDB contacted me, it was more by curiosity, like
why an SQL databases is interested by my experience.
And this is why I started discussions by curiosity.
And then this is where I realized that it was really an interesting
approach that's helping users on document databases with the
knowledge of SQL databases, being able to discuss with those
who use Postgres, who use MongoDB, who have a new use case, they
want to know if they can do it on both or one is better than the
other.
That was interesting.
And I was like, OK, I should think about that.
And then, of course, there is an offer that was interesting enough
to say, OK, why waiting, just going there?
But I could have the same offer from Yugabyte.
So it's not really what makes the decision.
Maybe it just push you to say, why not now rather than waiting
6 months or 1 year?
But no, the point was really learning something new.
I really like learning something new.
And all the content I create is me about learning.
Nikolay: Yeah, well, yeah.
My first reaction was, of course, I became very upset.
And I started to think, is it like sudden change of your views
or maybe you slowly became more unsatisfied with state of relational
and SQL world and so on.
So I asked our AI assistant, and as you know, we have all your
blog posts.
So I asked to research among blog posts where you talked about
NoSQL and SQL, and to my surprise, it said you had such posts
in the past and it's not a sudden change of views.
So the result from AI was it's not a sudden change of views.
But when I start, I asked to dig deeper, It was obvious that
maybe the key reason was nulls in your past blog posts.
The key criticism point was how null behavior.
And I was going to raise this.
I did it during the weekend and I was going to discuss this but
as I already tweeted or x'd I don't know how to say it.
Yesterday, what happened yesterday in the morning, my team made
mistake and I actually I looked at that merge request myself
so it was not null safe operation leading to nasty bug, which
led to multiple companies receiving emails from us, actually
a few emails from us, with wrong data.
And it was because of just comparison, not involving three-value
logic.
And I was beaten by this so many times.
I had a startup where I was stuck, my own startup, I was stuck
7 months without growth.
Although I knew there should be growth, but there is no growth
and then I almost gave up and then I digged deeper into the code
and found this bug again not null safe comparison we fixed it
and in a few weeks we had 80,000 registrations per day.
I almost gave up on that startup.
This was like all nothing kind of, you know, it's just, it's
distinct from or distinct like or coalesce, you can fix it in
multiple ways.
But if you overlook it's just a single line of problem that which
can cost you a lot of money and time.
And like maybe whole startup can depend on it as in my story.
So I'm definitely with you in the criticism of null and not in
with null values, right?
Franck: I'm not really criticizing it because I love the free
value logic.
I love nulls because I think I understand it.
Nikolay: I also think I understand.
I also love exactly.
Yeah, yeah, yeah.
Franck: But it took me 20 years to understand it.
And then I can understand that a developer who already has a
lot of things to learn, do not want to spend time on something
that looks like mathematics.
Nikolay: It's good.
It's kind of like I kind of came from academia, right?
And I learned quickly during my university time because I had
a very good professor, a big specialist in databases, and I quickly
learned it.
But it took me 20 years to stop liking it because I see reality
says nobody, nobody, like everyone steps on this rake all the
time, including myself.
Franck: Yeah, you need to be pragmatic.
But also, you can also solve all problems in SQL databases.
Just don't use NULL.
Just set all columns, not null.
And that works.
And you were talking about normalization.
Just normalize a bit more.
If you are tempted to put a NULL in a column, then it's probably
because this column belongs to another table.
And then it will not be a NULL, it will be the absence of a row
in another table.
Just go forward, full normalization, and do not allow any NULL,
and that will work.
I mean,
Nikolay: It will work, but
Franck: you will not have those errors.
Maybe you will have some performance issues.
Nikolay: Exactly.
Performance issues will be inevitable.
Franck: I see NULL like denormalization.
It's a shortcut that is easy.
It's so easy just to say, okay, let's put a NULL because it doesn't
have a value.
If it doesn't have a value, it should not have a row in the table.
Nikolay: Yeah.
I also remember, like, imagine you have CTO or some leader who
understands NULLs.
Imagine all those poor application developers who write Java,
JavaScript, doesn't matter, PHP code, Ruby code, and this CTO
with this understanding of NULLs in SQL constantly putting pressure
like you again you used it wrong in your code and I was this
person and right now I'm like I think just NULLs is
Franck: a good
Nikolay: concept but the world says please no it just doesn't
work well So that's why I say I don't like them.
Franck: I will take another analogy.
I think the best editor is VI.
Because I also
Nikolay: agree to
Franck: learn it.
Yeah, we had to learn it
Nikolay: inside TMAX.
Franck: It was hard to learn it, we had to learn it.
But when you know it, you are very efficient with it.
But I can understand that a junior today do not want to learn
all those VI commands.
Same for null.
I mean, if you learn it and if you spend all your life doing
SQL, then, yeah, it's good.
But that's not the reality.
Nikolay: Yeah, so back to Monga, and let's talk a little bit
about the alternative and if we go out of SQL world, but stay
inside databases, what's happening to nulls and empty values,
unknown values and so on.
Zeros, empty strings.
Should it be considered all the same or no?
Franck: In SQL, for me in SQL it's easy.
A null is a value that exists, but you just don't know the value.
Your top manager has a salary, but you don't know it.
So if you have to put all salaries in a database, then you will
have a null.
And maybe you will put it 1 day, just because you don't know
it yet at the time where you insert.
The problem is that null is used for other things, for something
that doesn't exist.
You know, when in Excel we say NA, doesn't apply.
And if you use this as doesn't apply in JVa script, you're just
trying to store it and have the same logic when you query the
database.
So MongoDB does that.
It's very similar to not exist.
You have those documents where you can declare an attribute or
not.
And in most cases, if it's not there, it's similar to null.
And if you want to say explicitly it exists but I don't know
the value, then add something else, like a boolean that says,
okay, we don't know it.
Nikolay: Yeah.
By the way, You mentioned you like it, it's a good concept, but
I'm thinking, so many caveats, for example, if you take null
value and do plus 1, it will be also null, like unknown, remains
unknown, because we don't know what we're using.
If you
Franck: don't know a value, then you can add 1 and you still
don't know the value.
Nikolay: If you say at the same time if you use aggregate sum
it's not like that it uses 0 instead of now right?
Franck: Yeah because you sum the use it's defined as summing
the known values.
Nikolay: You cannot explain this, it's not logical.
It's just as is, because sum is just plus 1 argument, plus different,
just a sequence of plus operations, right?
Franck: But...
Depends on how you define the aggregation.
If it's even the sum of the known value...
Nikolay: If we have 3 rows, salary, like $1, $2, and NULL dollars,
NULL, right?
Yeah.
If we just perform explicit summarization, the result will be
NULL.
But if we use sum, we should be the same result.
It will be not the same.
It will be 3.
Franck: Depends on how you define it, but SQL defines that as
the sum of the values that you know.
Nikolay: I apologize.
It gives
Franck: you an idea, and it makes sense.
I mean, if you have 1000000 rows and you ask for a sum, you probably
don't run an unknown just because 1 is not known.
At least you know the sum of the existing ones.
Nikolay: Let me apologize and explain what's happening here.
I just flipped the board and made you defend the SQL world, which
is interesting because it shows that you have courage to become
specialist in both worlds.
This is interesting.
Franck: For me, I changed the company and I help different users,
but I did not change what I think about databases.
I mean, I've been working a lot with Oracle, I still think it's
a very good database, but I can understand that people want to
move out of it, and it's probably not because of the features.
I like Postgres, but I also think that there is something else
to do in the storage and to distribute it.
I like YugabyteDB, but I also understand that some people may
want to use something else.
Same for MongoDB.
I just want to help users when I can help them.
And also something, especially on Twitter, but we see a lot of
people comparing databases like MySQL is better than Postgres
or Postgres is better than MySQL or whatever.
And what I always say is that the best database is the 1 that
you know.
If you know how to administrate better SQL server on Windows,
then that's probably the best database for you.
It's not for me.
And if you are more successful with the NULL behavior in document
databases, then probably you should use document databases.
So my goal is just to have people be successful and use the right
database depending on what they know.
The worst that you can do is work with MongoDB and do the same
design as you did on the SQL database or the opposite.
Putting everything in document in Postgres just because you have
learned MongoDB first, that will probably not be good.
You need to understand how it works, read an execution plan in
both case, understand how the indexes are used.
Michael: I kind of agree for products where you're the only user
like if I'm choosing between iOS and Android or we were talking
before the call about macOS or Windows if I'm the only person
affected I understand choosing what I know best, but I feel like
with databases we're often choosing for a team for an organization
for a company And it's not just what I know best, even if I'm
the tech lead or, you know, even if I am the decision maker,
I need to factor in what do my team know best?
What can we hire most easily?
What's easiest to operate?
Or how long will this project last?
Is it a proof of concept project or is it our main system you
know it's a bunch of other factors I think are really important
and do you think you brought up use cases at the beginning I
think that's like super important because we often do know the
use cases we often do know the access patterns so picking the
1 that is best for that makes more sense to me than like which
1 I know best personally but I do take your point that if you
if you take that as like an organization which 1 do you operationally
know best as an organization like that it does still fit but
I do think there's some subtle difference there what do you think
Franck: I think that there are a lot of use cases that can be
successful on many databases.
Of course, there are some special cases that are really put at
the maximum throughput needed, where you have really to define
the right technology for it.
But let's say you have time series.
Time series coming from IoT and you have queries on them.
Of course, you can use a time series database, but you can also
do it on Postgres with a time series extension or not.
And you can also do it on a document database.
If you do it correctly, I think you have a lot of choices for
many use cases.
And finally, the enterprises that need a specific database because
of the very high scale of it, they finally build their own database
or they trick the 1 database to use it freely like their own
database.
But I think you really have the choice.
Many use cases, you can do that on Postgres, you can do that
on Yuga, but you can do that on Oracle, you can do that on MongoDB,
you can do that on DynamoDB.
But if you do it in a database where you don't know exactly how
NULL works or how the isolation, the ACID properties, the locks
are working, then you can also be successful on any database
for many use cases, but you can also be very bad in any database
if you don't care.
So it's more about the people, I totally agree, not your personal
choice, about the people.
And I remember discussions when I was doing consulting, I remember
discussing with a customer for something where it would have
made sense to use stored procedure and they were growing all
microservices, Java, all that.
And they just told me, yeah, but if we do it in SQL, PL/SQL was
on Oracle at that time, we are 4 in the team who can do that
and maintain that.
And then if any problem is there, we are 4 to be on call.
If we do it in Java, we have 200 developers in India, we have
200 developers in US.
If there is a problem during the night, they will manage it.
So the good choice, Even if it's not the best for performance,
for design, for whatever, the good choice is is also something
where you can sleep and have a team that can manage it.
Nikolay: Well, right now, AI can help you fix bugs, tests, and
so on.
Oh, yeah.
It's easier, right?
I have a couple of questions from friends, and I think you know
them, but I'm not going to reveal names.
First question, is MongoDB adding SQL to the product?
I don't
Franck: think this is in the roadmap at all.
And I don't think people are asking for that.
Let's look at another SQL database, DynamoDB.
When DynamoDB added the SQL syntax on top of it using PartiQL,
it was never used.
And the main reason was that users were afraid of it because
with the API that, with the document API, they know what happens.
The big difference, I mentioned the API, but there is a big difference
between NoSQL and SQL.
In SQL, you have a declarative language where you don't know
how the data is accessed until you read the execution plan.
Which is good because you have an application that is independent
of the physical data model, but it's also more difficult because
the developer has no idea how it works in production before looking
at the execution plan.
And when looking at the execution plan, the developer may have
to work a long time to understand why the bad execution plan
is chosen.
Is it because of statistics, not good index, whatever, it's kind
of complex.
With the NoSQL APIs, you code the data access.
So it depends on the database.
For example, in DynamoDB, if you want to use an index, you have
to query the index.
In MongoDB, you have this data independence where you query on
the collection, and if the index can be used, it can be used.
But you control the data that is accessed.
For example, when you design your documents, You design something
that is joined when you insert it, not at run time, where a query
planner will decide if it starts with 1 table or another table.
And it has some good and bad.
I remember in consulting, spending a long time with developers,
looking at the execution plan and they know their data and they
know their access pattern and they immediately tell me, of course,
that's not the right execution plan.
We must start with this table and then look up into this 1.
Okay, perfect.
I can use an int pg_hint_plan, for example, in Postgres to validate
that it's a better execution plan.
And then the developer is happy.
Yeah, perfect.
I want that.
And then they're like, okay, but it's not finished.
Now, we need to figure out how to get the right execution plan
without the hint.
And with consulting, people were paying the day just to get the
right execution plan that they know initially was the best 1.
With an OSQL API, you are closer to what happens physically and
then you have more control on that and some developers prefer
that.
Nikolay: Next question was, what do you think Postgres can or
should learn from MongoDB?
Maybe this, right?
Is it possible to...
Michael: I have 1 more.
I think they do major upgrades really well.
Franck: Oh, yes.
Well...
Michael: But we can learn that from a lot of databases.
Nikolay: Yeah, previous question was because I had like maybe
outdated knowledge that many NoSQL systems implemented some dialect
of SQL, for example, Cassandra with CQL, right?
Franck: Yeah, but they...
Nikolay: Not used.
Franck: It's only syntax, it's not SQL, it's not a declarative
language, it's just syntax.
I don't see the point.
Nikolay: If you
Franck: have an API that is integrated with your programming
language, why do you want to write a string in Java that you
send to the database if you don't have to?
In SQL, You have to do that because you have this data independence
and very different language.
But I don't really see the point.
But I forgot what you mentioned.
Nikolay: Yeah, I said vice versa what Postgres could learn from.
Michael answered upgrades.
I concur with you, definitely.
Franck: But that is related.
In SQL databases, in relational databases, to have this data
independence, logical and physical data independence, where you
query, in SQL databases, you query a logical model.
We were talking about normalization.
This is the logical model.
Maybe physically everything is stored in 1 table.
You don't really care from the relational SQL point of view.
But then to map the logical model to the physical model, you
need a catalog, a dictionary.
And this is what is difficult during upgrades, because you need
to change the catalog and the catalog is shared.
You can short the data, you can distribute the data, but the
catalog must be shared because they must use the same dictionary.
And that's easier with a NoSQL database because you have much
less to share about the metadata, because the catalog is in the
application.
The schema, we were talking about schemaless or schema on read
or on write.
The big difference is that Most of the schema is in the application.
And then if you upgrade the application, you have a new version
of the application, it knows the new schema.
And the 2 versions can work together if you take care that when
you read a document, you know how to read it.
Michael: Great answer.
Nikolay: Yeah, last question.
What do you think about systems which are built on top of Postgres,
like FerretDB and DocumentDB recently released by Microsoft?
Franck: That's a good point.
So, beyond the funny thing that DocumentDB is an AWS database,
but the name belongs to Microsoft because before putting a MongoDB
like API on Cosmos DB, it was called DocumentDB.
So, Microsoft did that multiple times, put it in Cosmos DB to
see if it will be more popular.
So first, it's a mess.
Different API, similar, you don't know the name where it comes
from, but I really like what the FerretDB people are doing.
And for me, as a developer advocate, I really like that there
is a MongoDB API on multiple databases.
In Oracle, you can also have a MongoDB API.
The more you make it popular, the more you help users to use
another API without changing the database, that's perfect.
From a marketing point of view, I don't think it's a big problem
either, because it's not only about the API.
What I think that the big customers of MongoDB like with MongoDB
is that they have in front a company that is doing only 1 thing.
The company is doing only MongoDB.
It's not like Oracle that has a database, but also another database
and cloud and manage service and software.
MongoDB is doing only MongoDB.
So if they use MongoDB on MongoDB, they have hundreds of people
doing support on it.
Nikolay: I cannot agree here because I remember MongoDB company,
it's called Mongo or MongoDB, sorry...
So I remember they also did some Postgres when they first released
BI connector.
Remember this story?
They used Postgres.
Franck: I have no idea.
Nikolay: To be able to use Tableau and other systems for data
analysis, BI and so on.
They needed to make some bridge to SQL world and they used Postgres
for that.
It was very interesting.
Franck: I have no idea.
My point was more like, you can do some MongoDB on Percona, you
can do some MongoDB on Oracle, you can do some MongoDB for FerretDB
on Azure.
And that can work.
But if you are a big customer and want support, you probably
want support from the original 1.
Nikolay: I hear you speaking as a member of this team, new member
of this team, but I also have like my must have a note that MongoDB
is not pure open source.
Franck: It is not pure open source, yeah.
Nikolay: Well, FerretDB is Apache 2.0, which is pure open source.
So this is 1 of...
Franck: Yeah, yeah, yeah.
Of course, I'm a big fan of open source.
I would prefer that it is open source, but I can also understand.
You know why they had to change the license?
Because AWS was taking everything.
And finally, today AWS is a major partner.
So it was probably a good move.
Probably today it could be open source.
But yeah, I can understand given the history that they want to
protect the managed service.
Nikolay: Open source is eating commercial software, clouds are
eating open source software.
Yeah, you remember this sequence of fish picture, right?
Yeah, okay, I think no more questions from me.
It was very super interesting and yeah, enjoy.
Thank you for coming.
Franck: Thank you very much.
I really like also what you do, how you can come with so many
different topics on every week.
I think you never missed a week for us.
So yeah, that's really nice.
Nikolay: Great.
Michael: Really kind of you, Franck.
Thank you for joining.
Franck: Thank you.
Nikolay: Have a great week.