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.