Nikolay and Michael discuss why they chose Postgres — as users, for their businesses, for their careers, as well as some doubts.
Here are some links to things they mentioned:
Here are some links to things they mentioned:
- Our episode on why Postgres become popular https://postgres.fm/episodes/why-is-postgres-popular
- Database Systems: The Complete Book (by Hector Garcia-Molina, Jeff Ullman, and Jennifer Widom) http://infolab.stanford.edu/~ullman/dscb.html
- Our episode on the Postgres startup ecosystem https://postgres.fm/episodes/postgres-startup-ecosystem
- Will Postgres Live Forever? (talk by Bruce Momjian) https://www.youtube.com/watch?v=iYVxWpyaGpA
- "Anarcho-Syndicalist Commune" from Monty Python and the Holy Grail https://www.youtube.com/watch?v=R7qT-C-0ajI
- The Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary (book by Eric S. Raymond) https://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar
~~~
What did you like or not like? What should we discuss next time? Let us know via a YouTube comment, on social media, or by commenting on our Google doc!
What did you like or not like? What should we discuss next time? Let us know via a YouTube comment, on social media, or by commenting on our Google doc!
~~~
Postgres FM is produced by:
- Michael Christofides, founder of pgMustard
- Nikolay Samokhvalov, founder of Postgres.ai
With special thanks to:
- Jessie Draws for the elephant artwork
Creators & Guests
What is Postgres FM?
A weekly podcast about all things PostgreSQL
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.