Michael: Hello and welcome to Postgres.FM, a weekly show about
all things PostgreSQL.
I am Michael, founder of pgMustard.
This is Nikolay, founder of Postgres.AI.
Hey Nikolay, what are we talking about this week?
Nikolay: Hi Michael, I thought sometimes it's a good idea to
reconsider decisions, you know.
And if you chose some tool or some project to work with, sometimes
it's good to look back at recent experience and further back
in the past, why you made this decision and think is it still
the right decision?
And should you keep using this product or system or project or
anything or tool or it's time to change it?
Michael: Yeah, I hope you're not having second thoughts.
Nikolay: You can doubt anything.
Why not?
Michael: Just I had on my list of people I expected to doubt
things Nikolay Samokhvalov doubting Postgres was very, very low
down my list.
Nikolay: Okay, so, by the way, good pronunciation of my last
name.
Yes.
Yeah, thank you.
And yeah, so, honestly, it's not a joke.
I'm thinking, should I still use Postgres?
And for me, of course, it's a much more fundamental question,
rather than for like...
Compared to people even if you even if you CTO and all your data
in Postgres it's a big question for you to...
But for me it's even a bigger question because a company called
Postgres.AI and last 19 years I put all data to Postgres, last...
Okay, how many years?
Postgres consultants, like, a source of income depends on it.
Not only data in Postgres, but also all my activities are in
Postgres.
And since 2007, I'm also a community activities, having some
community activities, all my thoughts related to professional
stuff very close to Postgres, around Postgres, but I must admit
I have doubts.
So what I would like to for us today discussing our topic which
is why Postgres.
What I would like to have like doing this discussion is to I
would like to look inside myself, raise all the doubts I have,
and honestly, If the doubts grow and we don't resolve them, I'm
ready to switch to a different database system and a different
type of business.
I'm not joking.
Michael: I'm looking forward to this.
Nikolay: I see huge potential recently.
We started growing in all aspects and it's super interesting.
and so many things not yet accomplished.
I have big ideas, I think I have big ideas too, which I must
implement and so on.
But I also have doubts.
Let's talk about them and if they start to overweigh these ideas
and desire to build and so on, then I'm honestly open to switch.
Really.
It's also probably I won't be present on this podcast anymore.
I'm not joking.
Really.
So, why Postgres?
Michael: Let's go back.
Let's go back.
Should we start at the beginning?
Why did we each choose Postgres initially, both as users, but
also to build tools around, build companies around, build careers
around?
It'd be interesting to hear why you chose it, even if it's...
I know we've covered it briefly before, but...
Nikolay: You want to start from me or from yourself?
Michael: Why not start from you, I think?
Nikolay: Sounds good.
I went to a great university in 1998.
I think elite, like very good.
I'm an MIT, it's in Russia.
It's like hard to get into 1 of the best technical universities.
And applied maths and computer science was focus, but smaller
focus starting third grade you need to choose specialty.
I wanted to do hardcore stuff so I went to kernel and operational
systems and so on, but I remember it was a couple of Armenian guys
who were professors that were responsible for this direction.
I went to them, they said, write us a letter, we will respond.
And it's great.
So I wrote a letter, no response, wrote a letter once again,
no response.
So in my head I was thinking, damn, I tried to be hardcore.
Now I'm like, I approached guys who are older than me, have experience
in the same institute, in the same subdivision.
Many directions, by the way, AI was already one of the directions,
very different than today, of course, but still, like neural
networks and so on.
Somehow it wasn't interested in that direction.
I personally was asked like what's the easiest?
And they said, oh, professor for like which is doing databases
is the easiest And he's like so kind, you know, like, and definitely
it's the easiest.
Like, good.
I go there.
This is how I chose databases.
Honestly.
Then I started saying, you know, databases are in the heart of
any information system.
It's where data is stored.
It should be in good shape.
If it's in bad shape, then everything can be bad, slow, and so
on.
Not efficient or not bad quality, like not secure or something.
So many things, it's really in the center, right?
I believe in this.
But at that time I chose just like by accident.
So, and then I worked with Oracle slightly more than 1 year,
with SQL Server maybe up to a couple of years, and then somehow
by accident they got into startups in 2004-5, and they said of
course we cannot buy, we have like budget to build something.
I joined and became CTO, like started growing team and I was
responsible for almost all decisions technically and they said
we cannot afford Oracle license of course.
I was a big fan of SQL Server and I told them, okay, then we
use the most popular open source database system, which is MySQL.
And you know, I probably mentioned, right, 1 week later I was
already almost quitting because it's ridiculous, repair table,
0000, date.
I cannot work with it.
I have good foundation, because professor was kind and easy going,
but it also was great professor, and the best I think in Russia
at that time in terms of academia and very well known books and
so on.
I was very lucky to be his student and then PhD student and his
name is Sergei Kuznetsov.
His name was unfortunately he died recently.
So yeah, he was a very great guy.
And I learned a lot from him and of course I learned, I studied
books like Chris Date's, like kind of simple thing, but also
Garcia-Molina, Ullman, right?
Which is… Later I learned these guys are from Stanford.
It was unexpected.
I thought maybe it should be from Berkeley or so, but then I
also found they are already not active but from Stanford.
So many good stuff like relational theory, calculus, These things.
Sometimes I learned many things in Russian, so sometimes I'm
having difficulties finding proper English names.
But in general, I had a good foundation.
SQL at that time already learned like, it's actually from him
I learned that nulls is a big problem in SQL model.
There is a relational model and there is a SQL model and they
are not completely the same.
At that time I studied also SQL standard.
I remember SQL 92, then 1999, then they started doing this 2.0.0.m
or x, like kind of not whole big release, but releasing parts,
right?
So a lot of stuff learned there.
Standard is hard to deal with for sure.
So I like big respect to guys who deal with it.
Peter Eisentrout and Vic Fearing, right?
CB.
From the Postgres side.
LB.
The closest to standard, these 2 guys, right?
Big respect.
For sure, it's hard.
So I was very young, like 20, 21, 22, I was already reading the
standard.
Then I work with MySQL and what a piece of something it is, actually,
honestly.
We learned some principles, but you touch something and it doesn't
work or work in opposite direction than you compared to what
you learned in Oracle.
In SQL Server, of course, there are some specifics, but in general,
both systems were mature and worked quite well and definitely
like grown-up systems.
MySQL wasn't a grown-up system.
You need to choose at that time, right?
You need to choose if it's MyISAM, repair table, but it lacks
full-text search and all you need to do was the second engine.
So… CB.
Michael: NDB?
LB.
Nikolay: NDB, right, but it's super slow.
Super slow.
So 1 or 2 weeks I was on this, but we just hired a guy from astronomical
university from the same place where Oleg Bartunov was, I think
is still doing some academia activities.
Maybe already know, I don't know.
But at that time...
So that guy said, I know this guy, Oleg Bartunov, and try Postgres.
And everything went in the right place immediately.
I converted super fast everything.
Super fast.
I needed to write an additional layer of caching because I had my
own ORM at that time.
It was before I think current popular ORMs became popular.
It was before Django.
I think Django and Ruby on Rails already existed, but were not
super popular, and we were using PHP.
I wrote my own and it had a lot of work with metadata.
I quickly switched to Postgres and worked with metadata in Postgres,
but it became very slow.
Everything is good, but working with metadata is much slower
than in MySQL, so I needed to add caching for queries to pg_class
and so on.
But this is the only concern.
Everything else went like it was like all the pieces of the puzzle
in the same, like where they should be, right?
Because Postgres probably has issues like replication, like we
learned later and needed to use Slony and Londiste later.
But it works as expected if you studied databases from books,
right?
From theory, Switching from theory to Postgres is natural, which
was not so if you switch from theory to MySQL.
This is how I end up actually loving Postgres because it saved
me.
It's free because we couldn't afford license being a small startup.
It's open.
Open maybe I didn't really care that much at that time about
openness, but I liked it.
Extensibility, openness, I liked it immediately.
And most importantly for me, things work as expected in terms
of relational theory, like there are triggers, there are views,
right, and like null behavior and so on, like these things as
you expect them to be.
Really reliable, right?
The ACID principles, strict system was already very strict to
ACID principles.
It probably was not super performant at that time compared to
MySQL MyISAM.
But you didn't lose data.
Except it's a bug, right?
Bugs happen, of course.
Michael: Yeah.
So that was originally why you chose Postgres.
And I guess we've gone a little bit into why you continue to
choose it in terms of you fell in love with it.
But why, yeah, why do you continue to build products and services
for it?
Nikolay: Well, this is my personal.
I built 3 social networks.
Well, I was in Russia then.
12 years ago, migrated to the US and lost my interest in social
networks already.
But interest to databases was constant all the time.
Yes, and Postgres popularity grew, demand started to grow, I
think, in 2014-15, and this is exactly when I needed additional
source of income, so I started helping other companies which
started having bigger databases in Postgres, like Postgres databases,
and started having troubles.
It was natural for me to use my knowledge and desire to work
with Postgres and that interest into databases to start a consulting
practice and then this podcast was born out of these seeds, meetups
in the past and desire to go online with meetup activity because
I know people are everywhere, like, and meetups are only in 1
place.
It's good to meet in person, but yeah.
So it was quite natural, everything was natural.
So why Postgres?
Because it's just, I have an interest, I have the opportunity, things
like match, and we continue working with it, right?
Michael: Yeah, perfect.
I'm only hearing positives.
Should I go through mine quickly, the reasons for choosing it
initially?
I think some of them are quite different from yours, but it's also
later.
My journey is later.
So I first came across Postgres through work rather than through
academia or anything.
My degree was unrelated.
So I ended up coming across it first while I was working at a
database tools company.
So I first fell in love with software and it was almost entirely
graphical user interfaces to things like databases.
So our biggest divisions at the company were for SQL Server tools.
So that was my first experience.
And I came across Postgres first as something people started
requesting.
Support, yeah, can you do the same tools?
We'd love to buy the same tools from you for Postgres.
You know, companies that used and loved our tools for SQL Server
were starting to do some projects on Postgres, you know, moving
not that many migrations at the time, but like greenfield projects,
they would often choose Postgres.
So this was about that same time that that 2013, 2014,
2015.
So it's those years that I started to hear it more and more.
And then in late 2014, I actually moved to a startup in London,
who were a payments company, our payments company GoCardless,
and their team, it was exceptional engineering team, still is.
And they love Postgres.
And that really, like, hearing that bigger companies were starting
to use it, and then also knowing that the cool YC startup scene
were also using Postgres, that really triggered something in
me.
It's like, ah, this isn't just something.
Like, I already knew that it was up and coming.
I know it's really old at the same time, but I already knew it
was becoming more popular.
And that these engineers that were much younger and VC-backed
startup in the UK chose it and loved it really inspired me to
like, think this could be a platform I'd want to build for this.
This could be going places.
And also.
It's clearly a technology that is already like sound and fundamentally
sound if the, all of these companies are choosing it.
And I'd also really kind of reacted negatively to some of the
other things that had been hyped up at a similar time.
Like I really couldn't get behind the whole MongoDB, like the
NoSQL movement at the time.
And also, do you remember big data?
Do you remember that as like a phase?
Just really reacted strongly, like strongly and negatively towards
a lot of the people that were hyping those up because it just
didn't seem based on solid foundation, like on good principles.
And it didn't make sense to me that these things were needed
or like fundamentally better.
And so when I saw Postgres was coming, was up and coming, and
it was based on good fundamentals, and they prioritised, like
I saw a lot of value alignment, like you,
Nikolay: I
Michael: would, And I think like most people, correctness and
reliability are more important than performance.
Of course, performance matters after that, but there's no point
in it being fast and wrong.
It's just that priority order seems so much better in the Postgres
ecosystem.
But then beyond that, there were loads of other benefits.
Like as you say, free as in price, that's obviously extremely
attractive.
And I think probably still underappreciated, like actually free,
like totally free.
And then also the fact that it's open from a source code perspective.
Having built tools for SQL Server and Oracle, having been involved
in teams, having to research new versions or look back to why
things have broken, all sorts of things.
If you don't have access to the source code, I mean, you don't
have access.
Nikolay: Many companies don't understand that.
I first felt this.
I was experiencing this insight, what you're just sharing, that
source code is like… it's like kind of deeper documentation.
When I first had it in 2018, helping some company which we are
migrating to RDS, they were huge already.
They needed logical replication to first to Vertica, then to
Snowflake, doesn't matter.
But they considered some tools and 1 of the tools was maybe 1
of the popular at that time was Click, Xatunity.
And the documentation didn't cover so many questions I had.
And I just, like, I realized I was talking to my client, I just
said, you know what, if they had a source available, not open
source, a source available, I would just answer myself, because
I can read code, it doesn't matter language, I could find this
place, how exactly they create logical slot.
Spent a lot of time and efforts, I realized they create logical
slot using SQL function, not replication connection.
That was their problem.
But for me, lack of source code means lack of ultimate documentation,
basically.
Michael: Ultimate and accurate and up-to-date.
Nikolay: It's also about transparency.
If you don't provide source code, you always can say, oh, we
fixed this problem, but not in all cases.
But you cannot bullshit if you have source available with all
versions and tags and releases, like anyone can see.
It's about transparency.
And transparency is why I have doubts in Postgres.
Michael: Oh, interesting.
Nikolay: Yes, but it's not technical.
Let's talk about technical first before we...
Michael: Well, I think we can intertwine them.
But a couple of other reasons I chose it that are on the non-technical
side.
I think when you're building for.
So I I'd worked at places that chose Postgres, but I wasn't the
decision maker.
At those.
You know, It was an already made decision when I worked there.
I never chose explicitly until I started my own business.
So it was only then that I mean, we chose it not just as users,
of course, but as as a platform to build on.
And because I was trying to build something like long term, it's
very much, you know, a small, slow, steady, not VC backed, hopefully
for decades, that kind of business.
I didn't want to build for a platform that there was, that was
like, that could shift and change drastically from underneath
me and also that was really at risk of a company changing their
mind or changing something drastically.
So it's often described as platform risk and it felt really low
with Postgres, not just because it was built on really solid
foundations but also because there's no 1 company that can, if
they, you know, there's no company behind it, there's no commercial
entity that is dependent on its success.
Nikolay: Like MySQL AB, right?
Michael: Yeah, well, but...
Nikolay: Or MongoDB, like the company.
Michael: Yeah, like all of...
If you consider all of the companies that have changed their
licenses in the last few years, for example, That's just one example
of how things can shift from underneath you.
But also, they could go completely closed source, or in MySQL's
case, stop publishing test cases, which is one step towards, again,
I don't think we've had any awful examples where businesses really
would have suffered, but they can if there's a single company
behind it.
And the fact that Postgres was not just, not just had seemingly
had policies in place to prevent that happening, but also seem
to live those values.
There's a real, there's lots of companies that employ contributors
and there's real collaboration between those on new features
and on bug fixes.
And it seemed truly collaborative, truly a community project,
even though lots of those community members were, almost all
were being paid to work on it, it was still a community, a group
effort between collaborative organizations that could all benefit
from it getting better.
And it just didn't seem like it was as likely to have a fundamental
shift as some of the other platforms out there.
Nikolay: It's interesting, actually.
It resonates with my idea that sometimes VC-backed company… Recently,
we discussed companies which are closing, post-VC-backed companies,
startups, right?
It resonates with the idea that if you… VC-backed, you have pressure,
right?
And you can have… because of that pressure, you can make some
unpredicted moves, unpredictable for your users and customers,
right?
For example, if you're a great successful Postgres startup, but
not successful enough for VCs, you suddenly can decide to switch
license and make more money if you lose some users, right?
Yeah.
This is about Postgres, but you apply the same logic for...
This is about Postgres startup, Postgres-related startup, right?
But you apply the same logic to Postgres core.
Michael: Yeah, as a platform to build on.
Nikolay: Yeah, this is interesting.
And if, for example, distributed nature of development basically,
right?
Distributed nature of development.
But of course there are some key people and if they have gone,
for example, disappeared or decided to quit or something, Postgres
has more chances to survive, right?
This is what Bruce Momjian describes in his talk Will Postgres
Live Forever, right?
Because like Postgres was dead several times already.
And someone picked it.
Well, it was dead after it was basically closed in Berkeley.
And then it resurrected in the middle of 90s as open source,
right?
So, yeah.
Michael: Yeah, you're right.
There are a few individuals who contribute a huge, huge, huge
amount.
But it also feels like there are others who contribute hugely
too.
And obviously, if a few of them or several of them stopped, like
when MySQL joined Oracle via Sun, and you had the split with
MariaDB if there was a fork like that in the Postgres world for
some reason and several of the contributors all left at once
or 1 or 2 really really big important ones did I can imagine
it being detrimental to the speed of Postgres enhancements, but
I do think there's still so much momentum.
And actually, I don't think...
I mean, we can talk about it, but I think feature growth is really
helping with Postgres, but I actually don't think it's as, now
that it's competitive with Oracle and SQL Server on a bunch of
like enterprise and like performance features, it's not as important
that we keep innovating as quickly on the feature level.
Perhaps things like pgvector and making sure we're available
for new use cases via extensions or via core could be important.
But yeah, I'd be keen to go back to you.
You already raised...
Do you want to cover technical reasons why others are choosing
it, maybe us or others, or do you want to move to doubts and
things
Nikolay: like that?
Let's quickly cover technical reasons.
So first of all, it has a strong foundation, follows principles,
follows standard, not fully, but quite well, much better than
many others.
And this is like, it has principles like extensibility and so
on.
Like these technical things, like Extensibility is constantly
bringing new features.
pgvector relies on extensions framework, and it has its own lifecycle,
but maybe it will go to the core at some point.
Maybe, right?
As the full-text search or XML did in the past, they were separate
extensions, but then went to core.
And this means also features are coming, coming, coming.
That's great.
Michael: Or it could, there's another success case where it could
be more like PostGIS, which has been incredibly successful and
helpful for the growth of Postgres in my opinion, and has stayed
an extension.
And I think a lot of people are choosing PostGIS, and Postgres
comes along for the ride, rather than the other way around.
And that's really cool.
And it could be the same in pgvector.
Like, people could be choosing pgvector, and Postgres comes along
for the ride in those cases.
So yeah, either case could be a huge success still.
Nikolay: PostGIS is an interesting example.
Yeah, and it's kind of a whole different world, right?
But imagine it was part of, like Postgres documentation doesn't
have PostGIS.
Would Postgres be even more successful if PostGIS was in core
and documentation had it?
Or, for example, if Timescale, the company, decided to go all
in with TimescaleDB and make it super open, eventually contributing
it to Core.
Just imagine, with all compression and all the stuff and Postgres
documentation had it.
I know it's not good for their business maybe, but imagine this
world we live in.
Postgres has PostGIS, it has TimescaleDB, pgvector, it has everything,
right?
The level of quality is unified, right?
It's like it's being tested all the time in the same manner as
Postgres itself.
And people don't spend time trying to understand how to bring
these pieces together.
And if it's managed Postgres like RDS or something, all the pieces
are there already.
Michael: Yeah, I can see arguments both ways.
I've seen people I respect a lot arguing completely the opposite
direction.
Nikolay: So maybe we should define what Postgres is.
There is Postgres when you just install it with a few extensions,
not a few, dozens of them, so-called KDRIP modules, right?
And also CLI, tool psql, and that's it, right?
That's it.
It also can create a user in your Ubuntu or Debian or CentOS
and set things up and be installed as a service.
Of course.
But that's it.
There are also super popular extensions which make Postgres very
different, like PostGIS or TimescaleDB or pgvector.
Great.
It's also Postgres or no?
It's also Postgres, right?
Bigger Postgres.
It's like there is Los Angeles, but if you live in Long Beach,
you still live in Los Angeles, right?
It's like there are bigger Postgres.
Michael: Al-Khalili That's a great example because it depends
in what context you're speaking and who you're speaking to and
you know how familiar they are with the area if they say where
are you from but it's if you if you're a local coffee shop in
near LA and someone asks where you're from, you'll probably be
more specific.
But if you're in Thailand and somebody asks where you're from,
you'll probably just say LA.
Nikolay: Same here.
Michael: Same, exactly the same.
Nikolay: We use Postgres, but if you say we use Timescale Cloud,
we're already like, okay, also Postgres, but definitely with
TimescaleDB and probably without some things they don't provide.
Interesting.
So there's bigger Postgres.
There are also many tools around, like you're building 1 and
we're building something.
So these tools, yeah, but a lot of options and it's like quite
a rich ecosystem.
Great right?
So this is also a reason why Postgres, because the ecosystem is
super rich and growing and it's great.
Michael: Although possibly, like I think that could be an argument
against it.
Definitely when I first was looking at Postgres, I'd actually
say that other ecosystems were a little bit more advanced.
There were more people building external tools for some of the
other systems.
So I do think there's like an, that's not as obvious a 1 for
choosing Postgres in my opinion, but it's great that the more
and more are popping up the last like technical ones I had were obviously
the extensibility, not just in terms of pre-made extensions,
but the fact you could like as a user, you can extend Postgres
in various ways.
I think a lot of people do choose it for those reasons.
Nikolay: Of course.
Yeah.
Starting from the creation of your own data type to your own type
of index and extensions and now like even more things up to storage
engines and so on.
Michael: Yeah, exactly.
I think people can dip their toe in with a new data type and
then like gradually get more and more excited by what they could
build.
And then the last technical 1 I had on my list was, and this
might be more why people stay rather than why people join in
the first place, but backwards compatibility is so helpful.
Because of the good fundamentals and because Postgres has five-year
support of major versions, people aren't forced to upgrade like
that often and things don't tend to break when they do.
You know, obviously we've done episodes on this and there's a
lot of complexity around major version upgrades and you do have
to re-release those things.
But compared to other systems, compared to other platforms that
people are building and building for, things like there are major
breaking changes in a lot of database major version upgrades.
And having seen people have to deal with those and have to get
stuck on really old versions, it's just so much better in the
Postgres world.
So I think that might be a reason people stay or like maybe some
very smart people, the reason they choose it.
But I definitely wasn't aware of that when I was first coming
across it.
Nikolay: Right.
Yeah.
Michael: Yeah.
So on the doubt side of things, you mentioned transparency.
Transparency.
Nikolay: Yeah.
For me, transparency is a key factor I dislike in Postgres because
the source code is open.
In mailing list, they are open as well.
Tanner Iskra Sure.
Leon Mandeley But if you look closer, and I know like people
who just use Postgres, they don't see problems.
But I know for sure, not like only based on my experience, but
based on many companies, not just 1, not just 2, many companies,
people who are in the head of those companies, Postgres-related
companies, big ones, big names, they feel this lack of transparency
in processes.
Like Postgres project doesn't apply this principle to itself.
Processes are not transparent.
Michael: Question, just to ask where you're going with this,
do you consider any other alternative projects more transparent
and more open, like, along this axis?
Nikolay: I'm honestly not a big expert here.
I just see if, like, well, usually organizations which are built
recently, which are quite strong and so on, have kind of democracy,
right?
They have elections, some rotation of power.
Michael: When I'm looking at alternatives, if I'm thinking like
MySQL, Redis, SQLite, none of those have as far as...
Nikolay: But it doesn't mean there's no problem.
Michael: No, no, no.
I'm just like the question why Postgres partly asks if not Postgres,
what else?
Like, they're almost in the database.
Or do you know what I mean?
Like if you're gonna, if you doubt it and then say, maybe this
isn't it, what would it be?
Like what's the alternative?
Nikolay: Yeah, good question.
It can be forked postgres with different principles.
Interesting.
Yeah, yeah.
Honestly, I like, I, When I raised in the beginning of this discussion,
I raised this, I have doubts, I have them for long.
I just wanted to look inside myself and validate.
But while we are discussing all these things are good, I'm still
staying honestly.
Like I already feel like I'm still staying with Postgres, but
people must know I'm not fully satisfied with things.
And at some point, I might say it's enough for me.
I don't feel it right now.
I'm very far from it.
But lack of transparency.
Michael: Yeah, so we've got lots of reasons why we chose Postgres
in the first place, lots of positives, like still that we would
choose it again today and that we do continue to choose it every
day.
Some areas for improvement for sure.
I don't see a great alternative.
I think it's still exceptional and love building for it, and
I'm hoping to for decades to come.
It'd be cool to hear from anybody that works in or with like
similar organizations with different governance structures and
how those work.
All I can think of is like benevolent dictator types you know
Linux and and SQLite and things but I'm sure there are other
good communities like I think the Kubernetes 1 keeps coming up
as a...
Nikolay: Cloud native, maybe.
Michael: Yeah, so there are some interesting ones out there that
are run slightly differently, so it'd be great to hear from people
that are heavily involved in those.
Nikolay: Mm-hmm.
Right.
So, yeah, in my opinion, Postgres is definitely one of the greatest
examples of open source.
I see it as a big bazaar with one big cathedral in the center,
which now I recognize and smaller cathedrals on this bazaar maybe.
Well, the cathedral is one, it's one, but it's still a bazaar and
no matter what, I think it has good chances to be a good bazaar,
like with many voices, even if people inside the cathedral in the
center don't agree with those voices, right?
These voices cannot be due to probably due to original nature,
license chosen in the '90s, and the original nature of the project
itself, even if there are conflicts, this bazaar will still be
huge.
And I think it has good chances to be huge, with different opinions,
sometimes very contradicting.
So yeah, I'm glad it's a bazaar because I think it's a good thing,
like an open source.
You know, I'm referring to cathedral and the bazaar by recreation.
Michael: Yeah, yeah, I love the analogy and you've used it multiple
times in the past but it's always been cathedral or bazaar.
Nikolay: LM.
Yeah, but now I see bazaar with a big cathedral in the center.
AD.
Michael: There is a cathedral in the middle.
Maybe it's not that big though.
It is a cathedral but maybe the bazaar is bigger and the cathedral
is very large.
LM.
I
Nikolay: feel sometimes this cathedral in the center tries to
pretend there is no bazaar almost.
Or this cathedral can define all the rules.
It cannot.
It cannot define all the rules.
Michael: Have you seen Monty Python?
There's Monty Python, I think it's, which 1 is it, maybe Search
for the Holy Grail?
Have you seen the Monty Python
films?
Nikolay: No.
Michael: No, I think you would like them.
Nikolay: My son loves it.
He tries
to convince me for years to watch everything.
Michael: You have
to watch it, I think you'll enjoy it.
But there's 1 moment where the king is going up to the peasants
working the land and tells them what to do because he's their
king.
And they're like, I don't believe in a king.
So it's quite funny.
I'll link that up.
Nikolay: Yeah, I should see.
So yeah, for sure it will remain to be a cathedral and it's good.
So yeah, I thank you for help validating that I still want to
use Postgres, you know.
For me, I have enough reasons to use Postgres no matter what.
No matter what happened.
I mean...
Michael: Nice.
Maybe we'll discuss again in a couple of years and see where
you are there.
Nikolay: Yeah, well, yeah.
I'm quite positive I will keep using it and help other people
to use it in a better way.
Michael: Me too.
Wonderful, thanks so much, Nikolay.
Catch you next week.